DNSSECの導入状況とDNSSEC運用ガイドラインの改良に向けた取り組み

今回の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問い合わせ状況の変化について分析した結果が発表されました。


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

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の導入が完了する見込みです。

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

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


発表で報告された主な分析結果を以下に示します。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が順次導入されていくことになります。

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

前述の通り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）」という概念を導入し、それぞれの場合の移転の標準的な運用手法をまとめるための提案が行われました。

「協力的な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が今後もその役割を果たしていくためには、従来からの技術面や運用面の標準化のみにとどまらず、ビジネス面や業務面における運用可能性や普及可能性をも含んだ、総合的な検討が必要不可欠になっていくでしょう。



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