Title: DNS WG2013年度活動報告書 Author(s): 石原知洋(sho@c.u-tokyo.ac.jp) 　　　関谷勇司(sekiya@wide.ad.jp) Date: 2013-12-27 1. はじめに DNS WG では、DNS における実装上や運用上の問題点に関して、情報共有とそれ を解決するための活動を行っている。2013年は春と秋の WIDE 研究会において ミーティングを開催し、情報交換を行った。本報告書では、これらのミーティ ングにおいて発表、議論がなされた事項についてまとめる。 2. 2013年WIDE 春合宿での議論まとめ 2013年3月の WIDE 春合宿において、DNS WG のミーティングを開催した。この ミーティングでは、以下の事項に関して発表と議論が行われた。 - DNS RRL (response rate limiting) : (ISC Paul Vixie )  - Report of BIND 10 trial in JP(JPRS 藤原) - Let's make new DNS servers(JPRS 藤原) - D-RootのIPv4アドレス変更とプライミングの概要(JPRS 森下) 2.1 Building DNS Firewalls With RPZ ISC の Paul Vixie が、BIND の新機能としてDNS-RRL(DNS Response Rate-Limiting) の発表を行った。 近年、DNS 応答を利用したDNS 増幅攻撃による DDoS が多く観測されている。 現在は主としてオープンリゾルバサーバが攻撃に利用されているが、原理的には送った クエリより大きなサイズの回答が返されれば増幅攻撃に利用されるため、 DNSSEC対応レコードなどのサイズの大きいレコードを有する権威サーバも 増幅攻撃として使われうる。 本機能はその対策として、権威サーバに回答レート制限を施すものである。 問い合わせがあった各クライアントのIPアドレスと問い合わせた名前を記録し、 それが一定以上繰り返された場合にはクライアントへの返答を差し止め、 定期的にTCP へのフォールバック要求を送信する。それにより、正規に 名前を引いているクライアントはTCPで問い合わせができる。 本機能により権威サーバが増幅攻撃に使われるリスクを減らすことができる。 2.2 Report of BIND 10 trial in JP JPRS の藤原より、メジャーバージョンアップをしたBINDバージョン10を 実験・評価したことについて報告があった。JPゾーンのレコード数は およそ2~3百万レコードほどであり、ゾーンは15分に一度ずつ差分ゾーン転送される。 本報告では、その環境を前提とした評価を行っている。 まず機能面では、1)BIND10は省略応答がないこと2)ネガティブキャッシュのTTLの 扱いがRFCに準拠していないこと（報告し修正済み）3)DNS Ok bit がセットされていた場合の 取り扱いがRFCに準拠していないこと（報告し修正済み）などが発見された。 次に性能面の評価では、クエリ応答のスループットと、ゾーン転送にかかる時間を 測定した。クエリ応答スループットは概ねBIND9より高い性能を発揮しているが、 ゾーン転送中にクエリ応答が止まる問題が発見された（報告し修正済み）。 また、ゾーン転送については、全ゾーン転送および少ない差分での差分ゾーン転送に ついては問題なかったが、差分が多い時の差分ゾーン転送は全ゾーン転送よりずっと 長くなってしまうという問題がみつかった。こちらはまだ修正されておらず、転送元に BIND9 を利用するなどの回避法を使う必要がある。 最後に、オペレーション面ではクエリログがないこと、リアルタイムにステータス確認を するのためのコマンド(rndc status)が無いこと、ドキュメンテーションが不十分なこと などが問題として挙げられた。 2.3 Let's make new DNS servers JPRS の藤原より、新しいDNS実装を作る提案があった。 DNS サーバは権威サーバ、キャッシュサーバなど、その働きによって 求められる性質が大きく違い、また規模によっても必要となる要求は変わる。 現在の有名なDNS実装であるBINDは全てに対応して作られているため、 状況によってはオーバースペックになる。 今回の提案ではDNSサーバを機能・規模によりクラス分けし、各DNSサーバに 求められる性能と、既存のDNS実装ではカバーしにくいクラスについての 分析について議論があった。 2.4 D-RootのIPv4アドレス変更とプライミングの概要 ルートネームサーバの１つであるDルートネームサーバのIPアドレス変更があり、 JPRS の森下より、その件について報告があった。 IPアドレス変更は2013年1月に行われ、アドレスブロックおよびAS番号も 変更となった。旧IPアドレスは半年の間は並行運用されるが、その後は新しいIP アドレスのみに変更になる。ルートネームサーバのIPアドレスは各DNS実装で 設定されているため、当該設定ファイルを変更するか、新しいバージョンのDNS実装を 利用する必要がある。 3. 2013年WIDE秋合宿での議論まとめ また、2013年9月の WIDE 秋合宿においても、DNS WG のミーティングを開催し た。このミーティングでは、以下の事項に関して発表と議論が行われた。 - Side effect of DNSSEC an increase of DS queries(JPRS 藤原) - An Measurement Study of Open Resolvers(NICT 高野) - 第一フラグメント便乗攻撃(JPRS 森下) - DNS on TCP(JAIST 井上) それぞれのミーティングにおいて、発表・議論された事項の概要をまとめる。 3.1 Side effect of DNSSEC an increase of DS queries JPRS の藤原より、JP ゾーンで観測されたDSレコード問い合わせの異常な増加について 説明があった。JPゾーンはすでにDNSSEC対応をしているが、実際にDSレコードを登録 している子ドメインはまだ一部である。しかし、全体量は多くないものの、DSレコードの 問い合わせが増加している傾向が観測された。 DS が存在しないドメインに対してDNSSEC対応リゾルバが問い合わせを した際には、DS を確認するために問い合わせる。DSが存在しないため ネガティブキャッシュされるが、そのキャッシュはゾーンのデフォルトTTL 時間しかキャッシュされないため、キャッシュ時間後に当該ドメインの名前が 問い合わされた場合は再びDSレコードが問い合わせされる。NSレコードなどの キャッシュTTLが十分に長くても、DSレコードのネガティブキャッシュの長さに 依存してDSの再問い合わせが発生していることがわかった。 本現象の回避策として、ダミーDSレコードをすべての子ドメインに追加する 提案があった。本件はIETFにおいても発表し、ダミーDSを挿入することの是非を 議論する予定である。 3.2 An Measurement Study of Open Resolvers NICT の高野より、オープンリゾルバの調査について報告があった。 調査方法は、すべてのIPアドレスに対して再起付き問い合わせを送るもので、 結果として300万台のDNSサーバと、250万台のオープンリゾルバが発見された。 オープンリゾルバは中国・アメリカ・メキシコに多く存在しており、 また、多く迷惑メールが送られてくるドメインのアドレスブロックに属している ものが多く見つかった。 3.3 第一フラグメント便乗攻撃 JPRS の森下より、UDP のフラグメンテーションを利用した新しいDNS詐称攻撃についての 報告があった。DNS のパケット同定に利用するポート番号、DNS ID などはパケットの 先頭部分にしか存在しないため、フラグメンテーションが起こるサイズのDNS応答の 場合、通常のパケットより簡単にDNS詐称が可能となってしまう。 また、この攻撃は対象のIPスタックで破棄されてしまうため、パケットモニタリングを していない限り対象のOS上で観測することはできない。 DNSSEC を利用した場合、本攻撃をDNS詐称に使われることは防げるが、DNSSEC署名 されたフラグメントパケットに対して攻撃された場合、サービス不能攻撃としては 有効になる。 対策としては、IPの仕様を変えフラグメントされたIPパケットに対して パケットを同定できる情報を埋め込むか、応答パケットにフラグメント位置を予測 されないようにランダムな情報を埋め込む方法が提案された。 また本質的にはフラグメンテーションが起きないようにアプリケーション層でデータグラム サイズを調整することが必要であるが、少なすぎる数を利用した場合TCPへの フォールバックが多く発生するという副作用もある。 3.4 DNS on TCP 北陸先端大の井上から、DNS にTCPを利用した場合の影響についての発表があった。 DNSをTCPにした場合、初期ハンドシェイクのための応答時間増加がまず考えられる。 TCPにはいくつかの拡張が考えられ、応答時間の改善が図られているため、新しいOSなどに 実装されているTCPを利用した場合にUDPと比べてどの程度の応答時間変化が あるか、シミュレーションによって推定をおこなった。 通常のTCPを利用した場合、TCPの応答時間はUDPの1.8倍ほどになるが、 TCP FastOpen オプションを利用した場合には1.5倍程度に抑えられた。 また、TCPマルチプレクサを利用した場合には、1.3倍程度となり、 UDP を利用した場合とプロトコル的には大きくは変わらない時間で 対応できることが推定された。 4. おわりに 2013年度は、大規模ドメインでのDNSSEC の運用を通じて得られた知見について いくつか報告があったことと、OpenResolver による攻撃とその対策についての議論が 多く行われた。DNS wg ではこれら２点について、今後も重点的に調査および情報交換を おこなっていく。