増刊号
vol.100

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2010-04-23━
　　　　　　　　　　◆ FROM JPRS 増刊号 vol.100 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　DNSSECの導入状況とDNSSEC運用ガイドラインの改良に向けた取り組み
　　　　　　　　～第77回IETF Meetingにおける話題から～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

今回のFROM JPRSでは、2010年3月21日から26日にかけて米国アナハイムで開催
された第77回IETF Meeting（以下、IETF77）で議論された話題の中から、
DNSSECの導入状況とDNSSEC運用ガイドラインの改良に向けた取り組みについて
お伝えします。

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

■ルートゾーン及びarpaゾーンへのDNSSEC導入状況

▼ルートゾーンへのDNSSEC導入状況

2010年7月のルートゾーンにおけるDNSSECの実運用開始に向け、ICANNに組織さ
れた「ルートDNSSECデザインチーム（以下、デザインチーム）」により、
DNSSECの導入に向けた作業が進められています。デザインチームではDNSSECの
導入がインターネットに悪影響を及ぼすことのないよう段階的かつ慎重に作業
を進めており、作業の進行状況は関係者が集まる会議などの場で随時発表され
ています。

今回の会議では、デザインチームから現在までの進行状況と、各ルートサー
バーにDURZ（*1）を導入した際のDNS問い合わせ状況の変化について分析した
結果が発表されました。

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

DURZの概要及び導入の経緯についてはFROM JPRS 増刊号 vol.97「ルートゾー
ンへのDNSSECの導入と展開」（*2）をご参照ください。

（*2）FROM JPRS 増刊号 vol.97「ルートゾーンへのDNSSECの導入と展開」
　　　http://jpinfo.jp/event/2009/1216DNSSEC.html

▼DURZ導入は2010年5月までに完了予定

DURZは2010年1月27日のL-rootへの導入を皮切りに、2月10日にA-root、3月3日
にI-root及びM-root、3月24日にD-root、E-root及びK-rootに順次導入されま
した。残りのルートサーバーのうちJ-rootを除く5台のルートサーバーには4月
14日に（*3）、最後の1台となるJ-rootには5月5日に導入され、ルートサー
バーへのDURZの導入が完了する見込みです。

（*3）本会議終了後、予定通り2010年4月14日にDURZが導入されました。

▼DURZ導入による問い合わせ状況の変化

今回の発表では、DURZの導入前後における各ルートサーバーのDNS問い合わせ
状況の変化について、DNS-OARC（*4）の協力によりさまざまな分析を実施した
結果が公開されました。具体的には、それぞれのルートサーバーにDURZを導入
した際のプライミング（*5）問い合わせの数と応答サイズ、UDP及びTCPにおけ
るDNS問い合わせ数と比率、あるサーバーにDURZを導入した際の各ルートサー
バー間における問い合わせ数と全体の比率などについて、分析が行われていま
す。

（*4）DNS-OARC: The DNS Operations, Analysis, and Research Center
　　　インターネットで広く利用されているDNSに関する運用、分析、調査研
　　　究に関する各種活動を通じ、DNSをより安全で高品質なものとすること
　　　を目的として、2004年に設立された国際組織です。
　　　https://www.dns-oarc.net/

（*5）プライミング: priming
　　　キャッシュDNSサーバーの起動時にルートサーバーにルートゾーン自身
　　　のDNSサーバー情報を問い合わせ、キャッシュDNSサーバーが持っている
　　　ルートサーバー情報（ヒント情報）を初期化すること。

発表で報告された主な分析結果を以下に示します。DURZの導入に伴い、導入の
妨げとなる大きな異常はこれまで発生しておらず、ルートゾーンへのDNSSECの
導入作業は順調であることが、分析結果においても裏付けられています。

　・DURZを導入したルートサーバーでは署名情報により平均応答サイズが増加
　　したが、それらのルートサーバに対するプライミング問い合わせの数には、
　　DURZの導入前と導入後において大きな変化がみられなかったこと

　・DURZの導入後に該当ルートサーバーにおけるTCP問い合わせ数が増加した
　　が、それぞれのルートサーバーにおける導入後のTCP問い合わせ数は40～
　　100query/sec程度であり、ルートサーバーの運用に悪影響を及ぼすもので
　　はななかったこと

　・DURZの導入後に各ルートサーバー間における問い合わせ数の差が若干小さ
　　くなり、問い合わせの分布が平均化されたとみられること

DNS-OARCによる分析作業は現在も継続中であり、結果は今後も随時発表される
予定です。

▼arpa配下の各ゾーンにもDNSSECを導入へ

また今回デザインチームから、現在ルートサーバーで管理されているarpaゾー
ン（*6）、及びその配下にある主なゾーンへのDNSSECの導入状況と導入予定に
ついて、以下の計画が発表されました。

　・arpaゾーンへのDNSSEC署名を2010年3月17日に開始

　・現在ルートサーバーで管理されているin-addr.arpaゾーンは、RIR及び
　　ICANN/IANAの権威DNSサーバーによる管理に、数カ月以内に移行される予
　　定

　・既にDNSSECが導入されているe164.arpaゾーンについては、2010年6月に
　　ゾーンを管理するRIPE NCCからarpaゾーンに対し、DNSSECの信頼の連鎖を
　　確保するためのDSレコードの追加を依頼予定

　・uri.arpa、urn.arpa、ip6.arpaの各ゾーンについては、DNSSEC導入実施の
　　ための提案書をICANNから米国商務省に提出済み。また、既に内部的な
　　DNSSEC署名のテストを実施済みであり、提案書が承認され次第数週間以内
　　に、実際のDNSSEC署名を開始する予定

このように、ルートゾーンへのDNSSECの導入と相前後する形で、インターネッ
トインフラ管理用のゾーンであるarpa配下の各ゾーンについても、DNSSECが順
次導入されていくことになります。

（*6）歴史的な経緯により、J-rootはarpa/in-addr.arpaゾーンを管理してい
　　　ません。

▼大きくなる応答サイズへの対応は必須

前述の通り2010年5月5日にDURZの導入が完了し、全てのルートサーバーのDNS
応答サイズが大きくなります。このため、もし各組織のキャッシュDNSサー
バーにおいて大きなDNS応答サイズの取り扱いが不適切であった場合、名前解
決に悪影響を及ぼす可能性があります。

DNS-OARCでは、キャッシュDNSサーバーで取り扱い可能なDNS応答サイズを確認
するためのテスト環境を、以下のページで公開しています。各組織のネット
ワーク管理者の方は2010年5月5日までに自組織のキャッシュDNSサーバーを
チェックし、必要な対応をされることを推奨します。

　OARC's DNS Reply Size Test Server | DNS-OARC
　https://www.dns-oarc.net/oarc/services/replysizetest

■DNSSEC運用ガイドラインの改良に向けた取り組み

▼現在のDNSSEC運用ガイドラインはRFC 4641で定義

インターネットにおいてDNSゾーンの運用者がDNSSECを円滑に運用するための
運用上の慣習（Operational Practices）は、2006年に発行されたRFC 4641と
してまとめられています。RFC 4641には鍵の生成・保管、署名の生成、鍵の移
転など、実運用において考慮すべき課題とその対応がそれぞれの項目ごとに記
述されており、DNSSECの運用ガイドラインとしての役割を担っています。

しかし、DNSSECの導入が具体化していく中で、現行のRFC 4641では不十分な点、
特に、レジストラ間においてドメイン名を移転する際に考慮すべき点が不十分
であることが顕在化してきました。

▼DNSSECとドメイン名の移転

レジストラが顧客のドメイン名とともに権威DNSサーバーも受け持っている場
合、レジストラ間においてドメイン名を移転する際の権威DNSサーバーの変更
における大まかな流れは、以下のようになります（*7）。

　（1）移転先レジストラが新しい権威DNSサーバーを設定する

　（2）移転先レジストラが新しい権威DNSサーバーの情報をレジストリに登録
　　　 （変更）する

このように従来のDNSでは、基本的に顧客を受け入れる移転先レジストラ側の
作業により、DNSの権限委任構造が切れない形で作業を進めることが可能です。

しかし、DNSSECが導入されたドメイン名について同様の移転を行う場合、従来
のDNSの権限委任構造に加え、DNSSECによる信頼の連鎖（chain of trust）の
取り扱いにも配慮する必要があります。そのため、移転作業をより慎重に進め
る必要があり、従来の移転作業に比べ、手順が複雑になります。

このため、DNSの運用について議論するDNSOP WGでは現在作成中のRFC 4641の
改訂版（以下、4641bis）において、DNS運用者の変更の際に新たに「協力的な
DNS運用者（Cooperating DNS Operators）」と「非協力的なDNS運用者（Non 
Cooperating DNS Operators）」という概念を導入し、それぞれの場合の移転
の標準的な運用手法をまとめるための提案が行われました。

（*7）レジストラの変更手続きなど、権威DNSサーバーの設定や登録変更に直
　　　接関係しない作業については、本稿では省略しています。

▼「協力的なDNS運用者」間によるドメイン名移転～公開鍵と署名情報を共有

現在検討中の4641bisでは「協力的なDNS運用者」間におけるドメイン名の移転
の際の手順の典型的な流れを、以下のように定めています。

　（1）移転先レジストラが新しい権威DNSサーバーと新しい鍵を設定する

　（2）移転元レジストラは移転先レジストラから、移転先レジストラは移転
　　　 元レジストラからそのドメイン名の公開鍵（DNSKEYレコード）、及び
　　　 その公開鍵に対する署名情報（RRSIGレコード）の提供を受ける

　　　 （注）相手のレジストラに渡す必要があるのは公開鍵と公開鍵に対す
　　　　　　 る署名情報のみであり、秘密鍵の情報を渡す必要はない

　（3）双方のレジストラが自分と相手の双方の公開鍵、及び公開鍵に対する
　　　 署名情報を、それぞれの権威DNSサーバーで公開する

　（4）移転元レジストラにおいて、移転先レジストラのDNSサーバーホストを
　　　 NSレコードに追加する

　　　 （注）作業後に移転元レジストラのNSレコードは、移転元レジストラ
　　　　　　 の鍵で署名される必要がある

　（5）移転先レジストラが新しい権威DNSサーバーとDSの情報をレジストリに
　　　 登録（変更）する

　（6）移転先レジストラが移転元レジストラの公開鍵と署名情報を、自分の
　　　 権威DNSサーバーから削除する

このように4641bisでは、移転元と移転先のDNS運用者が互いに協力することで
該当ドメイン名の新旧の公開鍵とその公開鍵に対する署名情報を双方の権威
DNSサーバーで公開し、DNSSECによる信頼の連鎖が切れない形でドメイン名を
移転するという手法を定めています。

▼「非協力的な運用者」間によるドメイン名移転～手法標準化が今後の課題に

しかし、商用化が進んだ現在のインターネットにおいてこのような協力が実際
に成立するのかについては、単に技術的要件や運用的要件のみにとどまらず、
ドメイン名移転の際の具体的な業務の流れ、ひいてはレジストラやDNS運用サー
ビスプロバイダといった各関係者における業務形態や利害関係をも含んだ、総
合的な検討が必要になります。

そのような状況から4641bisでは、DNS運用者が変更作業に際し協力的ではなく、
鍵情報の共有や相手方の鍵を用いた署名などが期待できない「非協力的なDNS
運用者」という概念を新たに導入し、このような場合のドメイン名移転におけ
る運用の手法をどのように標準化すればよいかについて、今後の検討を進めて
いくこととなりました。

▼「インターネットをよりよく機能させる」ために

このような、いわばビジネス面をも含めた総合的な検討は今回のDNSSEC運用ガ
イドラインに限らず、商用化されたインターネットサービスにおける運用・普
及を前提とした標準化作業において、今後ますます必要になっています。

IETFのホームページにはその役割として「インターネットをよりよく機能させ
る（make the Internet work better）」と書かれています。IETFが今後もそ
の役割を果たしていくためには、従来からの技術面や運用面の標準化のみにと
どまらず、ビジネス面や業務面における運用可能性や普及可能性をも含んだ、
総合的な検討が必要不可欠になっていくでしょう。

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

◎関連URI

　- IETF 77 - Anaheim, CA, USA
　　http://www.ietf.org/meeting/77/
　　（IETF77ホームページ）

　- IETF 77 Preliminary & Interim Materials
　　https://datatracker.ietf.org/meeting/77/materials.html
　　（IETF77発表資料一覧）

　- DNSSEC for the Root Zone - IEPG - IETF 77 Anaheim, USA March 2010
　　http://www.iepg.org/2010-03-ietf77/joe.pdf
　　（ルートゾーンへのDNSSEC導入に関する発表資料）

　- Root DNSSEC
　　http://www.root-dnssec.org/
　　（ルートゾーンへのDNSSEC導入公式サイト）

　- DNSSEC Operational Practices, Version 2
　　http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-02
　　（DNSSEC運用ガイドラインの改訂版インターネットドラフト）

━━━━━━━━━━━━━━━━━━━━━━━━━━━【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), 2010 Japan Registry Services Co., Ltd.