-------------------------------------------------------------------------------- 内部ネットワークで利用している名前との衝突 (JPIX 石田) -------------------------------------------------------------------------------- ■名前衝突の背景 ・新gTLD導入に伴いドメインが増加した事により、 旧来の内部名と衝突するが予想される。 ■想定される衝突 ・想定される衝突についての情報提供歓迎 ■パブリックDNSから見える状況 ・Distribution of TLD Requests by Category →今回の新gtLDで、文字列として申請されているものは3%程度 ■新gTLDで申請中の文字列に対するルートDNSでの検索ランキング 1位 → home(952,944) 2位 → corp(144,507) ■想定される影響 ・SSACメンバーの見解 社内ネットワーク利用については見えておらず、想定される問題も 洗い出しきれていない可能性が高い ■ICANNのこれまでの対応 ・調査レポート ・リスク回避計画の発表 High Risk → .corp .home Midium Risk → 20% Low Risk → 80% ■決定している対策 ・High Risk → 委任無期限保留 ・必要な人に情報が届いていないので、JPNICで専門家チームを構成して対応予定。 ■情報提供への協力 ・名前衝突の問題事例 ・現在とられている対策に対するコメント ・周知のあり方、情報提供についての要望 ■報告先 ・ルートDNS、大規模なRecursiveサーバ、委任されているTLDの権威DNSに関する情報 → namespacestudy@jasadvisors.com ・本件に関するMl → https://lists.dns-oarc.net/mailman/listinfo/collisions ・名前衝突の問題に関する報告先 → http://www.icann.org/en/help/name-collision ■QA なし -------------------------------------------------------------------------------- とあるゾーンの親子崩壊(設定ミス)(BBT 大本) -------------------------------------------------------------------------------- ■amazone.bbtower.netの誕生 ・bbtower.netは検証環境向 ・Amazon　route53を利用し、新ゾーンを登録 ■挙動があやしい ・Route53に登録したAレコードが引けたり引けなかったりする → 何回に1度NXDOMAINになる ・SOAを引いてみると、Route53以外のサーバ(bbtwore.netのマスターサーバ)が 答える場合がある。 ■原因は ・amazone.bbtower.netはbbtower.netと別ゾーンとして運用している。 (ゾーンカットして、別ゾーンとして記述している) ・Route53への委譲を示したNSレコードは、amazone.bbtower.netのゾーンに記載 ・bbtower.netのゾーンには、amazone.bbtower.netのNSレコードは登録されていない → 親子の絆を結んでいないので、親に聞いてもNXDOMAINと答える → amazone.bbtower.netのゾーンを同居している事になっているので、 直接ns01.bbtower.netにNSを引くと、amaoneのNSを返す。 ■なぜこうなった？ ・社内検証用ドメインのため、サブドメインに対してwebUIを利用して利用者が 任意にRR登録できる状態になっている。その仕組みの中で指定ドメインを 別ゾーンとして切り出してアクセス権限をコントロールしていた。 ・リカーシブサーバがroute53のNSレコードをキャッシュしていた場合は、 正しい答えが返る。 → つまり隠し子 ■QA c.昨年DNS SummerDaysランチセミナーで話した委任問題の話に似ている。 AuthoritySection経由で入ると引けて、上から辿ると引けない 状態になったのかも。(JPRS 森下) c.そのように思う(大本) c.権威にdig書くときは、＋norecの記述をつけてほしい(JPRS森下) q. キャッシュは切り替えたりしたのか？() a. しなかった(大本) -------------------------------------------------------------------------------- オープンリゾルバ確認サイトの公開について(JPCERTコーディネーションセンター 小林) -------------------------------------------------------------------------------- ■確認サイトを2013年10月31日に公開 ・Web URI http://www.openresolver.jp ・コマンドライン版 wget の場合: $ wget -qO - http://www.openresolver.jp/cli/check.html curl の場合: $ curl --location-trusted http://www.openresolver.jp/cli/check.html ■デモ 1.サイトにアクセス 2.同意を行う 3.結果確認 (OK→ 緑、オープンリゾルバーの疑いがある→ 赤) ・判定された場合の対応について同ページに記述している ・オープンリゾルバーと判定された機器は、リンク先のJPCERT/CCに連絡してほしい ■動作確認の概要 1.ユニークなホスト名を名前解決する 2.返答されたIPアドレスにWebアクセス 3.各IPアドレスに対してcheck.openresolver.jpを問い合わせる → 確認結果を1時間キャッシュする ■アクセス傾向 ・平日に多い ■利用ブラウザ傾向 ・会場への挙手によるアンケート IEを常に使っている人→ いない FireFox→ 半分ぐらい Crome→ 半分ぐらい ・統計 fifrefox → 30% Crome → 30% msie → 19% ■QA q.キャッシュするということは、1時間以内だと反映されないのか(BBT伊藤) a.そうである。改善に向けて今後検討する。(小林) c.そこは使う人と認識が共有できていればよいと思う(BBT伊藤) c.利用状況をイマイチだという事だが、確認しようと思わなくても確認できるように、 ブログパーツを作ってみてはどうか。(NTTCom 高田) c.検討する(小林) q.バージョン6対応の検討はないのか？ (WIDE加藤) a.小規模から始めようとの事で現在はv4のみ。今後検討する。(小林) q.Webインターフェースが同意する部分があるが、不要ではないか？ CLIでは同意しない。(JPRS 米谷) a.他でも指摘が入っており、修正する段階に入っている。(小林) c.CLIの英語文面の表現を改善してほしい。(JPRS 米谷) q.Buffalo、Ellecomの情報は入らないのか？(龍谷大学) a.多くの人がそれらの当該ベンダー製品多く使われている事は認識しているが、 今は正式にお答えできない。(小林) c.UIについて、テストボタンを一番上にもってきてもいいと思う(JPRS 阿波連) q. googleのパブリックDNSなど ※抜けあり※ (神明) a.状態を見極めて対応したい(小林) c.DNS Serverとして動いていないのにオープンリゾルバーとなっているものが あると思う。Webカメラなどがそれにあたり、現状ではチェックできないと思うが、 次の段階で検討いただけるとうれしい。 c.検討する。(小林) -------------------------------------------------------------------------------- Free BSDでUnboundを使ってみる(力武) -------------------------------------------------------------------------------- ■なぜUnboundか？ ・BINDサポートが大変 → リリーススケジュールとの調整が難しい ・DNSSEC validationの効率的実装をしたい ■PortsからUnboundもBINDも無くなることは無い ・DefineするとPrivateLibになる実装はよくない。 ■実際の設定は？ ・/etc/rc.confに以下を追加 local_unbound_enable="YES" ■Unboundのデフォルト設定で困ること ・man 5 unbound.confを読む必要あり ・プライベートアドレスの逆引きはデフォルトではNXDOMAINを返す ・ローカルゾーンを定義する必要あり ■Unbound+ldns他の変化によるメリット ・OpenSSHでSSHFP RRのvalidationができるようになった ・local_unboundをenableする事で好きなだけforwarderの相手が増やせる ・DHCP等の動的設定に自動対応 ■FreeBSD 10の開発状況 ・おそらく2013年内にリリースする予定 ・基本的には安定している ・問題は、libiconvがCitrusベースとなった為GNU依存のISO-2022-JPなどの 自動変換が動作しないこと ■要約 ・FreeBSD 10からはUnbound+ldnsが標準装備 ・今までのPortsとは干渉しない ・プライベートアドレスだとそれなりの設定は必要 ・FreeBSDの中では/usr/lib/privateを作ってややこしくなっているが、 それは今後を考慮した実装変更 ■QA c.10に移行してメールトラブルが起きそう※抜けあり※(WIDE加藤) c.本家はGNUを捨てると言っている※抜けあり※(力武) q.(神明) a.(力武) -------------------------------------------------------------------------------- An analsis of DITL root data and comparison with JP data (JPRS 藤原) (DITLのルートデータとJPデータの比較) -------------------------------------------------------------------------------- ■Analysis method ・Cで書かれたプログラムがpcapファイルを読む ・IPアドレス毎に問い合わせをカウントする ■Details of 2013 Root Dataset 1 ・トータルで291億パケットを取得 ・TCPの割合は0.49% ■Details of 2013 Root Dataset 2 ・A〜Mの比較において、Aに来るクエリ元IPアドレス数が多い クエリ数は均等に来ているような来ていないような ■Number of IP addrs seen at root 48h ・ENS0、Do=1はゆっくり広がっている ・30％のIPアドレスはnon-existentTLD queries ・24％のIPアドレスはNS queries ■Number of queries send from each address, at root, 48 hours ・48時間で8千万〜1億クエリ送っている ・800万アドレス中の50万アドレスが、1日に1000より多く送っている ■Number of queries from top 50 addresses at root, 2013 ・No.1〜4は同じ ・No.5〜9は存在しないものg社のもの？ ■UDP transport analysis ・UDP Checksum オフのクエリは4千万で0.14%程度 ■EDNS0 udp payload size ・EDNS0は4000、4096が多い ・ ■Comparison of Root and JP 48 hour data ・JPでは200万、Rootでは850万 ・.JPクエリ to Rootは150万 ■DITL 2013 IP address coverage ・Rootで見つけられていないIPアドレスが29%程度ある ■Number of queries sent from each address, 48 hours, 2013 ・JPとRootでは一桁違うが、傾向は同じ ■Conclusion q.(力武) a.(藤原) -------------------------------------------------------------------------------- Side effect of DNSSEC an increase of DS queries (JPRS 藤原) (JP DNSにおけるDSクエリ急増について) -------------------------------------------------------------------------------- ■Ratio of DS queries seen at JP 2 of 7 servers, 24 hours data ・赤がDNSSEC バリデータの数 ・黒はDSクエリの数 ■Number of DS queries (2 of 7 JP servers) ・DSクエリが増えたタイミング + 2011/1 JPがDSを始めたとき + 2011/12 大きなISPがバリデーションをイネーブルにした + 2013/4 2011/12にイネーブルにしたISPが増強した。 ■A part of query log for a popular name from one IP address, 2 of 7 JP servers ・1つのアドレスが15分程度の単位でgoogle.co.jpのクエリを送ってくる → NCACHEのTTL(900秒)と同じ ■Reason of DS queries increase (2) ・バリデータは、1日に1回non-DSクエリを投げる。 また、1日に95回(86400/900-1)のクエリを送る → 合計96回 ■Evaluation on existing implementations (BIND 9 and Unbound) ・5分に1回送るプログラムを書いて実験 → 結果 + BIND9、UnboundはValidatorを送る + 15か20分間隔でunsigned delegationのDSクエリが飛ぶ ■Possible situations in the future ・将来的にJP DNSサーバーへの問い合わせが96倍になる可能性がある ■Possibly affected domains ・有名なところはサインされているので、Rootへの影響は少ない。 ■No good countermeasures ・あきらめて全てのDSクエリを受け入れ、基盤を強化する ・DNSプロトコルを書き換える ・全ての登録者にサイン ・有名な名前のTTLを伸ばす ・900→ 10800にすると8倍までに減らせる ・ダミーDSをunsigned delegationsに登録する +dummy DSはコントロールできる → Do you have other ideas ? ■QA c.DS値は最近86400ではなくなったので、96倍ではなくなった。(JPRS 森下) c.12倍になる。(藤原) q.DSレコードがクエリされたときだけネガティブキャッシュを増やすのはどうか(東) a.細かく検討してみないと分からない(藤原) c.「サインしているものは安くすればよい」というマークアンドレスのコメントは 紹介するに値する(WIDE 加藤) -------------------------------------------------------------------------------- 次期イベント開催について (JPIX 石田) -------------------------------------------------------------------------------- c.夏にDNSSECを含めたイベントを開催したい。 InternetWeekとあわせて年2回としたいがよいか。(JPIX 石田) → ★拍手多数にて可決★