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 A 5分おき 結果  ともに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