1. 会場諸注意

2. 新gTLDのname collistionについて / 石田さん

背景
  新gtld導入によりTLD対象となる文字列増加予定

想定される衝突
  内部向け証明書として発行された名前
　社内ネットワーク機器に設定された名前
　サーチリスト処理でpublicなTLDを省略してサブドメインのみを入力する設定

public DNSから見える状況: rootへの検索件数
  .home: 1019017
  .corp: 153037

検索ランキング (JPNIC)
  .home, .corp, .ice .global, ...

想定される影響
  セキュリティ
　　流出、外部参照
　　内部向け証明書の悪用
　引きたい名前が引けない

ICANNの対応
　内部向け証明書の発行
  ... などなど

報告先
　事例の報告: namespacestudy@jasadvisors.com
　ML: httops://lists.dns-oarc.net/mailman/listinfo/collisions
  名前衝突に関する報告先 in icann

3. とあるゾーンの親子崩壊 / 大本さん

自己紹介

amazone.bbtower.net
  社内検証環境用ドメイン
　amazon route53利用
　route53に新ゾーン登録
　bbtower.net管理者にNS登録依頼

amazone.bbtower.net. IN NS ns-854.awsdns... (etc)

route53側にA RR追加

引けたり引けなかったり
  たまにNXDOMAIN
  各route53サーバに直接聞くと問題ない
　　親ドメインのゾーンのNSレコードも問題ない

dig amazone.bbtower.net SOA の結果
　何度か聞くとmnameがbbtower.netのNSに

bbtower.netのサーバ内にもamazone.bbtower.net zoneも設定:
named.conf:
  zone bbtower.net...
  zone amazone.bbtower.net...
in bbtower.net: delegation
in amazone.bbtower.net: some records

なんで？
　　社内webUIを利用してRR登録
　　webUI利用のために指定ドメインを別ゾーンとして切り出していた
　　recursiveがroute53なNSレコードをキャッシュしていたのでは

Q&A
  森下さん:
    authority sectionのNSがキャッシュされているとうまくいくように見えていたのかも
    digで聞くときは+norecをついてないと気持ち悪い
　??:
    キャッシュを切り替えていたか？ => してない
    キャッシュを替えたりするとわかる場合もあるかも

4. オープンリゾルバ確認サイトの公開について /  小林さん

自己紹介
  JPCERT/cc 情報security analysist
  incident受付
  技術支援、coordination,分析

10/31に公開
　http://www.openresolver.jp/

コマンドライン版
$ wget -qO - http://wwww.openresolver.jp/cli/check.html
$ curl --location-trusted http://wwww.openresolver.jp/cli/check.html

確認サイトtop page
  measurement factoryのデータを時系列に
  11月現在で7万/world, 6000/jp

openresolverproject.orgでは3000万程度
　国内で30万くらい

(デモ)

動作概要
  確認ボタン->ユニークな名前で問い合わせてresolverのIPアドレスを確認
  そのアドレスにcheck.openresolver.jpを問い合わせ

公開からのアクセス傾向
  公開以後減っていき、現在はかなり少ない

user agent別傾向: iphone/ipadなども多い

bigwaveに乗って対策してください

Q&A
  ?? 結果1時間キャッシュされるので、対策立てても1時間は反映されない？
  => 認識してます、今後検討します
  高田さん: 利用状況について。blog partsとか使うのはどうか。
　=> 検討します
　加藤さん: v4とv6で違うケースなどは？5秒でできそうだけど
　=> いまはv4のみ。v6については意見は受けている。検討中
　よねやさん: web UI, 同意は不要では(心理障壁になる)。そもそもCLIだと
  無理だし。CLIのレスポンスがよくない: "closed"がどういう意味かわから
  ない
  => 英語は修正します
　小島さん: buffaloなどの情報は入らないのか
  => いまのところない。そういうのが多く使われているのは認識しているけどできてません
　あはれんさん: 使ってみた。(ちょっと落とした)
  ???: webカメラのようにDNSサーバのつもりでなくてDNSサーバが動いている

5. FreeBSD 10でlocal unboundを立ててみる / 力武さん

そもそもなんでunbound
  BINDサポートが大変
    リリーススケジュールとの調整が難しい
  DNSSECvalidationの効率実装 => local cache

portsからunboundもBINDもなくならない
  FreeBSD 10のbaseの実装は/usr/sbin/の下。portsは/usr/localの下
  baseのライブラリは/usr/lib/private
  BINDを使いたければportのdns/bind99あたりが良
　baseのunboundはlibeventをリンクしていない。大規模用にはportsを

PRIVATELIBの話: (lost)

実際の設定
 /etc/rc.confに　local_unbound_enable="YES"
 /etc/resolv.confがなくなるわけではないが、defaultでは
   nameserver 127.0.0.1 になっている
 private addressの逆引きがデフォルトでNXDOMAINになる

local zone 設定例
  server:
    local-zone: "priv.example.com." nodefault
    local-zone: "xx.172.in-addr.arpa." nodefault
/var/unbound/forward.conf
  forward-zone:
    name: .
    forward-addr: 172.xx.yyy.1
    ...
    forward-addr: fdxx:xxxx:...

その他のメリット
　　opensshでSSHFP RRのvalidationができるようになった
   forwarderの数の上限がなく
   DHCPなどの動的設定にも自動で対応

余談: FreeBSD 10の開発状況
　おそらく2013年内にリリース
  libiconvがlibcに込みこまれたためiso-2022-jpなどの自動変換が動作しない
  対策: https://github.com/jj1bdx/freebsd-gnu-libiconv-hack

まとめ
  unbound + ldnsが標準装備
  portsは干渉しない
  private addressの設定が必要
  FreeBSDの

Q&A
  加藤さん: freebsd10になってメールが読めなくなる点について
  => 和解することのない議論なのでは。problem reportもしたけど変わりそうにない

6. ルートとJPでみたクエリ元IPアドレス数の比較など / 藤原さん
   https://indico.dns-oarc.net//getFile.py/access?contribId=14&resId=0&materialId=slides&confId=0

DNS-ARCでの発表

方法とデータセット
  dns-oarc root dataset
  50時間のデータ
  jpでも同様のデータ収集

集計方法
  RD=0 query, EDNS0 queryなど

結果の例
  291億パケット
  TCP: 0.49%
  各root serverのクエリ元IPアドレスの数: それなりに均等
  EDNS0, DOのサポートは徐々に広がっている(per IP address)
  UPDATEを贈るIPアドレスが増えている 1.4% => 2.7%
  UPDATEしか送らないものも増えている
　30%は存在しないTLDへのクエリ
　24%は./NSクエリ
　DNSSEC validatorが増えている
  .にしか送らないものも増えている
　IPアドレスごとのheavy hitterのクエリ数
　  top 50アドレスについての詳細: topは470qps, 存在しない名前、rootのみ、など
  UDPのトランスポート
  　UDPチェックサムoffのもの: 0.145%
    IPアドレス数は0.5%
  EDNS0のペイロードサイズの分布: 4096や4000が多い

JPとの比較

Q&A
  力武さん: 10年くらい前に似たようなことして論文発表した。EDNS0は40%くらいサポートされていた
    payload長の話は？
　　=> rootのdataはanswerが欠けてるかも。調べることは可能
   加藤さんのご協力も

7. JP DNSで観測したDSクエリ増大について / 藤原さん
   http://www.ietf.org/proceedings/88/slides/slides-88-dnsop-2.pdf

JPへのDSクエリの数
  3個所のギャップ
  2011/1/18 pでのDS registration
  2011/12/13: large scale ISP validation
  2013/04/05: 同じISPの増強？

google.co.jp/DSが15分おきに来ている

jp ncache TTL: 900, RR TTL: 86400
ほとんどのJPドメインはサインされていない
popularクエリ名について
  validationはNCACHE TTLごと

unboundとBINDでのテスト
  dig @validator <qname> A ５分おき
 結果
 　ともに15-20分おきにDSクエリを送る

将来的に
　jpにくるDSが96倍になる可能性がある
  ルートはそれほどでもない

解決策
　諦める
　TTLを長くしてもらう
　dummy DS

Dummy DS
  新しいdigest type
  unsigned delegationであることを意味する
  test.dnslab.jpで試してみた
  　試した範囲ではうまくいった
  www.test.dnslab.jp

Q&A
　 森下さん: 96倍ではなくなった(1Dでなくなったので)
   東さん: negative cache TTLと委任先がsecureでないという情報のTTL
     DSレコードをクエリされたときだけ(negative cache TTLを？)増やすのはありか？
   Mark Andrewsのコメント via 加藤さん: サインしてるドメインを安くすればよい

8. クロージング
今後:
  夏にDNSSECも含めたイベント
  internet week