JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト

ドメイン名関連会議報告

2009年

ルートゾーンへのDNSSECの導入と展開

～DNSSECの世界的普及に向けた大きな一歩～

2009/12/16

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の導入と展開に関する最新動向についてご紹介します。



IETF76の様子
IETF76の様子


ルートゾーンの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/
組織名は日本語の「綺麗」に由来しており、サイトのトップページには片仮名で「キレイ」と書かれています。
ルートDNSSECデザインチームのメンバー（IETF76より）
ルートDNSSECデザインチームのメンバー（IETF76より）


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

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検証を不可能にした、ダミーの署名データになります。


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

    DURZ（IETF76での発表資料より）
    DURZ（IETF76での発表資料より）


    1. 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
    2. 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サーバの実装は、最新のUnbound1.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

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