JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
増刊号
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2009-08-24━ ◆ FROM JPRS 増刊号 vol.94 ◆ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ DNSSECの導入と運用に関する技術動向 ～第75回IETF Meetingにおける話題から～ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 今回のFROM JPRSでは、2009年7月にスウェーデンのストックホルムで開催され た第75回IETF Meeting（以下、IETF75）と、それに合わせて開催された関連会 議で議論された話題から、DNSSECの導入と運用に関する技術動向を中心にお伝 えします。 ◇ ◇ ◇ ■DNSSECの導入・普及に向けた機運の高まり 2008年に発表された「カミンスキー・アタック（*1）」によるDNSキャッシュ ポイズニングに対する危険性の高まりを受け、DNSSECの導入・普及を進めよう という活動が活発になってきています。JPドメイン名においても、2010年中を 目途にDNSSECを導入予定です。 DNSSECの導入によりDNS応答の受信者は、 1. 本当にその相手が登録したデータであること （データ出自の認証） 2. 通信途中で書き換えられたり、一部が失われたりしていないこと （データの完全性） の2点を検証できるようになります。これにより受信者は受け取ったDNS応答が 「偽造や改変を受けていない」あるいは「偽造や改変を受けている」というこ とを、明確な形で確認できるようになります。 （*1）JPRS トピックス＆コラム No.009「新たなるDNSキャッシュポイズニン グの脅威～カミンスキー・アタックの出現～」 http://jpinfo.jp/topics-column/009.pdf ▼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の担当者から導入後の 状況報告について報告・議論されました。 （*2）ISOC（アイソック） http://jpinfo.jp/glossary/index.php?ID=0037 Internet Societyの略称。 1992年に設立された非営利の国際組織で、インターネット技術及びシス テムに関する標準化、教育、ポリシーに関する課題や問題を解決あるい は議論することを目的としています。具体的には、イベント「INET」の 開催や、IABやIETFの上位団体として、これらの団体の活動に対する支 援を行っています。 ▼.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プロ トコルの改良方法について議論されました。詳細は後述します。 （*3）JPRS トピックス＆コラム No.008「512の壁を越える?EDNS0の概要と運 用上の注意?」 http://jpinfo.jp/topics-column/008.pdf ■IEPGにおける議論 IEPGは、インターネットサービスオペレータで構成される、インターネット 全体に関する運用環境や運用技術に関する技術的調整を円滑に進めるための グループです。IEPGでは毎回、IETFに併設する形で会議を開催しています。 ▼ルートゾーンの肥大化が及ぼす影響と評価 DNSSECの導入、IPv6普及の進捗、新しいgTLDやIDN ccTLDの導入などにより、 ルートゾーンの大きさは肥大化する傾向にあります。このためICANNでは、今 後予想されるルートゾーンの肥大化がインターネット全体に与える影響につ いて、専門家による評価を進めています。 今回のIEPGでは評価メンバーの一人であるパトリック・ファルトストローム氏 から、レポートの草案を8月31日に公開する予定であること、10月に開催され るICANNソウル会議まで、草案のレビューとパブリックコメントを受け付ける ことが発表されました。 評価に関するパブリックコメントは下記ページ（*4）で参照、投稿することが できます。 （*4）ICANN | Public Comment http://www.icann.org/en/public-comment/#root-scaling ■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）で参照することができます。 （*5）DNSSEC OK buffer minimum size requirement and error handling http://www.ietf.org/id/draft-gudmundsson-dnsext-setting-ends0-do-bit-01.txt ■DNSSECは「導入できるかどうか」から「導入するには何が必要か」へ このように今回のIETF75では従来からの、DNSSECが導入できるかどうか、では なく、DNSSECの導入を進めていくためには何が必要か、という課題を中心に議 論が進められました。このような状況からも、DNSSECはインターネット全体へ の円滑な導入に向け、関係者全体が協力して努力していく段階に達している と言えるでしょう。 ■次回のIETFは広島で開催 次回の第76回IETF Meetingは2009年11月に広島で開催されます。IETFには、世 界中からインターネット技術者や研究者らが多く出席し、インターネット上の さまざまな課題について活発な議論が行われています。このようないわば「イ ンターネットづくり」とも言える重要な会議に、皆さまも参加されてみてはい かがでしょうか。 ◇ ◇ ◇ ◎関連URI - IETF75 http://www.ietf75.se/ （IETF75ホームページ） - Securing the DNS: Leading the next step towards a more secure Internet @ IETF 75 http://www.isoc.org/isoc/conferences/dnspanel/ （ISOC DNS Panelホームページ） - ICANN DNS Root Scaling Study http://www.iepg.org/2009-07-iepg75/Root%20scaling%20study%20overview%20v5.pdf （ルートゾーンの肥大化が及ぼす影響に関する状況報告・パブリックコメ ント募集） - IETF76 http://www.ietf76.jp/ （IETF76ホームページ） ━━━━━━━━━━━━━━━━━━━━━━━━━━━【FROM JPRS】━ ■会議報告：http://jpinfo.jp/event/ ■配信先メールアドレスなどの変更：http://jpinfo.jp/mail/henkou.html ■バックナンバー：http://jpinfo.jp/mail/backnumber/ ■ご意見・ご要望：from@jprs.jp 当メールマガジンの全文または一部の文章をホームページ、メーリングリスト、 ニュースグループまたは他のメディア等へ許可なく転載することを禁止します。 また、当メールマガジンには第三者のサイトへのリンクが含まれていますが、 リンク先のサイトの内容などについては、JPRSの責任の範囲外であることに ご注意ください。 その他、ご利用にあたっての注意事項は読者登録規約にてご確認ください。 http://jpinfo.jp/mail/kiyaku.html ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 編集・発行：株式会社日本レジストリサービス（JPRS） http://jprs.jp/ http://日本レジストリサービス.jp/ Copyright(C), 2009 Japan Registry Services Co., Ltd.
Copyright©2001-2024 Japan Registry Services Co., Ltd.
