JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
増刊号
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2009-07-23━ ◆ FROM JPRS 増刊号 vol.93 ◆ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ DNSSECの導入に向けて―より安全なインターネットの実現のために ～ICANNシドニー会合における話題から～ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ JPRSは2009年7月9日に、JPドメイン名サービスへのDNSSECの導入予定を発表し ました。それに先立つ2009年6月にはICANNが、2009年中にルートゾーンで DNSSECを稼動させることを目標に活動を開始する旨を表明しており、DNSSECの 導入と運用に関する検討がインターネット全体の重要な課題となっています。 今回のFROM JPRSでは、DNSSECの概要と最近の標準化の状況について解説する とともに、2009年6月の第35回ICANNシドニー会合で開催された、DNSSECワーク ショップの内容をお伝えします。 ◇ ◇ ◇ ■DNSSECの概要 DNSSEC（DNS Security Extensions）は、DNSのセキュリティを向上させるため の一連のDNS拡張機能です。 ▼DNSSEC開発の背景 DNSは主な通信プロトコルにUDPを使用しているため、他の通信プロトコルと比 較して悪意のある第三者によるデータの偽造が容易であるという弱点がありま す。 DNSは、こうしたデータの偽造を検出・防止するための仕組みを備えています。 しかしそれらはデータの偽造可能性を減少させることしかできないため、偽の DNS応答によりDNSキャッシュデータを汚染させる、いわゆる「DNSキャッシュ ポイズニング」攻撃のリスクを完全に回避することはできません。そこで、こ の問題を根本的に解決し、DNSの信頼性を高めるための手段としてDNSSECの開 発が進められました。 ▼DNSSECにより実現できること DNSSECの導入によりDNS応答の「出所」と「内容」の正当性を検証することが 可能になります。つまり、DNSサーバからの応答を受け取った側が、 1. 応答が確かにそのDNSサーバから発信されたものであること 2. 応答内容が悪意のある第三者により途中で改ざんされていないこと を確認できるようになり、DNSの信頼性を高めることができます。 ■DNSSEC標準化の状況 他のプロトコルと同様、DNSSECはIETFで標準化作業が進められました。基本的 なDNSSECの仕様を定めた最初のバージョンが1999年にRFC 2535として発行され、 その後、運用コストの低減を図るためのプロトコルの改定作業を経て、2005年 にRFC 4033、4034、4035の三つのRFCにバージョンアップされました。 RFC 4033: DNS Security Introduction and Requirements （DNSセキュリティ拡張の紹介とその要件） http://www.ietf.org/rfc/rfc4033.txt 日本語訳: http://jprs.jp/tech/material/rfc/RFC4033-ja.txt RFC 4034: Resource Records for the DNS Security Extensions （DNSセキュリティ拡張で使用するリソースレコード） http://www.ietf.org/rfc/rfc4034.txt 日本語訳: http://jprs.jp/tech/material/rfc/RFC4034-ja.txt RFC 4035: Protocol Modifications for the DNS Security Extensions （DNSセキュリティ拡張のためのプロトコル修正） http://www.ietf.org/rfc/rfc4035.txt 日本語訳: http://jprs.jp/tech/material/rfc/RFC4035-ja.txt これら三つのRFCに加え、DNSSECによる正当性検証の際に必須となるトラスト アンカーの自動更新を実現するプロトコルであるRFC 5011が2007年に、ゾーン ウォーキング（*1）を防ぐためのNSEC3拡張を定義したRFC 5155が2008年に、 それぞれ標準化されました。 RFC 5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors （DNSSECトラストアンカーの自動更新） http://www.ietf.org/rfc/rfc5011.txt RFC 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence （DNSSECのハッシュ化された不存在証明） http://www.ietf.org/rfc/rfc5155.txt これらの標準化作業の進捗により、DNSSECをインターネットで実運用するため に必要な基本プロトコルが整いました。 （*1）あるゾーンデータに含まれる全ての名前情報を入手する行為。 ■DNSSEC導入に向けた機運の高まり DNSSEC関連プロトコルの整備、社会インフラとしてのインターネットの重要性 の高まり、また2008年に発見された「カミンスキー・アタック（*2）」のよう な新しいDNSキャッシュポイズニングの攻撃手法などにより、DNSSECの導入に 向けた機運が高まってきました。 （*2）「JPRS トピックス＆コラム」No.9 新たなるDNSキャッシュポイズニン グの脅威～カミンスキー・アタックの出現～ http://jpinfo.jp/topics-column/ これらの状況を受けICANNは、セキュリティと安定性に関する諮問委員会 （SSAC）、ルートサーバシステム諮問委員会（RSSAC）などの専門家のコメン トを参考にしながら、DNSSECの導入に関する検討を進めてきました。 そして、ICANNは2009年6月に、米国政府、米国ベリサイン社（以下、ベリサイ ン）と協働して、2009年中にルートゾーンでDNSSECを稼動させることを目標に 活動を開始する旨を表明しました（*3）。 （*3）ICANN to Work with United States Government and VeriSign on Interim Solution to Core Internet Security Issue - Immediate security concerns addressed by DNSSEC - http://www.icann.org/en/announcements/announcement-2-03jun09-en.htm ■DNSSECワークショップにおける主な話題 このような動きを受け、今回のICANNシドニー会合で開催されたDNSSECワーク ショップの関心は高く、50人収容の会場はほぼ満席となりました。 今回のワークショップでは.orgを始め、実際にDNSSECを導入し始めているTLD からの状況報告や、ルートゾーンにDNSSECを導入する際の各種鍵（*4）の管理 モデルの検討状況、現在IANA（*5）が試験運用している「暫定トラストアン カーリポジトリ（Interim Trust Anchor Repository: 以下、ITAR）」の状況 など、インターネット全体でのDNSSECの実運用を前提とした発表・議論が多く 行われたことが特徴的でした。 （*4）DNSSECでは公開鍵暗号と電子署名の仕組みにより正当性の検証を行って おり、そのための鍵の作成や管理が必要になります。 （*5）Internet Assigned Numbers Authority http://jpinfo.jp/glossary/index.php?ID=0027 以下、興味深い発表内容をいくつかご報告します。 ▼ルートゾーンにおける鍵の管理 ルートゾーンは現在ICANN、米国政府、ベリサインの三者が共同で運用してい ることから、DNSSECで使用する鍵の管理を誰がどのように行うかが課題となっ ていました。 今回のワークショップでは、次回のIETFストックホルム会議での発表を目標に、 テストと実装の計画案の作成をICANNとベリサインが共同で進めている、とい う発表がありました。 また、TLDの鍵情報をルートゾーンに記載する作業については、現在IANAで試 験運用しているITAR（後述）をベースに、できるだけ早い段階で実装したいと の発言がありました。 ▼DNSSECを先行導入したTLDからの状況報告 今回のワークショップではDNSSECを実際に導入した、あるいは導入作業を進め ているいくつかのTLDからの状況報告がありました。中でも、gTLDでDNSSECの 本運用を開始した.orgを管理しているPIR（*6）からの発表は、注目を集めて いました。 PIRからは2009年6月2日に.orgのゾーンデータへの署名を開始したこと、当初 は技術者が管理している三つの*.orgドメイン名に手動でDNSSECを適用して試 験したこと、2010年に全てのレジストラ・登録者からのDNSSEC化の要請に応え られるようにシステムを整備する予定であることが発表されました。 今回のワークショップでは.org以外に、ccTLDでは.au、.my、.nz、.sg、.th、 また.arpaやin-addr.arpa、ip6.arpaといった管理用ドメイン名へのDNSSEC導 入のための作業状況が、それぞれの関係者から報告されました。それぞれの報 告の詳細は、参考URIとしてご紹介したDNSSECワークショップの公式ページに 紹介されています。 （*6）Public Interest Registry http://www.pir.org/ ▼トラストアンカーリポジトリ（Trust Anchor Repository）に関する議論 DNSSECでは、DNSの上位のゾーンから下位のゾーンに対し、署名による「信頼 の連鎖」を構築します。ルートゾーンを含むDNSの全てのゾーンがDNSSECに対 応した場合、ルートゾーンが信頼の連鎖の基点となり、全てのゾーンの信頼性 を検証することができます。 しかし、ルートサーバやTLDサーバが全てDNSSECに対応するまでには、ある程 度の時間を要します。全てのゾーンがDNSSECに対応するまでの間、DNSSECに対 応したゾーンがあたかも「島」のように、DNSの木構造の中に点在することに なります。 このような状況では、信頼の連鎖の基点はそれぞれの「島」の最上位ゾーンと なり、DNSSECを利用する側はこれら複数の基点を知っている必要があります。 「トラストアンカーリポジトリ（Trust Anchor Repository: 以下、TAR）」は、 これらの情報を集中的に格納、公開することでDNSSECの普及を促進しようとい う狙いがあります。 今回のワークショップでは、TARの紹介とその長所・短所についての議論、 IANAがTLDを対象に公開しているITARの紹介と運用状況についての報告があり ました。 議論では、TARにより上位ゾーンのDNSSEC署名の普及がかえって遅くなる危険 性もある、DNSの全てのゾーンがDNSSECに対応した時点でTARは段階的に不要に なるが、その際のサービス移行はどのように進めるのか、といった点が話題に なりました。 ■DNSSEC導入には全体の協調が不可欠 JPRSが発表した「JPドメイン名サービスへのDNSSECの導入予定について」でも 触れているように、DNSSECはDNSを構成するそれぞれの関係者（ルートサーバ、 TLDサーバ、各組織の権威DNSサーバ、DNSキャッシュサーバの運用者など）が それぞれの立場で、DNSSECへの対応を進めていく必要があります。 JPRSではDNSSEC導入、普及促進のための活動を通じ、より安全なインターネッ トの実現のための活動を今後も継続していきます。 ◇ ◇ ◇ ◎関連URI - JPドメイン名サービスへのDNSSECの導入予定について http://jprs.jp/info/notice/20090709-dnssec.html - ICANN 35 | 21-26 Jun 2009 | Sydney http://syd.icann.org/ （ICANNシドニー会合公式ページ） - Workshop: DNSSEC | Sydney http://syd.icann.org/node/3791 （DNSSECワークショップ公式ページ） - IANA - Interim Trust Anchor Repository https://itar.iana.org/ （IANAが運用している暫定トラストアンカーリポジトリ） ━━━━━━━━━━━━━━━━━━━━━━━━━━━【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.
