JPNIC・JPRS・NTTデータの3社による共同発表となったのが「次世代DNSに関する研究開発」。DNSに関してはInternetの中核をなす技術の一つである一方で、セキュリティ的には意外と脆弱な点が多いことも多くの識者から指摘されているが、今回の研究ではそれらの弱点を解消すべく、様々な対策の研究発表が行われた。

DNSSEC導入はサーバ側は問題ないもののプロトコルに問題が残る

その中でもまずチェックしておきたいのが「DNSSEC」に関する研究。現在のDNSのプロトコルでは、DNS情報はUDPパケットで伝送されるため、悪意のあるユーザが偽のDNSサーバを用意することでDNSサーバの応答を簡単に偽装することができてしまう。それに対しDNSSECでは、DNSサーバからの応答内容に公開鍵暗号を利用した電子署名を添付することでその正当性を確保することができるのだが、一方でDNSサーバにおいては公開鍵暗号の処理など新たな処理が加わるためにサーバのパフォーマンス低下などの可能性があり、実運用に当たってはそれらの問題が心配されていた。

DNSSECの概要	DNSSECの実証実験の概要

これに対し今回はDNSSECに対応したDNSサーバであるBIND 9.3-snapshot、そして従来のドメイン名登録システムに鍵管理機能を追加したものを使用し、「dnssec.jp」「e164.jp」の2ドメインで実際にDNSSEC対応のDNSサーバを運用する形で実証実験を実施。この結果、DNSSEC対応のDNSサーバでも毎秒約12,000Queryを処理することができることが確認できたほか、DNSの応答時間も最大で約10msの増加にとどまるということで、DNSSECを導入するにあたってのサーバ側のパフォーマンスについては全く心配がいらないということが報告された。

しかし、一方でDNSSECプロトコル自体に関しては全く問題ないというわけにはいかないようで、今回3社で実際にDNSSEC対応のクライアントソフトを試作しサーバとの通信テストを行ったところ、「データの検証に失敗した場合の理由の通知に問題がある」「通信路の安全化が不十分」という2点でプロトコルに不備があることが確認できたという。既にこれらの問題はIETFの方にも報告され、現在改良作業が進められているというが、DNSSECを本格的に利用するためには、これらの問題が解決されるまでまだしばらくの間待たなくてはいけないようだ。

評価結果。サーバ側の性能的には問題はほとんどないという	DNSSECクライアントを試作しての実験結果。やや問題がある

DNSの信頼性を計算して表示するシステム

またこれとは別に面白そうなのが、DNS Queryがどの程度信頼できるのかを算出してユーザに通知するという試み。具体的にはローカルのDNSサーバに信頼度算出のためのプログラムを組み込み、クライアントが通常のDNS Queryをローカルサーバに対して投げると、同サーバは外部のDNSに通常のQuery作業を行う一方で、信頼度計算のために対象となる各ネームサーバに別途Queryを投げて「使用しているサーバソフトのバージョン」「正引きと逆引きの内容が一致するかどうか」など複数の項目をチェック。そしてローカルのDNSはチェック項目に従って信頼度を算出してクライアントにそのデータを送り、クライアント側ではInternet Explorerのツールバーの一部としてその信頼度が表示されるというものだ。

今回のシステムの基本的アプローチ	信頼性計算のために行われるDNS Queryの種類

こちらは具体的なチェック項目

実際このシステムで信頼度算出のテストを行ってみたところ、外部に飛ぶDNS Queryのためのデータ量がパケット数で約30倍、バイト数では約56倍にもなってしまったというのだが、その大半はZONE-AXFR/NS-PTRの2つのQueryのパケットが占めるということで、この2つを除くとパケット数・データ量共に約5倍程度に収まる。その場合でも信頼度そのものの信頼性にはさほど影響がないとのことで「ネットワークに大きな影響を与えることなく信頼度の確認が可能になる」と、発表を担当したNTTデータの馬場氏は語っていた。

信頼度はこのようにIEのツールバーに表示される	トラフィックはやや増加するが、種類を絞れば影響は大きく下がる

DNSに高度なアクセス制御を導入するに当たっての課題

次世代DNSについてはもう一つ、高度なアクセス制御をDNSに導入するための研究も紹介したい。現在のところDNSサーバのアクセス制御についてはサーバ全体に対してアクセスを認めるか認めないかという程度の制御を行うのが精一杯であり、サーバに登録されている個々のDNSレコード単位でのアクセス制御を行ったりするということは行えないが、この点を改善してゾーンデータ単位でのアクセス制御を可能にする試みが披露された。

具体的にはDNSサーバのゾーンレコードの中にアクセス制御リスト(ACL)をテキストデータの形で記述するほか、デジタル署名を利用してユーザ名やホスト名を識別する仕組みや、共通鍵暗号を利用してDNSメッセージを暗号化する仕組みを導入することでアクセス制御を実現。今回はサーバはBIND 9.2.1を改造したもの、クライアントはglibc 2.3.2を改造したものをそれぞれ利用して実験を行っている。

今回導入されたDNSのアクセス制御方式	プロトコルの詳細

サーバ・クライアントの実装状況

その結果、Pentium 4 2.8GHzを搭載したマシンをDNSサーバとして使用した場合で、アクセス制御対応のDNS Queryを毎秒40Query程度処理できることが確認できた他、メモリ使用量も「ACL一つにつき90bytes程度必要になる以外は、従来のBINDとほとんど大差ない」(馬場氏)という。

これまで特定のユーザに対してのみDNSレコードを見せたいと思うと、内向き・外向きのDNSをそれぞれ設置するといった方法を取るしかなかったし、それも企業内のLANなどでしか使えない手法のためにいろいろと不都合も存在したが、この手法が正式にIETFなどで標準化され普及すればかなり助かる人が出てくるのではないか。今後に期待したい技術の一つだ。

処理性能の測定結果	リソースレコード量とメモリ使用量の変化の関係