児童ポルノのブロッキングと「DNS RPZ」/悩ましい「DNS運用の現実」


 東京・秋葉原の富士ソフトアキバプラザで開催された「Internet Week 2011」で11月30日、毎年恒例の「DNS DAY」が行われた。このプログラムは、DNS(Domain Name System)に関する課題を共有し、今後の方向性を議論するためのもの。今回は、その中からDNSブロッキングに関する話題として株式会社インターネットイニシアティブ(IIJ)の島村充氏による「DNS RPZ」の部分と、株式会社日本レジストリサービス(JPRS)の民田雅人氏による「DNS運用の現実」をお伝えする。

株式会社インターネットイニシアティブの島村充氏株式会社日本レジストリサービスの民田雅人氏

DNSブロッキングに対する悩み

 インターネットの世界には、違法あるいは有害とされる情報やサイトが数多く存在する。児童ポルノ、著作権法に違反するコンテンツ、スパムやフィッシング、マルウェア配布に関するもの。これらの問題からいかにユーザーや権利者を守るのか。動機はともかくとして、その実現には数多くの問題を含んでいる。現在、違法情報対策としてDNSブロッキングが使われているが、そもそもDNSでドメイン名の名前解決をブロックすることが適切なのかはいまだに議論が続いているのが実情だろう(法的な視点や運用に関する考え方などについては、本誌11月17日付記事「“児童ポルノ=ブロッキング対象”ではない? 閲覧可能なままの画像も」に詳しいのでそちらをご覧いただきたい)。

 ここで、DNSブロッキングに関して簡単に復習しておきたい。DNSブロッキングでは、ユーザーが利用するキャッシュDNSサーバーに特定のドメイン名に対する名前解決要求が来ると、その応答として「その名前は存在しない」という答えを返すか、特定の警告サイトなどのIPアドレスを返すというように、本来のDNS応答とは異なったものを返すことになる。日本では現在、一般社団法人インターネットコンテンツセーフティ協会がブロックすべきURLやドメイン名をリスト化し、会員であるISPへ提供。そのリストに基づきISPがキャッシュDNSサーバーに反映させる方法が採られている。

 ただし、この方法(ブロックしたいドメイン名に対して、応答を上書きするような設定を行う)では、それぞれのキャッシュDNSサーバーで個別に設定する必要があり、DNSの設定ミスなどによる間違ったブロックやブロック漏れが発生するかもしれない。キャッシュDNSサーバーの運用者にかかる負担が大きく、実際のブロックで問題が起こった場合の責任の所在が分かりにくいというのは現場の大きな悩みになっているものと推察される。

 IIJの島村氏の発表「キャッシュDNSサーバーとフィルタリングの実例」はIPv6に関するAAAAフィルタリングとDNSブロッキングに関する話題を扱ったものだが、その中で紹介された「RPZ(Response Policy Zones:応答ポリシーゾーン)」は、この問題を解決する可能性を秘めたものだ。

「DNS RPZ」とは何か?

 「DNS RPZ」とは、ISC(Internet Systems Consortium)により開発されているBINDというDNSサーバーの一機能である。簡単に言ってしまうと、キャッシュDNSサーバーでブロッキングを簡単に行えるようにBIND 9.8.0以降で実装される機能の名称であると思えばよいだろう。現在のゾーン上書き方式では情報反映後にゾーンのリコンフィグ(再構築)が必要だが、RPZを使用すると、ブロックリスト作成団体が提供する情報を「ゾーン転送」というDNSの機能を使って得ることができるようになり、その変更をリロード(再読込)という形で反映できるようになる。

RPZの概要
RPZのメリット

 島村氏は、「ゾーン上書き方式だとゾーンの追加や削除があり、リコンフィグを伴うのでドキドキする。RPZだとゾーンのリロードで済むため、精神的に楽」だとし、管理に対する負担の軽減が大きいことを説明の中で述べた。

「DNS RPZ」の可能性

 また、島村氏は、「RPZは、セキュリティポリシープロバイダーから情報のゾーン転送を受ける(複数から受けることも可能)ことで、ブロックすべき対象をキャッシュDNSサーバーに迅速に反映させることができる点も大きなメリットである」とし、さらに「ポリシーの作成者と運用者の責任分界点も明確になる」ということも述べている。

RPZにおける連携

 これは、例えばブロックすべき対象をブラックリストのような形で作る組織と、そのブラックリストを使って実際の運用をする組織にとって重要なポイントである。利用者から見ても、自身のサイト、もしくは自身が訪れようとしたサイトがブロックされたということであれば、そのブラックリストを作った組織に交渉をすればよい。キャッシュDNSサーバー運用者は、その動作だけを保証すればよく、ブロックすべき対象を個々に意識せずに済む。このような明確さは、複雑な運用をできるだけ単純化するためにも必要なのではないだろうか。

 ただし、現状では「動作検証でFirefoxのDNSSEC検証拡張を使っていたらBINDが落ちた」(島村氏)といったように、まだまだ安定して運用できる状態にはない。この原因を「ブロックしているドメイン名のRRSIGを引くと落ちる」と特定し、バグレポートを出したらすぐ直ったことなども示されたが、その後もRPZに関するバグが見つかるなど正式採用にはまだ不安があるため、現在では実績のあるゾーン上書き方式を採用していることなどが述べられた。

 ISCでは、RPZをセキュリティ組織、他のDNSソフトウェア開発者などと協力し、共通に使えるフォーマットにしたいとしている。コンセプトはよいので、そうなれば、将来的にこの技術は広く普及することになるかもしれない。

RPZに対する感想

悩ましいDNS運用の現実

 DNSを安定運用するための情報として比較的話題になるのは、さまざまな工夫やツールの駆使といった実運用に即した内容であることが多い。だが、その前に、問題のあるDNSソフトウェアを使っていたり、必要な機能をサポートしていないバージョンが使われていたりすることも決して少なくはないのが実情だろう。JPRSの民田氏の発表は、現状のDNSサーバーがどのような状況にあるのかを、JPRSが管理しているJP DNSの1つであるa.dns.jpに来るクエリから分析した結果を基に考察したものである。

対策状況の変化(問い合わせに対する割合)
対策状況の変化(IPアドレス数で状況不明のものを除いた割合)

 これら一連のグラフは、2008年の夏に起こったDan Kaminsky氏によるキャッシュDNSサーバーへの新たなる毒入れ攻撃手法の発見以降に行われた対策がどのようになっているかを調べた結果である。この調査は、1時間当たりのポート番号の変化で判定しており、「状況不明」については、「おそらく、DNSサーバーではなく、誰かがdigコマンドのようなものを打った結果ではないか」(民田氏)ということであった。問い合わせに対する割合では約93%。状況不明のものを除いたIPアドレス数に対する割合では約87%であることが述べられ、その上で、今年(2011年)11月の状況を見ると、対策が取られた2008年10月当時に比べて徐々に改善している様子が見てとれるとしている。

 ただし、DNSサーバーに対してパッチを当てたものが増えたのか、それともサーバー機器の更新によって変化が起きたのかは不明であるようだ。IPアドレス数で明らかに未対策が10%前後あるということは、ホスト数に換算すると調査対象で9万台程度という数字になる。未対策のサーバーは、その後に発見された脆弱性に対しても未対策のままである可能性が高く、潜在的に問題を抱えた状態で運用されていると考えることができる。

いまだに数多く残る古いサーバー

 続いて、DNSサーバーのシェアと、その説明が行われた。2011年8月現在の調査では、BIND 9が約40%、BIND 8が約2%で、不明が57%あったことなどが示されている。不明が多いのは、問い合わせで知らない文字列が返ってきたり、そもそも応答が無いためであり、感覚的には半分くらいがBIND 9ではないかと感じていること、NSDやPowerDNSといったDNSソフトウェアはその他に含めたことなどが説明された。

DNSサーバーのシェア
BIND 9での割合

 民田氏は、この表を示しながら、「割合として出してしまうとゼロではあるが、いまだにBIND 4がこれだけあることに驚いた」としながら、「BIND 9.3が多い」という点に注目してほしいと述べた。BIND 9.3系は、例えばRedHat Enterprise Linux 5.xやSolaris 10に含まれているバージョンであり、ベンダーのサポートのみに頼って運用していることが多いと言える。

古いDNSソフトウェアは一掃すべき

 民田氏は、古いBINDの問題点を挙げ、古い実装がいつまでも使い続けられ、そのままになる現実を何とかしたいという。DNSSEC時代のDNSサーバーは新しい実装を使うことが必須とされるばかりでなく、仕様や実装にかかわる問題を抱えたバージョンや、脆弱性を抱えたままのバージョンを使い続けることの危険性を訴えて発表を終えた。

 会場からは、なぜ古いバージョンが使われ続けるのか、ディストリビューションを作っているところとの連携の可能性はあるのかといった点などから質問や発言が相次いだ。この場にいる多くのDNS関係者にとって、この問題がいかに大きいか。そのことをあらためて確認できた場であったことは間違いないだろう。


関連情報


(遠山 孝)

2011/12/2 20:22