DNSSECの導入と運用に関する技術動向

今回のFROM JPRSでは、2009年7月にスウェーデンのストックホルムで開催された第75回IETF Meeting（以下、IETF75）と、それに合わせて開催された関連会議で議論された話題から、DNSSECの導入と運用に関する技術動向を中心にお伝えします。

DNSSECの導入・普及に向けた機運の高まり

2008年に発表された「カミンスキー・アタック（*1）」によるDNSキャッシュポイズニングに対する危険性の高まりを受け、DNSSECの導入・普及を進めようという活動が活発になってきています。JPドメイン名においても、2010年中を目途にDNSSECを導入予定です。

DNSSECの導入によりDNS応答の受信者は、

1. 本当にその相手が登録したデータであること
   （データ出自の認証）
2. 通信途中で書き換えられたり、一部が失われたりしていないこと
   （データの完全性）

の2点を検証できるようになります。これにより受信者は受け取ったDNS応答が「偽造や改変を受けていない」あるいは「偽造や改変を受けている」ということを、明確な形で確認できるようになります。

DNSSECの円滑な導入・普及を進めるための活動が活発化

ユーザーがDNSSECを利用するためには、名前情報を提供する側の権威DNSサーバ、及び名前情報を検索する側のキャッシュDNSサーバのすべてにおいてDNSSECが導入されている必要があります。

このような状況から、

• DNSSECの導入・普及を円滑に進めていくため、今後どのような技術的項目について考慮すべきか
• DNSSECの導入・普及を進めるに当たり、プロトコル上、あるいは運用上改良が必要な項目は何か
• 各項目について、具体的にどのような改良を進めていく必要があるのか

といった、DNSSECを実際に導入・運用する際に必要となる技術に関する議論が、 今回の会議における大きな話題の一つとなりました。

以下、議論された内容について報告します。

DNSパネルセッションにおける議論

今回のIETF75と同時開催する形でISOC（*2）が「Securing the DNS: Leading the next step towards a more secure Internet」と題したパネルセッションを開催しました。パネルセッションではルートゾーンやTLDにおけるDNSSECの導入計画について、また既にDNSSECを導入しているTLDの担当者から導入後の状況報告について報告・議論されました。

.netは2010年末、.comは2011年初頭にDNSSEC導入へ

.com/.netを管理する米国ベリサイン社から、.netには2010年末に、.comには2011年初頭にDNSSECを導入する予定であることが表明されました。

.com/.netでは実装方式として最新のDNSSECであるNSEC3を用い、鍵情報の登録はRFC 4310で定義されているEPP拡張方式を用いる予定であることが示されました。レジストリ＝レジストラ間の通信方式であるEPPを用いることから、.com/.netでは鍵情報の登録はレジストラ経由で行われることになります。

ルートゾーンへのDNSSEC導入は2009年中を目処

DNSSECをインターネット全体で円滑に動作させるためには、ルートゾーンにDNSSECが導入され、かつ各TLDの鍵情報がルートゾーンに登録・公開される必要があります。

ルートゾーンへのDNSSEC導入のための具体的な検討作業は現在、米国商務省、ICANN、米国ベリサイン社の三者により進められています。今回のパネルセッションでは、

1. 2009年中にDNSSECをルートゾーンに導入する方向で活動を進めている
2. レジストリ業務を行っているIANA（ICANN）がルートゾーンの鍵署名鍵（KSK）を管理し、公開鍵をインターネット上に公表する
3. ゾーンファイルの生成を行っている米国ベリサイン社がゾーン署名鍵（ZSK）の管理とルートゾーンへの署名を行い、各ルートサーバに署名済みゾーンデータを提供する

という案を軸に、具体的な実装作業が進められていることが報告されました。

DNSSEC導入により権威DNSサーバへのTCP問い合わせ数が急増

.orgを管理する米国パブリック・インタレスト・レジストリ（PIR）から、2009年6月2日の.orgへのDNSSEC導入から現在までの運用状況が報告されました。

今回の報告ではDNSSEC導入開始と同時に、.orgの権威DNSサーバへのTCPによる問い合わせ数がDNSSEC導入前と比べて百倍のオーダーで増加し、DNS問い合わせ全体の約15％に達したことが示されました。これは、DNSSECの導入によりDNS応答のサイズが大きくなったことから、DNS問い合わせにおいてTCPへのフォールバック（*3）が数多く発生していることを意味しています。

DNSSECを導入した場合、EDNS0拡張機能がうまく機能することによりTCP問い合わせの急増を避けられることが期待されていました。しかし、実際には当初予想よりもTCP問い合わせの増加率が大きく、大規模なゾーンへのDNSSEC導入の際には権威DNSサーバの負荷上昇を、従来よりもより大きく見積もる必要があるという見解が示されました。

この問題はIETF75においても取り上げられ、上記を緩和するためのEDNS0プロトコルの改良方法について議論されました。詳細は後述します。

IEPGにおける議論

IEPGは、インターネットサービスオペレータで構成される、インターネット全体に関する運用環境や運用技術に関する技術的調整を円滑に進めるためのグループです。IEPGでは毎回、IETFに併設する形で会議を開催しています。

ルートゾーンの肥大化が及ぼす影響と評価

DNSSECの導入、IPv6普及の進捗、新しいgTLDやIDN ccTLDの導入などにより、ルートゾーンの大きさは肥大化する傾向にあります。このためICANNでは、今後予想されるルートゾーンの肥大化がインターネット全体に与える影響について、専門家による評価を進めています。

今回のIEPGでは評価メンバーの一人であるパトリック・ファルトストローム氏から、レポートの草案を8月31日に公開する予定であること、10月に開催されるICANNソウル会議まで、草案のレビューとパブリックコメントを受け付けることが発表されました。

評価に関するパブリックコメントは下記ページ（*4）で参照、投稿することができます。

IETF DNSEXT WGにおける議論

DNSEXT WGは、DNSの各機能の拡張に関する議論を行うためのWGです。

EDNS0プロトコルの改良に関する議論

前段で報告したように、DNSSECの導入により権威DNSサーバへのTCP問い合わせが予想以上に増加し、権威DNSサーバの負荷が上昇することが示されました。

これを緩和するため、EDNS0で取り扱えるバッファサイズが1220バイト以下であった場合DNS問い合わせのDO（DNSSEC OK）ビットをOFFにし、DNSSEC関連のデータを取り扱わないようにするのはどうか、という提案がありました。

今回の提案は実際に.com/.netの権威DNSサーバに到達するDNS問い合わせを分析した結果、EDNS0に対応したDNS問い合わせのうち約15％が、EDNS0で取り扱えるバッファサイズとして、現状においてDNSSECデータを取り扱うには十分ではない1220バイト以下の値を通知してくるという統計的事実に基づいています。

しかし、本提案については今回のIETF75では合意に至らず、今後継続して議論を進めていくこととなりました。今回提案されたインターネットドラフトは、下記ページ（*5）で参照することができます。

DNSSECは「導入できるかどうか」から「導入するには何が必要か」へ

このように今回のIETF75では従来からの、DNSSECが導入できるかどうか、ではなく、DNSSECの導入を進めていくためには何が必要か、という課題を中心に議論が進められました。このような状況からも、DNSSECはインターネット全体への円滑な導入に向け、関係者全体が協力して努力していく段階に達していると言えるでしょう。

次回のIETFは広島で開催

次回の第76回IETF Meetingは2009年11月に広島で開催されます。IETFには、世界中からインターネット技術者や研究者らが多く出席し、インターネット上のさまざまな課題について活発な議論が行われています。このようないわば「インターネットづくり」とも言える重要な会議に、皆さまも参加されてみてはいかがでしょうか。



本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。