DNSSEC導入の負荷実験データに大きな関心、海底ケーブル埋設＆修理ネタも

●間近に迫った世界的なDNSSECの導入

　インターネットにおいて、ドメイン名とIPアドレスの対応を管理するDNS（Domain Name System）は重要な基盤技術の1つだが、これが正しく動かなければ、Webページへのアクセスばかりでなくメールの送受信にも影響が出る。そのDNSの安全性を高めるために、DNSSECが世界的に導入されようとしている。

　DNSSECとは「Domain Name System Security Extensions」の略で、DNSでやりとりされる情報が正しい応答先から来たものか、パケット内容が改ざんされていないかといったことを確認できるように仕様を拡張するものだ。

　予定では、7月15日からルートDNSサーバーがDNSSEC正式運用を開始し、JPドメイン名など主だったTLDも導入を計画している。DNSSECは、DNSを構成する関係者が全体として協調する必要があるため、それぞれの立場で対応を進めていかなければならず、DNS運用者にはさまざまな懸念がある。

　JANOG（JApan Network Operators' Group）が7月8日・9日に東京・恵比寿のザ・ガーデンホールで開催した「JANOG26 Meeting」では、そうした懸念に対する情報を提供するなど、DNSSECに関する話題が大きなトピックとなった。

　なお、JANOGとは、インターネットにおける技術的事項と、それに関連するオペレーションに関する事項を議論・検討・紹介することにより、日本のインターネット技術者や利用者への貢献を目的としたグループだ。

●DNSSECでキャッシュDNSサーバーの負荷は確実に増大する

（左から）JPRSの民田雅人氏、NTT Comの濱口一真氏、NECアクセステクニカの川島正伸氏

　「動かしてみましたDNSSEC」と題したセッションでは、冒頭で日本レジストリサービス（JPRS）の民田雅人氏からDNSSECの概要と着目点などが解説された後、NTTコミュニケーションズ（NTT Com）の濱口一真氏からキャッシュDNSサーバーにおける影響、NECアクセステクニカの川島正伸氏からブロードバンドルーターに関する調査結果と続き、再び民田氏が権威DNSサーバー管理について解説するという流れで進められた。

　濱口氏の発表は、JPRS共同実験を利用した計測結果を使い、DNSSEC導入に伴うキャッシュDNSサーバーの影響を把握しようとするものだ。サーバー環境には、Xeon E5405（4コア、2GHz）、メモリー8GB、BIND 9.7.0-p2を使用したということだ。また、今回の実験結果はあくまでもJPRSおよびNTT Comの試験環境で確認した数値であり、すべての環境で同一の結果が出ることを保障したものではないということも付け加えられている。

　さて、その実験結果だが、いくつかのスライドを見ると濱口氏の言うとおり「確実に負荷は上がる」ということが読み取れる。「DNSSEC実験結果（CPU使用率の変化）」では署名の検証を行うとCPU使用率が倍以上になること、「DNSSEC実験結果（メモリー使用率の変化）」では署名ありの場合でより多くのメモリーを使用することがはっきりと出ているのがわかる。

CPU使用率の変化	メモリー使用率の変化

　その一方で、ネットワーク帯域の変化では興味深いデータも示された。権威DNSサーバーからの応答（Reply）ばかりでなく、キャッシュDNSサーバーから権威DNSサーバー方向のトラフィック（Query）も増えることがデータ上に出ている点に注目される。1クエリのデータサイズが、あるケースでどのくらい変化したかも示された。

ネットワーク帯域の変化	1クエリのデータサイズの変化

　サーバーの負荷が上がるということは、設備の増強を含めた対応を検討する必要がある。濱口氏は、今後は、商用トラフィックベースを想定したデータの収集や負荷分散装置、ファイアウォールの影響把握も重要だと続けた。

●ブロードバンドルーターには課題が多い

　川島氏の発表は、DNSSECが導入された際にSOHOや一般家庭などで使用しているブロードバンドルーターはどこまでDNSSECに対応できるのかという視点で、必要な項目に対する検証を行ったものだ。EDNS0（Extension Mechanisms for DNS）に対応しているかや、フラグメントされたパケットを正しく扱えるかといった内容を個別に調査した結果を示し、現状がどうであるかが示された形になった。

　「イケてる実装とイケてない実装がある」こと自体は予想された結果ではあるが、問題は、その中身だろう。本来は1200バイトのデータが返ってきているのに、それを512バイトでばっさりと切り捨ててしまう。しかも、切り捨てたことを示すフラグを立てないため、そのパケットを受け取った側はTCPフォールバックをすることもできない。別の事例では、ブロードバンドルーターがAレコードしかキャッシュしないため、キャッシュ利用時にDNSSEC検証を行えない実装なども示された。また、イケてる実装では当該機種がNIC.CZのDNSSEC適合性確認ツールを使用して100％適合への一番乗りを果たしたことが報告された。

検証のポイント	イケてない実装の話その1（512bytesへの異常な愛）

　イケてないブロードバンドルーターを使っていると、正しく通信できない可能性があり、利用者にとって不利益になる。川島氏は「応答パケットサイズは肥大化傾向にあるため、DNSSEC対応に限らずEDNS0対応とTCPフォールバック対応は進めるべき」とし、「ブロードバンドルーターで、DNSキャッシュは行わないほうがよい。行うなら、覚悟して実装すること」という言葉で締めくくった。

イケてる実装	検証のまとめ

●権威DNSサーバー側の負荷も増大する

　民田氏の発表は、権威DNSサーバーをDNSSEC化することで負荷がどのように変化するかを示したものだ。古い世代の機種と最新の機種を用いて比較したデータは興味深いものだったが、重要なのは、権威DNSサーバー側でも平均で1割から2割の性能低下があり、不在応答（存在しない名前を問い合わせられた）時にはさらに処理能力が低下するという部分だ。応答パケットも5倍から8倍程度に増加するという。

権威DNSサーバーのDNSSEC化による調査内容	各方式の応答性能比較

　応答性能は、1秒間にどれくらいの名前解決要求（クエリ）を処理できるかという数字だ。最新の機種ではまだ余力があるが、古い機種では一気に性能が低下しているのが見てとれる。やりとりされるパケットサイズがどのくらいの大きさになるのかといった点についてもデータが示された。

各方式の平均DNS応答サイズ	実験のまとめ

　民田氏は、これ以外にも各種グラフを使って負荷の変化などを示した。その後、質疑応答に移ったが、DNSSECに対する関心の高さからか、数多くの質問や意見が会場から出ることとなった。

　DNSSECの導入は、今や世界的な流れとなっている。導入の有無を論じる時間は終り、現実問題としてDNS関係者はその対応を迫られている。そうした中で、このような機会は貴重であったと言えるだろう。民田氏は最後に、「キャッシュDNSサーバーは早めの対応をお願いします」として、何から手を着けるべきかを示した。

●インターネットを支える海底ケーブルの実際

　JANOG Meetingは、堅苦しい話題ばかりではない。今回は、自分たちが普段使っている工具を紹介するセッションや、「海底ケーブル～構築と運用の深イイ話～」というセッションもあった。

　今や、世界をつなぐために海底ケーブルは欠かせない存在になっている。しかし、普段は目に見えないこともあり、その実際を知る機会は滅多にない。NTT Comの浜田泰幸氏と中嶋正裕氏の発表は、海底ケーブルをどう埋設したり修理したりするのか、さらには2006年12月に起きた台湾地震で破壊された海底ケーブルの話などを含めての紹介だった。ネットワーク運用者でも普段なかなか接することのないものだけに、来場者の関心を集めていた。

（左から）NTT Comの中嶋正裕氏と浜田泰幸氏	海底ケーブルは、漁業などの関係から水深1000mから2000mぐらいまでは埋設される。深海では非埋設となる
海底ケーブルの構成と形状	世界の海底ケーブル
海底ケーブルをどのように修理するか。ROV（Remotely Operated Vehicle）が活躍する	修理船はかなり大きい
台湾地震による回線断を、中国の内陸部を通すことで対応	切断された海底ケーブルの写真