1通の論文から始まったDNSSECの歴史、ランチセミナーで紹介

日本レジストリサービスの森下泰宏氏（右）と民田雅人氏（左）

AT&Tベル研究所のSteven M. Bellovin氏による論文「Using the Domain Name System for System Break-ins」の概要

今年の弁当は幕の内

　「Internet Week」恒例となったセッションに「ランチのおともにDNS」というものがある。「Internet Week」の会場となっている秋葉原は、昼の食事には苦労する。特にイベントが行われている時にはなおさらだ。このセッションは、ランチが出る上に有用な情報を聞けるのでありがたい。しかも、タダ。ということもあって、今年も満席だった。

　今年のタイトルは「桃栗三年柿八年、DNSSECは何年？」。インターネット関係者の間でもホットな話題の1つをどのように“料理”したのか、その概要をお伝えする。

　セッションの内容は、DNSSECの歴史とその対応について簡潔にまとめたものだ。日本レジストリサービス（JPRS）の民田雅人氏と森下泰宏氏の発表は、森下氏によるDNSSECの歴史話から始まった。

　森下氏によると、DNSの安全性に関する懸念が起こったのはAT&Tベル研究所のSteven M. Bellovin氏が書いた「Using the Domain Name System for System Break-ins」という論文がきっかけだという。何が問題かというと、論文中で“DNSキャッシュポイズニング”の手法についての記述があったという点らしい。

　しかし、当時（1990年）の段階ですでにドメイン名空間は巨大であり、他の方法で安定運用をするのは困難であると結論付け、Bellovin氏はこの論文を数年間発表しなかった（発表は1995年）。その間、この脆弱性は一部の研究者・専門家などの間で伝えられ、DNSにセキュリティ機能を付加することの重要性を認識するのに役立ったという。

　DNSSECにセキュリティを付加する議論が公式に始まったのが、1993年の第28回IETF。そこで最初の「DNSSEC BOF」が開催された。その後、1994年の第29回IETFにおいて「DNS Security Working Group」が組織され、DNSSECの標準化活動がスタート。以降、さまざまな議論が重ねられ、現在に至るという流れである。DNSSECの歴史は、実はかなり以前からあったことがよくわかる。

　続いて、運用にあわせてDNSSECの規格を改良していった話に移行する。

　DNSSECで悩ましいのは、署名に使用する鍵の扱いとゾーンへの反映である。例えば、鍵の交換と再署名。同じ鍵を長期間使い続けるとリスクを生じるため、安全確保のためには定期的な鍵更新を行う必要がある。ところが、この鍵の更新は決して容易ではない。鍵更新の手間、新しい鍵での再署名のタイミング、すでにキャッシュされた情報との整合性などなど。正直、非常に煩雑だと感じるが、こうしたことをどれだけきちんとできるかが広範囲に影響するため、これらの課題を解決、または、いかに上手に行えるようにするかを考えなければいけない。

　また、DNSSECでゾーンに署名した場合、ゾーンデータの大きさが署名前の約8倍程度増加するという点にも対処しなければならない。どれくらい増加するかは鍵の長さなどに依存するが、DNSのゾーンデータが大きく増えるとDNSサーバーの効率低下の原因になったり、DNSのパケットが大きくなることによる通信上の問題も起こるかもしれない。影響は実に広範囲だ。

　さらに、当初のDNSSECの仕様では、指定された名前が無いということを示す「不在証明」からそのゾーンの情報を芋づる的に引き出せるゾーンウォーキングも問題になった。

　森下氏の資料では、そうした経緯を経て、不具合を改良するためのさまざまな議論や試み、新しいRFCに関する話まで幅広く扱っている。仕様を改訂した結果、従来のRFCと互換性が無くなったDNSSECbis（RFC 4033、4034、4035）の話や、不在証明問題を解決するためのNSECやNSEC3の提案など、知っておくとよい話が網羅されている。ここでそのすべてを紹介することはできないが、JPRSではそうした情報もWebサイトから発信していくということなので、そちらを注目するのがいいかもしれない。

　いずれにしても、主要なTLDが続々と2010年から2011年にかけてのDNSSEC導入を表明している。ルートサーバーは2010年7月1日までに段階的な導入を完了する。試験導入済みの「.org」は2010年に本格導入予定。日本のドメイン名である「.jp」は2010年中、「.net」は2010年第4四半期、「.com」は2011年第1四半期だ。待ったはきかない。今は、DNSに関連する組織には行動が求められていることを実感した40分だった。