増刊号
vol.97

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2009-12-16━
　　　　　　　　　　◆ FROM JPRS 増刊号 vol.97 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　　　　　　　　ルートゾーンへのDNSSECの導入と展開
　　　　　　　 ～DNSSECの世界的普及に向けた大きな一歩～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DNSはインターネットの基盤技術の一つであり、DNSの信頼性を向上させること
は、インターネット利用者の安全を高めるために必要不可欠です。そのような
背景から、電子署名によりDNS応答の信頼性を向上させるための技術である
「DNSSEC」が開発され、普及促進が図られてきました。

IETFにおけるDNSSECプロトコル改良の進展や、2008年に発表されたカミンス
キー・アタックといったDNSに対する新たな脅威の出現などを背景に、2009年
はインターネット全体で、DNSSECの本格導入に向けたさまざまな活動が開始さ
れた年となりました。特に、ルートゾーンにおけるDNSSEC導入の具体的なスケ
ジュールが発表され、導入・展開に向けた実作業が開始されたことは、DNSSEC
の世界的普及に向けた大きな一歩であったと言えるでしょう。

今回のFROM JPRSでは、2009年10月から11月にかけて開催された第59回RIPE
Meeting（以下、RIPE59）、第36回ICANN Meeting（以下、ICANN36）、第76回
IETF Meeting（以下、IETF76）の一連の会議において報告・議論が進められた、
ルートゾーンへのDNSSECの導入と展開に関する最新動向についてご紹介します。

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

■ルートゾーンのDNSSECは2010年7月に稼動開始

2009年10月に開催されたRIPE59において、ICANNと米国ベリサイン社（以下、
ベリサイン）の担当者が、ルートゾーンにおいてDNSSECを2010年の7月に正式
稼動させる予定であると発表しました。

ルートゾーンへのDNSSEC導入そのものは既にICANNからアナウンスされていま
したが、ICANNが具体的な実施スケジュールを明確にしたのは、この時が初め
てです。発表の際には会議の参加者全体から大きな拍手が起こり、ルートゾー
ンがDNSSECに対応することの重要性と、その期待の大きさがうかがえました。

■「ルートDNSSECデザインチーム」が実作業を担当

ルートゾーンにおけるDNSSEC対応作業は新たに組織された「ルートDNSSECデザ
インチーム（以下、デザインチーム）」により進められています。デザイン
チームはルートゾーンのDNSSEC対応に際し必要となる、鍵管理のポリシー策定
やシステム運用手順の確立などの作業を円滑に進めることを目的としており、
ICANNとベリサインの関係者、及びccTLDとしてDNSSECをいち早く導入した
「.se（スウェーデン）」においてDNSSECの技術検証にかかわった組織
「Kirei（*1）」の担当者を含むメンバーにより構成されています。

（*1）http://www.kirei.se/en/
　　　組織名は日本語の「綺麗」に由来しており、サイトのトップページには
　　　片仮名で「キレイ」と書かれています。

■「インクリメンタル・ロールアウト」による段階的かつ慎重な導入

RIPE59における最初の発表以降、関係者が多く集まるICANN36及びIETF76の場
においてデザインチームのメンバーから、ルートゾーンに導入するDNSSECのよ
り具体的な技術仕様・導入手順及び導入スケジュール案が発表・議論されまし
た。

導入手順案では13あるルートサーバに対し、段階的かつ慎重にDNSSECの導入を
図るために「インクリメンタル・ロールアウト（Incremental roll out）」と
いう手法が採用されています。インクリメンタル・ロールアウトは、要求事項
を一度に全部実現するのではなく、複数に分割し、順次実現していくための手
法です。

今回発表された具体的な手順の概要は以下のようになっています。

1. 2009年12月: 内部的な署名と検証開始

　ルートゾーンのレジストリシステム内部において、ルートゾーンが署名され
　ます。ただし、この段階では各ルートサーバに署名済みのルートゾーンは反
　映されず、ICANNとベリサインの内部においてのみ、署名や鍵更新などの検
　証作業が進められます。

2. 2010年1月: L-rootにダミーの署名データを導入、影響がないことを確認

　13のルートサーバのうちICANNが運用するルートサーバである
　L.root-servers.net（L-root）に、署名データを導入します。ただし、この
　時点で導入される署名データは「DURZ（*2）」と呼ばれる、故意にDNSSEC検
　証を不可能にした、ダミーの署名データになります。

（*2）DURZ: Deliberately Unvalidatable Root Zone
　　　「故意に検証不可能にしたルートゾーン」を示します。

3. 2010年1月～2010年7月: 他のルートサーバにDURZを順次導入

　状況を確認しながらL-root以外の他のルートサーバに、順次DURZを導入して
　いきます。ここまでの手順によりDURZがすべてのルートサーバに導入されま
　す（*3）。

（*3）2009年12月15日（米国時間）、ルートゾーンへのDNSSEC導入に関する
　　　公式サイトが公開されました（関連URIを参照）。公式サイトには、
　　　各ルートサーバへのDURZの導入予定スケジュールが掲載されています。

　　　　・2010年1月11日週　L-root
　　　　・2010年2月 8日週　A-root
　　　　・2010年3月 1日週　M-root、I-root
　　　　・2010年3月22日週　D-root、K-root、E-root
　　　　・2010年4月12日週　B-root、H-root、C-root、G-root、F-root
　　　　・2010年5月 3日週　J-root

4. 2010年7月: DURZを正規の署名データに差し換え

　導入されたDURZを正規の署名データに差し換えます。同時に、キャッシュ
　DNSサーバにインストールするためのルートゾーンのトラストアンカー（公
　開鍵）が公開され、ルートゾーンにおけるDNSSECが正式稼動します。

■DURZを導入する理由

このように今回のDNSSEC導入では、DURZの導入というやや複雑な手順が採用さ
れています。ではなぜ、このような方法が採用されたのでしょうか。

その理由は、もし最初から正規の署名データをルートゾーンに導入した場合、
「DNSSECの有効化」と「応答サイズの増大」という二つの大きな変更、すなわ
ち実際のインターネットに大きな影響を与える可能性のある大きな変更を、同
時に導入してしまうことを回避するためです。

今回デザインチームが採用した導入方法では、まずDURZをルートサーバに段階
的に導入していくことにより「応答サイズの増大」による悪影響がないことを
検証し、それが完了した後にDURZを正規の署名データに差し替えることで
「DNSSECの有効化」を行う、という手順を取ることにより、二つの変更を同時
に導入することを回避しています。

なお、もし各段階の作業により万一、インターネット上で何らかの問題が発生
した場合には、前段階への速やかな設定切り戻しと問題の調査・対応が行われ
ることになっています。

■ハッシュアルゴリズムの違いに注意

現在、DNSSEC検証の際に使用されているハッシュアルゴリズムであるSHA-1は、
セキュリティの強度的に不十分であると言われており、2010年以降、電子署名
のハッシュアルゴリズムとしてSHA-1の使用を停止するよう、米国政府から勧
告されています（*4）。

このような背景からデザインチームでは、ルートゾーンへのDNSSEC導入の際に
使用するハッシュアルゴリズムとして、次世代のハッシュアルゴリズムである
SHA-2の一つである、SHA-256の使用を表明しています。

DNSSECでは、暗号アルゴリズムとハッシュアルゴリズムの組み合わせを一つの
アルゴリズム番号で定義していることから、新しいハッシュアルゴリズムを導
入するためのプロトコル拡張（「RSASHA256」と「RSASHA512」のアルゴリズム
番号の追加）が必要になりました。そして、このプロトコル拡張は、2009年
10月に発行されたRFC 5702で定義されました。

現時点でRFC 5702をサポートしているDNSサーバの実装は、最新のUnbound
1.4.0と、現在リリース候補版が公開されているBIND 9.7以降のバージョンに
なります。

なお、BIND 9の現在のリリース版であるBIND 9.6.1-P2ではRFC 5702はサポー
トされておらず、SHA-2が使用されているゾーンに対するDNSSEC検証ができな
いため、キャッシュDNSサーバを運用する場合には注意が必要です。

（*4）「暗号の2010年問題」と呼ばれています。

■2010年は「DNSSEC導入元年」に

デザインチームは今後のDNSSEC導入作業について「過程と手順をインターネッ
トコミュニティに対しでき得る限り公開し、透明に進める」と表明しています。
また現在デザインチームでは、ルートゾーンにおいて実際に使用する鍵（KSK
とZSK）の管理ポリシーについての草案（関連URIを参照）を公開しており、コ
メントや提言を受け付けています。

ルートゾーンへのDNSSEC導入が完了することで、DNSSEC導入における大きな障
壁の一つとなっている「ルートゾーンにDNSSECが導入されていないこと」が解
決し、DNSSECの世界的な普及に向けた活動が活発化していくことになります。
2010年は2009年以上にDNSSECが注目され、かつ実際に利用される年となること
でしょう。

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

◎関連URI

　- Root DNSSEC
　　http://www.root-dnssec.org/
　　（ルートゾーンのDNSSEC署名に関する公式サイト）

　- DNSSEC for the Root Zone
　　http://www.ripe.net/ripe/meetings/ripe-59/presentations/abley-dnssec-root-zone.pdf
　　（RIPE59において発表されたルートゾーンの署名に関する発表資料）

　- DNSSEC for the Root Zone
　　http://www.iepg.org/2009-11-ietf76/rootsign-ietf76-iepg.pdf
　　（IETF76におけるIEPGミーティングで発表された、ルートゾーンの署名に
　　　関する発表資料。RIPE59のもののバージョンアップ版。）

　- Domain Name System Security Extensions (DNSSEC)
　　http://www.ntia.doc.gov/dns/dnssec.html
　　（米国商務省の電気通信情報局（NTIA）で公開されているDNSSEC関連情報。
　　　「Draft Documents」のところから、デザインチームが作成中のドキュ
　　　メント草案が入手できる。）

　- Secure Hashing - Approved Algorithms
　　http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html
　　（米国国立標準技術研究所（NIST）による勧告）

　- RFC 5702: Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG
　　Resource Records for DNSSEC. J. Jansen. October 2009.
　　http://www.ietf.org/rfc/rfc5702.txt
　　（RFC 5702: DNSKEYとRRSIGレコードへのSHA-2アルゴリズムの使用）

━━━━━━━━━━━━━━━━━━━━━━━━━━━【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.