Title : DNS-WG 2011年活動報告 Author(s) : Tomohiro Ishihara(sho@c.u-tokyo.ac.jp), Yuji Sekiya (sekiya@wide.ad.jp) Date : 2012-01-03 2011年3月の WIDE 春合宿において、DNS WG のミーティングが開催された。この のミーティングでは、以下の事項に関して話し合いが行われた。 - DNSSEC 検証の普及状態の調査法 - JP ゾーンの鍵運用と DNSSEC によるトラフィックの変化 - Response Policy Zones(RPZ) 2.0 また、2011年9月の WIDE 秋合宿にて開催された DNS WG ミーティングでは、以下につ いての発表が行われた。 - DNS浸透都市伝説の正体 - BIND 9 のおとしかた: Reproduction of BIND 9 security problem - DNSサーバのユースケース調査 以下に、それぞれの合宿にて行われたミーティングの議事録を、活動報告とし てまとめる。 =================================== + DNSSEC 検証の普及状態の調査法 JPRS の藤原氏より、DNSSEC 検証機能があるクライアントの調査方法および結 果について報告があった。ここでは、 DNSKEY の問い合わせを行うクライアン トをDNSSEC 検証機能があるクライアントと定義づけた。調査方法であるが、ホ ストベースによる集計とクエリベースによる集計を行い、ホストベースは DNSSEC 検証機能があるクライアント、すなわち DNSKEY の問い合わせを行うク ライアントとその他のクライアントの比率による集計、クエリベースはそれぞ れのクライアントが出す問い合わせの量の比率による集計である。集計対象の データセットとして、JPRS が運用している JP ゾーンのサーバにおけるパケッ トキャプチャおよびクエリーログを利用した。 集計結果として、ホストベースでは 0.17% のサーバが DNSSEC 検証機能があり、 クエリベースでは 6% のクエリが DNSSEC 検証機能があるリゾルバによるもの であった。 =================================== + JP ゾーンの鍵運用と DNSSEC によるトラフィックの変化 JPRS の民田氏より、JP ゾーンの DNSSEC 運用と、運用開始前後におけるトラ フィックの変化について発表があった。 JP ゾーンの運用についてであるが、JP ゾーンの DNSSEC 鍵はゾーン署名鍵 (ZSK)を一月ごとに、鍵署名鍵(KSK)を一年ごとに更新する運用となっている。 KSK はハードウェアセキュリティモジュールとして暗号化スマートカードを利 用している。スマートカードはコピーをして東京と大阪にそれぞれ安全に管理 されている。署名は基本として東京で行うが、災害時のバックアップとして大 阪でも署名が可能である。 JP ゾーンの DNSSEC 署名は段階的に行われ、2010/10/17 にJP ゾーンの署名を 開始し、2010/10/29 に ZSK の配布、2010/12/10 に DS レコードをルートゾー ンに登録、2011/01/16 より登録ドメインのDS レコードの受付を正式に開始し ている。 署名前後でのトラフィックの変化であるが、個々の問い合わせに対する応答パ ケットのサイズについて、サービス前は110オクテットを中心とした分布のみを 見せていた。サービス後では、110オクテット以外に、360オクテット、610オク テットを中心とした分布が増えていた。それぞれ、360オクテットの場合は NSEC3 レコードが１つ、610 オクテットの場合は NSEC3 レコードが２つ入って いる場合の応答と見られる。 また、TCP を利用するクライアントについても増加が見られ、JP ゾーンの署名 を開始した 2010/10/17 、および ZSK の配布を開始した 2010/10/29 にそれぞ れ増加を見せていた。 =================================== + Response Policy Zones(RPZ) 2.0 ISC の Paul Vixie 氏より、Response Policy Zones(RPZ) のバージョン 2.0 について説明があった。RPZ は、特定のドメイン名について名前解決を行わな いことでブロッキングを実現する機能である。RPZ 1.0 は 2010年よりDNS 実装 である BIND9 へのパッチとして提供されていたが、1.0 でのフィードバックを もとに 2.0 を開発を行う。 1.0 におけるフィードバックとしては、1)静的に設定されたもの以外で、DNS のトランザクション上異常と見受けられる対象について自動的に登録する機能 が必要、2)ISP よりカスタマー向けのサービスとして、外部のデータベースを 利用してブロッキングのルールをインポートする際に、それらの個々のルール についての扱いをカスタマーごとに変えられる機能が必要、というものがあっ た。 これらのフィードバックに対応する機能は RPZ バージョン 2.0 で実装され、 bindバージョン 9.8.0 への搭載が行われる予定である。 =================================== + DNS浸透都市伝説の正体 JPRS 民田氏より、「DNS 浸透都市伝説の正体」というテーマで発表が行われた。 DNS 浸透問題とは、あるドメインのゾーンを保持する DNSサーバの IP アドレ スを変更する場合に、ユーザに新しい情報が伝わらないことを指す。これは、 ユーザが利用するリゾルバ DNS サーバに、古い情報がキャッシュとして残って しまっている場合に発生する問題であり、この問題が発生すると、古い DNS サー バに対してアクセスに行くことで名前解決ができなかったり、キャッシュされ ている古い情報に基づいて Web サーバ等にアクセスに行ってしまうという現象 が発生する。 これを防ぐために推奨される DNS サーバ移行の手順は、次のとおりである。 (1) 新 DNS サーバの環境を準備 (2) 新旧両方の DNS サーバで、同じ DNS ゾーンデータを保持するように設定 (3) 上位 DNS サーバで DNS サーバの情報を変更する (4) ゾーンに存在するレコードの TTL 時間が経過するのを待つ (5) 旧 DNS サーバを落とす 上記の手順により、古いデータが期限切れとなるため、基本的に DNS 浸透問題 は発生しない。 DNS 浸透問題が発生するのは、ゾーン中に存在するレコード、例えばwww の A レコードの TTL が NS レコードの TTL より短い場合に発生する。NS レコード の TTL が切れる前に、www の A レコード TTL が切れることによって、再度 www の A レコードがキャッシュされる。その後、NS レコードの TTL が切れる ことによって NS レコードは新しい情報がキャッシュされるが、www の A レコー ドは古い情報が残り続ける。これによって、ユーザは古い www サーバにアクセ スし続けてしまうことになる。 しかし、この問題は既に過去のものであり、現在の BIND9 では、この問題を改 善するための機能が取り入れられている。具体的には、BIND 9.2.3 にて導入さ れているため、これ以降のバージョンの BIND9 を使っていれば、DNS サーバ移 行時の DNS 浸透問題は発生しないはずである。すなわち、DNS浸透問題は都市 伝説となっているはずなのである。 ところが、BIND 9.2.3 以前のバージョンにて運用されている DNS サーバが、 約33% 存在(JPRS調べ) し、そのためこの改善が有効に機能していない場合が見 受けられる。この原因の一つとして、RedHat Enterprise Linux 3 等、古いバー ジョンの BIND9 をサポートし続けているディストリビューションが存在するこ とがあげられるとの報告があった。 =================================== + BIND 9 のおとしかた JPRS 藤原氏から BIND9 に発見された二つの致命的なバグに関する報告が行わ れた。一つ目のバグは、BIND 9.7.3 にて修正された、named が固まってしまう バグである。BIND 9.7.3 の CHANGES に以下の記述が存在する。 2975. [bug] rbtdb.c:cleanup_dead_nodes_callback() acquired the wrong lock which could lead to server deadlock. [RT #22614] これは named がデータ処理の最中に、間違ったロックをしてしまうことによっ て引き起こされていたバグであり、ある程度の問い合わせがある環境にて頻繁 なゾーン変更を行うことで、再現することができたとの報告があった。 二つ目のバグは、named を落とすことができるバグであり、9.7.3-P3 にて修正された。 BIND 9.7.3-P3 の CHANGES に以下の記述が存在する。 3124.[bug] Use an rdataset attribute flag to indicate negative-cache records rather than using rrtype 0; this will prevent problems when that rrtype is used in actual DNS packets. [RT #24777] また、このバグは一度修正パッチが作成され、BIND 9.7.3-P2 に取り込まれて リリースされようとしたが、再度問題が発見されたため、BIND 9.7.3-P2 リリー ス自体が取りやめとなったことがうかがえる記述も含まれている。 --- 9.7.3-P2 released (withdrawn) --- 3123. [security] Change #2912 exposed a latent flaw in dns_rdataset_totext() that could cause named to crash with an assertion failure. [RT #24777] このバグに関して、実際に再現実験を行った結果、修正が入っていない BIND9 を落とすことができたという報告がなされた。実際の落とし方に関しては、セ キュリティ的な観点から明記することは避けるが、まだこの修正が導入されて いない BIND も多く運用されていると思われるため、早急な対応を促す必要が あることが確認された。 =================================== + DNSサーバのユースケース調査 JPRS 藤原氏から、DNS サーバの利用形態に関する調査結果と分類に関する報告 が行われた。これは、BIND 10 に取り入れるべき機能を決定するための予備デー タとしても使われる調査であり、DNS サーバの利用を、 - 小規模ユーザ + 企業ユーザ + 大学ユーザ + 個人ユーザ - DNS ホスティング事業者 - TLDs - ISPs - CDNs といった区分によって、それぞれの DNS サーバが有するゾーンの大きさやゾー ンの更新頻度、リゾルバサーバとしての機能などの観点から分類を行った。ま た、BIND 以外の実装を利用している場合も、どの区分にて BIND 以外の実装が 多く利用されているのかの分類を行った。 BIND10 に求められる機能の一例として、BIND9 にも存在する View 機能があげ られた。DNS ホスティング事業者や企業ユースにおいては、View を利用した Split DNS 機能が多く利用されており、クライアントの IP アドレスによって 制御を行なっている場合が見受けられるとの報告があった。例えば、内部ネッ トワークからの問い合わせは Privete IP アドレスを含む応答を返し、外部か らの問い合わせは Global IP アドレスのみを返答するといった使い方である。 これ以外にも、BIND10 に必要とされる機能の調査も兼ねて、DNS サーバのユー スケースに関する意見募集が行われた。