DNSSECの導入に向けて―より安全なインターネットの実現のために

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をインターネットで実運用するために必要な基本プロトコルが整いました。

DNSSEC導入に向けた機運の高まり

DNSSEC関連プロトコルの整備、社会インフラとしてのインターネットの重要性の高まり、また2008年に発見された「カミンスキー・アタック（*2）」のような新しいDNSキャッシュポイズニングの攻撃手法などにより、DNSSECの導入に向けた機運が高まってきました。


これらの状況を受けICANNは、セキュリティと安定性に関する諮問委員会（SSAC）、ルートサーバシステム諮問委員会（RSSAC）などの専門家のコメントを参考にしながら、DNSSECの導入に関する検討を進めてきました。

そして、ICANNは2009年6月に、米国政府、米国ベリサイン社（以下、ベリサイン）と協働して、2009年中にルートゾーンでDNSSECを稼動させることを目標に活動を開始する旨を表明しました（*3）。

DNSSECワークショップにおける主な話題

このような動きを受け、今回のICANNシドニー会合で開催されたDNSSECワークショップの関心は高く、50人収容の会場はほぼ満席となりました。

今回のワークショップでは.orgを始め、実際にDNSSECを導入し始めているTLDからの状況報告や、ルートゾーンにDNSSECを導入する際の各種鍵（*4）の管理モデルの検討状況、現在IANA（*5）が試験運用している「暫定トラストアンカーリポジトリ（Interim Trust Anchor Repository: 以下、ITAR）」の状況など、インターネット全体でのDNSSECの実運用を前提とした発表・議論が多く行われたことが特徴的でした。


以下、興味深い発表内容をいくつかご報告します。

ルートゾーンにおける鍵の管理

ルートゾーンは現在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ワークショップの公式ページに紹介されています。

トラストアンカーリポジトリ（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導入、普及促進のための活動を通じ、より安全なインターネットの実現のための活動を今後も継続していきます。



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