Title : DNS-WG 2012年活動報告 Author(s) : Tomohiro Ishihara(sho@c.u-tokyo.ac.jp), Yuji Sekiya (sekiya@wide.ad.jp) Date : 2013-01-09 2012年3月の WIDE 春合宿において、DNS WG のミーティングを開催した。この ミーティングでは、以下の事項に関して発表と議論が行われた。 - Building DNS Firewalls With RPZ - Bogus authoritative servers interfere DNS64 - Ghost Domain Name - Number of possible DNSSEC validators seen at JP, 1 year difference - DNS Server Diversity また、2012年9月の WIDE 秋合宿においても、DNS WG のミーティングを開催し た。このミーティングでは、以下の事項に関して発表と議論が行われた。 - A method of PCAP file evaluation and preliminary results of JP DNS query measurement - DNS Caching Server Performance Improvements: Initial Research and Ideas - DNSにおける委任の定義と親子同居問題 - DNSSEC validators where and how many? 以下に、それぞれの合宿にて行われたミーティングの議事録を、活動報告とし てまとめる。 =================================== + Building DNS Firewalls With RPZ ISC の Paul Vixie が、BIND の機能である RPZ(Response Policy Zone) を利 用した DNS ファイアウォールの構築について発表を行った。DNS ファイアウォー ルは通常のネットワークファイアウォールのように、DNS の問い合わせや応答 をルールに従って通過、破棄、書き換えを行うものである。RPZ はこれらのルー ルをゾーンの形として保持し、通常の DNS ゾーンと同じように問い合わせ・ゾー ン転送を行なって共有することができる。現在の普及状況としては、BIND に実 装されているが、他の DNS 実装にはまだ実装されてない。標準化は IETF では なく、ISC が主導して行なっている。 =================================== + Bogus authoritative servers interfere DNS64 東大の石原が、合宿で実施した NAT64 + DNS64 による IPv6 環境実験において、 一部の権威サーバの動作によって DNS64 で問題が発生した件について発表を行っ た。DNS64 サーバは、IPv6 の AAAA レコードが無いホストに対して、IPv4 の A レコードを元に変換した IPv6 アドレスを答える機構を持っている。このた め、DNS64 は AAAA レコードの問い合わせ後に A レコードの問い合わせを行う が、一部の DNS 実装（主に DNS を利用した負荷分散装置など）では、 1) A レコードが存在するにもかかわらず、AAAA の問い合わせに対して NXDOMAIN を返す 2) AAAA の問い合わせに対して無効なレコードを返答する （1,2 ともにDNS の仕様違反である）などの動作をするため、DNS64 が正しく 動作せず、サイトにアクセスできない等の現象が発生していた。本問題につい てはインターネットドラフトとしてまとめ、IETF に提出を行なった。 =================================== + Ghost Domain Name JPRS の森下が、幽霊ドメイン名問題についての発表を行った。幽霊ドメイン名 問題とは、ある DNS ゾーンを親ゾーン上から削除した際に、削除されたゾーン を長期にわたって名前解決可能な状態に仕向けられるという問題である。この、 レコードを消したのに名前解決可能にさせられているドメイン名を、幽霊ドメ イン名と呼ぶ。発表時点で、ほとんどのキャッシュサーバがこの問題を抱えて おり、元論文である "Ghost Domain Name: Revoked Yet Still Resolvable, Jian Jiang, Jinjin Liang, Kang Li, Jun Li, Haixin Duan and Jianping Wu, Proceedings of the 19th Annual Network & Distributed System Security Symposium" では、70% のオープンなキャッシュサーバにおいて幽霊 ドメイン名を一週間以上保持することが可能であったと述べられている（報告 書執筆時点では多くの実装で修正がおこなわれている）。幽霊ドメインが発生 する仕組みとしては、キャッシュサーバ上でキャッシュしたレコードの書き換 えを検知した際に上書きするという動作を悪用している。すなわち、すでに削 除された子ドメインの権威サーバ上で、NS レコードの内容を変えつつキャッシュ サーバに対して問い合わせを送り続けることでゾーンの NS レコードのキャッ シュを強制的に保持させ続ける。これによって、ターゲットとなったキャッシュ サーバのクライアントは当該ドメイン名を親ゾーンから削除されたにもかかわ らず、キャッシュの有効期間を超えて名前解決ができてしまう。 本問題の解決法として、キャッシュサーバ実装を幽霊ドメイン名問題が出ない ものに取り替える、もしくは定期的にすべてのキャッシュをクリアする、など が紹介された。 =================================== + Number of possible DNSSEC validators seen at JP, 1 year difference JPRS の藤原が、JP に対して問い合わせをしてきたキャッシュサーバ中で DNSSEC 検証を行なっているものの数に関する調査結果について発表を行った。 調査方法としては、JP ゾーンの DNSKEY レコードを問い合わせてきた IP アド レス、および JP ゾーンのサブドメインの DS レコードを問い合わせてきた IP アドレスの数について集計した。調査結果は、2012年2月次点で 10000 の キャッシュサーバが DNSSEC 検証をしていると推測された。DNSSEC 検証を行う キャッシュサーバは増加傾向にあり、特にルートゾーンが署名された日からは ほぼ線形に増加傾向にあることが観測された。 =================================== + DNS Server Diversity JPRS の藤原が、複数種の DNS 実装を利用することについて発表ならびに提案 を行った。DNS は基幹サービスであるため、ネットワーク接続性提供には欠か せないが、それに対して DNS 実装で致命的なバグ・脆弱性が見つかることは多 い。同一種類の DNS 実装だけを利用していると、全ての実装を一度に変更する 必要があり、かつゼロデイ攻撃などに対して脆弱となる。複数種類の DNS 実装 を利用すれば、これらの脅威について軽減することが可能である。 また、そのような多種類の構成を行うにあたり、必要なサーバおよびクライア ントの設定についての発表があった。また、以前の DNS クライアントでは、複 数種類の DNS サーバをリゾルバに指定した場合に、うち一つの DNS サーバが サービス不能になった際に 30 秒程度待たされることがあったが、最近の主要 OS の DNS クライアントではそのような待ちは発生せず、一つでも答えられる DNS サーバがあった場合には通常通りの速度で答えが返ってくるという調査結 果についても述べられた。 =================================== + A method of PCAP file evaluation and preliminary results of JP DNS query measurement JPRS の藤原が、PCAP の解析に利用している C ライブラリの紹介とそれを利用 したデータ解析結果について発表を行った。JPRS では定期的に一定期間の全ト ラフィックの収集と解析を行なっている。このような解析を行うツールとして PacketQ というソフトウェアがあるが、トラフィックは生データの状態で 2TB あり、PacketQ を利用した場合には解析に多くの時間とメモリが必要となる。 そこで、軽量かつ並列で動作可能な C 言語による解析プログラムを開発した。 本解析プログラムによっておよそ 10TB 程度の DNS トラフィックの解析が1日 程度で、かつ現実的なメモリ使用量で実施できるようになった。 =================================== + DNS Caching Server Performance Improvements: Initial Research and Ideas ISC の神明が、キャッシュサーバのパフォーマンス改善に関する発表を行った。 BIND9 はキャッシュサーバのパフォーマンスが高くなく、ISP などで利用する 際に問題になる場合があった。BIND10 はキャッシュ機構について根本から見直 し、スループット、レイテンシ、メモリ利用などの改善を図った。 設計にあたり、まず理想状態のスループットの算出をおこない、また過去の実 トラフィックデータから、実世界での DNS レコードのキャッシュ TTL 傾向に ついて調査を行なった。 結果として、DNS レコードの問い合わせはよく知られているようにベキ分布で あり、実データでは全体のうち 1/30 の種類のレコードが、全体の 80% を占め ていることがわかった。そのため、一部データを「より早い」キャッシュに入 れるなど、キャッシュを多層構造にすることで性能の改善が図れる可能性があ る。また、グルーレコードをキャッシュとして保持することで、キャッシュの サイズは実データ上では 18.2% 上昇するが、外に出す問い合わせを 13% 削減 できることもわかった。加えて、98% のトラフィックは 1)NOERROR の返答 2)NXDOMAIN の返答 3)NS のみの返答（名前解決途中のゾーンでの回答）の３タ イプのどれかとなるため、ある種の返答の予測もできるであろうことも報告さ れた。 今後はこれらの事前調査を元に、BIND10 のキャッシュ性能改善について継続し て開発を行なっていく予定であるとの報告がなされた。 =================================== + DNSにおける委任の定義と親子同居問題 JPRS の森下が、DNS の親子同居問題について発表を行った。親子同居問題とは、 親ドメインと子ドメインが同一のネームサーバ上で管理されている時に発生す る問題である。 親ドメインと子ドメインが同一のネームサーバ上で管理されるシナリオとして は、共用 DNS サーバなどにより、さまざまな顧客ドメインの DNS 権威サーバ を一つのサーバ上にてサービスをしている場合が考えられる。 例えば特定のドメイン（例：example.org）の管理を共用 DNS サーバに委託し ている場合に、別の悪意ある顧客が同一の共用 DNS サービスに対して xxx.exmaple.org というドメインの管理を委託することで、本来ならば委譲さ れていないドメインのレコードを乗っ取ることが可能となってしまう。これは、 親ドメイン上でそのレコードの有無にかかわらず可能であるため、 www.example.org などのドメイン名を乗っ取り、悪用することも可能となる。 この問題は DNS プロトコルの仕様上の問題であり、対処方法としてはDNS プロ トコルを改変して親から得たゾーン情報を記述することで、正しいクライアン トが意図したゾーンの情報取得が行われるようにする、などが挙げられた。ま た、共用 DNS サービス業者が登録時に正当に移譲されているかをチェックすべ きでは、等の意見も寄せられた。 =================================== + DNSSEC validators where and how many? NII の福田が、トラフィック解析による DNSSEC の普及状態の調査について発 表を行った。トラフィック解析による受動的な調査と、DNSSEC トラフィックを 寄せられたホストに対するプローブによる能動的な調査の二種類の調査を行なっ た。 データ解析については、JP のネームサーバ上に寄せられた 2011年6月、2011年 12月2012年4月に測定したトラフィックそれぞれ2日分を利用し、主に JP の DNSKEY レコードおよび DS レコードの問い合わせに着目をして解析を行なった。 全体的な傾向として、DNSSEC の問い合わせを送ってきた対象は、2011年6月か ら2012年4月までの間に IP アドレスベースで 0.4% から 1.1% に、AS 数ベー スで5.9% から 11.1% に増加していた。 各AS での DNSSEC 対応ホスト数はベキ法則に従っており、90% の AS では一つ も DNSSEC 対応ホストは存在せず、逆に DNS のクエリを出すホストが多く存在 する一部 AS では、多くの DNSSEC 対応ホストが存在していた。DS レコードの 問い合わせについては、ほとんどが重複しており、これはDSレコードおよびネ ガティブキャッシュの TTL が短すぎることが原因と推測される。 また、DNSKEY/DS レコードの問い合わせを送ってきた DNS クライアントに対し て問い合わせを送ることで能動的な調査を行なった。対象のクライアントのう ち、応答があった、すなわちオープンリゾルバとおもわれるホストは全体の 10% であった。その中で、正しく DNSSEC の検証を行なっているホストは 38%-50% となり、DNSSEC に関連するレコードを問い合わせていても、必ずしも DNSSEC 検証を正しくできていないホストが多いことがわかった。 DNSSEC 検証の位置の推定についても報告があった。DNSSEC の検証はキャッシュ サーバで行う場合と、各 DNS クライアントで行う場合が考えられる。両者を区 別する方法として、DS の問い合わせにおける 全レコードのうち DS レコード が占める割合を調べ、その割合が 4% 以下である場合には各 DNS クライアント が、4% 以上である場合はキャッシュサーバがそれぞれ DNSSEC 検証をしている と推測する。評価用データでこの推定方法を評価したところ、正確度は 80% 超 であった。この推定方法でデータを解析したところ、70% の DNSSEC レコード を問い合わせてきたホストは、DNSSEC 検証可能であると推測された。