---

ICANN DNS Security Update #1
翻訳文

（社）日本ネットワークインフォメーションセンター
最終更新 2003年2月5日

この文書は2002年1月4日に公開された
http://www.icann.org/committees/security/dns-security-update-1.htm
を翻訳したものです。
JPNICはこの翻訳を参考のために提供しますが、その品質に責任を負いません。

---

2002年1月4日

ICANN DNS セキュリティ アップデート #1

　9月11日の米国同時テロ発生を受け、現在 ICANN はインターネット上のネーミングおよびアドレス割り振りシステムに関連するセキュリティ対策に積極的に取り組んでいる。本文書では、ICANNの取り組みの背景にある諸要因をはじめ、ICANN が最近開催した DNS セキュリティに関するミーティングの成果や、ICANN が今後進むべき次なるステップ、ICANN構成組織について解説する。

(注: 本文書は全般的な概説に重点を置いたものであり、一部の分野においては、一般の技術職でない読者が理解できるよう、複雑な内容を簡略化して説明している。また、2001年11月のICANNのミーティングに参加された個人発表者、パネリストの意見も必ずしも反映していない。改善に向けたご提案を募集する。)

ICANNとDNSおよびDNSセキュリティの概要

　ICANN は、非営利の国際組織で、インターネットの根幹をなすユニークな識別子のシステム (最もよく知られているものにドメインネームシステム (DNS) がある) の調整を行っている。DNS は分散型のオンライン・データベース・システムで、人間にわかりやすいドメイン名を、数値表現によるインターネットプロトコル（IP）アドレスに変換するものである (たとえば、DNS は www.icann.org を 192.0.34.65 に変換する)。

　DNS は階層的に構成されている。ICANN は、トップレベルドメイン名データベースのオペレータ (「レジストリ」) の指定と調整を行っている。トップレベルドメイン (TLD) のレジストリは、各トップレベルドメイン名（.de、.net、.info など）の、 権威ある、 一般からアクセス可能な、オンライン・データベースサービスを提供するものである。また、第2レベルまたは第3レベルドメイン名（icann.org、buckingham-palace.co.uk など）の登録を行った登録者は、自分のドメインに関連する DNS サービスの管理を行う。更に、一部の TLD レジストリは登録者に直接的な登録サービスを提供しておらず、認定された特別な会社 (以下「レジストラ」という) のネットワークを使用している。レジストラは登録者獲得に向けてしのぎを削っており、オンライン・レジストリデータベースへの変更を承認したり、料金徴収の処理を行っている。

　こうした役割が分散化した枠組みの中にあって、ICANN の主な役割は、TLD と IP アドレスのためのグローバルポリシーを設定し、インターネットにおけるネーミングおよびアドレス割り振りシステムを安定化させ、統合を図っていくことである。また、特定の国に依存しないトップレベルドメイン・レジストリ (.com、.net、.org、.biz、.info、.name など) については、ICANN は競争の激しいレジストラを認可する中立的な機関としての役割を担っており、各社が認定契約および公開 DNS 基準に準拠しているかどうかを監視している。ICANN はまた、直接的にさまざまなサービスを提供している。その中にはルート DNS ゾーンファイルの管理サービスがあり、これはトップレベルドメイン・レジストリと各ドメインのマスタネームサーバーを記載した認可リストで、13 のルートネームサーバーシステムを経由して公開されている。これらのサービスの多くは、「IANA 機能 (IANA function)」として知られている。ICANN が 1998 年に設立されるまで、このサービスは Internet Assigned Numbers Authority (IANA) により提供されてきた。

　このように、ICANN は、インターネットの全般的なセキュリティを業務範囲としているわけではなく、また各 DNS レベルにおける運営上の責任を負うものでもない。また技術的なプロトコルも ICANN の担当範囲ではない。これらはプロトコル管理組織により定義作成が行われている。こうした組織には、Internet Engineering Task Force などがあり、ICANN の Protocol Support Organization を構成する一員となっている。しかし、トップレベルにおける調整と、DNS のグローバルなポリシー策定は ICANN が担当しており、インターネットのネーミングおよびアドレス割り振りシステムの統合化と安定化の面では中心的な役割を演じている。

DNS セキュリティに関する ICANN ミーティングの概要 (2001 年 11 月開催)

　この分野で中心的な調整役を果たしている ICANN の役割、そして 9 月 11 日の米国テロ攻撃の影響を鑑み、ICANN の年次総会 (11 月中旬に Marina del Rey にて開催) では、インターネットのドメイン名およびアドレスの割り振りシステムのセキュリティが主要議題となった。総会にはインターネット・コミュニティから 1,100 名以上の参加者があり、レジストリマネージャ、運営スタッフ、DNS テクニカル・エキスパートをはじめ、政府機関、産業界、研究機関、マスコミ、一般ユーザーなどさまざまな分野から、高い関心を持つ人々が参加した。

　3日間の会期中、参加者は以下の事項に関して綿密な調査を実施した。1) インターネットのドメイン名およびアドレス割り振りシステム関連のセキュリティ上の必要要件、2) それらの必要要件が現時点でどの程度まで満たされているか、3) 緊急事態においてもドメイン名およびアドレス割り振りシステムの連続的な運用を行うためのセキュリティ環境を作り上げるためには、個人・組織・全体レベルでどのようなアクションが必要になるか。

　総会の議題を具体的に挙げると、以下のようなものになる。

　このプログラムは、DNS セキュリティの管理面と技術面の調和を取ることを目指しつつ、ドメイン名とアドレス割り振りシステムの安定化と統合化という ICANN の守備範囲を逸脱しないことを目的としていた。

　本プログラムの特徴は、すべてを統括する議長、トピックごとの設けられた委員会、管理および運用面/技術面から考察を行う並行セッション、参加者の分野ごとに開かれたミーティングであるということだ。本プログラムの最後には、ICANN の各部門のさまざまなグループの代表が、コミュニティに対し報告書を作成し、これには具体的な将来の施策の一覧などが記載された。

　ミーティングのマルチメディア版アーカイブは以下のサイトから入手できる。
http://cyber.law.harvard.edu/icann/mdr2OO1/archive

一般的な議題

　はじめに、日本の総務省小坂副大臣から歓迎の基調演説が行われた。小坂副大臣は、インターネット－特にドメイン名およびアドレス割り振りシステム－が国際経済と国際コミュニケーションに対して果たしている重要な役割を総論的に強調され、会議の基調を示した。小坂氏が強調した点は次のとおりである。「 インターネットはルートネームサーバーのみでは稼働しない」「インターネットのセキュリティと安定性の確保は、インターネット・コミュニティ、業界、個人、政府の各メンバーの双肩にかかっており、すべてのメンバーが世界的、地域的、国家的レベルでそれぞれの役割を果たすべきである」。

　冒頭の技術面での基調演説は、著名なインターネット・セキュリティの専門家で、AT&T Lab の研究員である Steve Bellovin 氏により行われた。以後行われるディスカッションの方向性を決定するため、Bellovin 氏は「ICANN はインターネット・セキュリティの問題のすべてを解決することはできない。それは行うべきことではない。ICANN にできること、そしてやるべきことは、インターネットが依存しているネームとアドレスのサービスの保護をより強固なものにしていることである。」と述べた。Bellovin 氏は、ICANN が担当範囲とすべき 3 つの重要な領域を特定した。それは IP アドレス割り振り、ドメインネームシステム管理、そして DNS ルートネーム サーバー管理の 3 つである。

　IP アドレス割り振りについて、Bellovin 氏は、割り当てに関連するかなりの量の不正確なデータが存在していると指摘した。安全なルーティングには、アドレスが割り当てられる組織に関する正確なデータが必要だ。不正確なデータの問題点は、割り当ての時期が古いものになるほど特に顕著である。ここで ICANN は、これらのデータの品質に責任を負っている地域インターネットレジストリと ISP と協力して作業していく必要がある。

　DNS ルートネームサーバーについては、Bellovin 氏は、以下のような数多くの問題点を指摘した。ホストのセキュリティ、利用可能性、ルーティング、そしてさまざまなソフトウェアが実行されないままになっていることなどである。DNS は高度に分散化した性質を持っているため (たとえば、ISP がネットワークをまたがったルーティングを制御し、ルートネームサーバー・オペレータが自らのホストソフトウェアを決定しているなど)、ICANN は協力して作業を行っていく上で調整役を果たす必要があり、また多岐にわたる組織との間で改良に向けた議論を深める必要がある。

　DNS 自体については、Bellovin 氏は、「不心得ものはセキュリティ・チェックを受けずにそれをすり抜けようとする」と形容して、DNS の複雑性を強調した。これらに対応しつつ、全体的なシステムのセキュリティを確保すべきである。これに含まれるものは、ネームサーバー、リゾルバ、ネームおよびアドレスのレジストリ (各レジストリのホスト、データベース、ソフトウェア)、認可されたレジストラ (各機関のホスト、データベース、ソフトウェア)、レジストリ-レジストラ間の通信と顧客-レジストラ間の通信のプロトコル、およびさまざまなバックエンド・プロトコルとソフトウェアなどである。

　ICANN は、オペレーティング・システムの選択やプロトコルの定義について口を差し挟むことはできないし、すべきでもない。ただし、ICANN は、この作業は、レジストリ、レジストラ、ルートサーバー・オペレータ、ユーザーとの協議のもと、それらが必要とする要件を調査作成することは可能であるし、行うべきである。

　Bellovin 氏が取り上げたテーマは、3 日間のミーティングにおいて議論が深められ、応用が行われた。そしてこの枠組みが理にかなっているという点について広範な賛同を得たのである。さまざまな部門別グループは、内容の優れた報告書の草案を作成するための実行計画に総じて協力を表明した。この報告書は、グループごとに必要とされる要件を詳細に記述し、将来取り組みが必要な領域を特定するものである。

　さらに、ICANN が運用面で責任の一端を担うべき特定のステップに関する、一連のテーマが取り上げられた。これらのステップは、本アップデートの末尾に、その概要を記載した。

　その他の基調講演者では、U.S. Critical Infrastructure Assurance Office の John Tritak が、政府は推進役を演じることはできるが、インターネット・セキュリティの確保においては民間セクターが主導権を持つ必要があることを強調した。また Counterpane Internet Security, Inc. の最高技術責任者である Bruce Schneier は、「柔軟さを持つセキュリティ － 現在の取り組み」と題して講演を行い、セキュリティに必要な、保護、検知、修復の 3 要素を強調した。Schneiner 氏は、100 ％完全なプロテクトを追求することに人気が集まっているが、善玉と悪玉の間で繰り広げられる「セキュリティ能力競争」では、完全なプロテクトは達成したと思ったら破られるものであると述べた。むしろ、積極的なセキュリティ戦略では、実現したい内容によって 3 つのアプローチ間の最適化を図る必要がある。実際には、このアプローチは、検知と修復にもっとも重点を置いたものになる。

　以降のセクションでは、ICANN 総会で行われた重要な報告の概要を紹介し、それらの報告の中で行われた評価、結論や、次なるステップを紹介する。

DNS ルートネームサーバー・システム

　2001 年 11 月の ICANN 総会で発表されたコミュニティ向けの一連のプレゼンテーションでは、DNS ルートネームサーバーのオペレータが、システムの分散化アーキテクチャは、悪意ある攻撃または緊急事態に直面した際に最も能力を発揮する点を強調した。今なおシステムの改善がいくつか計画されている。このセクションでは、DNS ルートネームサーバー・システムの概要を紹介した後、セキュリティ面で考慮すべき点について論じることとする。

　ドメイン名の解決は、ルート・ドメインネームサーバーの稼働の信頼性と安定性にかかっている。その根本的な設計上の前提がシングルルートの階層的ネームスペースになっているため、DNS は限られた定義済みのインフラストラクチャ要素に依存する数少ないインターネットプロトコルの 1 つとなっている。インターネット・ネームスペースのルートは、別々の組織が運営している地理的に分散化された 13 のルートネームサーバーを経由して利用できる。最悪のシナリオでは、13 すべてのルートネームサーバーのネームからアドレスへの変換 (またはその逆の)機能が働かず、インターネット機能の稼働に深刻な障害を生じるであろう。

　ルートネームサーバー・システムは、DNS プロトコル、ルートゾーンファイル、ルートネームサーバーの 3 つの主要なコンポーネントから構成される。

　DNS プロトコルは重要なインターネット・データベースを定義するものである。このデータベースはさまざまなサーバーを経由して配信され、クライアント・ソフトウェアが覚えやすいセグメント名を IP アドレスに変換する際や、メールボックス・アドレス宛のメールを受信するホストを検索する際に使用される。

　インターネット・ネームサービスのルートは、単一のルートゾーンファイルから構成され、このファイルは、トップレベルドメインやその関連レコードのデレゲーションで、DNS プロトコルがこれらのデレゲーションを実行する際に必要となるものである。現在、このファイルは、プライマリサーバー (「a.root-servers.net」) から 12 のセカンダリサーバーを経由して利用可能である。このファイルの変更は IANA がコントロールしており、変更 (一般にはトップレベル ドメイン用の同一サーバーの変更) は 1 週間に約 1～2 回行われている。a.root-servers.net のプライマリ・ルートネームサーバーは、アメリカ政府との契約に準拠しつつ VeriSign Inc. により運営されている。マスタゾーンファイルがいったん作成されると、そのファイルは障害回復サイトに複製され、オフサイトのロケーションにバックアップが保管される。ゾーンファイルの修正は、高度な検証システムを通して行うことになっており、これには、修正が公表される以前の手作業による厳密な調査が含まれる。

　ルートネームサーバーは、適切な DNS プロトコル運用のためのルートゾーンファイルへのアクセスを可能にするマシンである。プロトコル上の制約により、ルート ネームサーバーの数は現在 13 に制限されているが、この制限を回避するための作業が現在進行中である。これらの 13 サーバーを、異なる組織、異なるロケーション、異なるオペレータ タイプ、異なる運用環境で分散管理する試みは鋭意行われてきた。多様化を行えば、同一のアプローチで 13 すべてのルートサーバーを攻撃することがより困難になり、一定の保護機能を実現できる。本文書の執筆時点では、ルート ネームサーバーは、営利組織、非営利組織、大学、研究機関、NASA、米軍により運用されており、13 サーバーのうち 3 サーバーは米国外に設置されている。ロンドンに 1 つ （オランダから管理される）、日本に 1 つ、スウェーデンに 1 つである。

　ルートネームサーバーのパフォーマンス仕様 (「RFC 2870」と称される文書) では、ルートネームサーバーは、大企業にとり重要なデータセンターに要求されるような物理的なセキュリティを備えることが明記されている。13 台のルートネームサーバーはすべて、専門的な施設に設置されている。すべてのサーバーは、環境面での不測の事態に対しては、ある程度耐えうるように強化されている。この強化点には、物理的なアクセス制御の使用、パワー グリッドと冷却停止に対する保護機能 (長期の停電時の自家発電機能を持つ UPS (無停電電源装置) により保護された電源供給)、レイヤ 1 からレイヤ 3 の多様なインターネット接続性などが含まれる。ルートサーバーにはすべて、若干異なる UNIX オペレーティング システムが使用されているが、ハードウェアベースとベンダーの UNIX は相対的に異なっている。13 台の ルート サーバーには、5 つのベンダーの 8 つのオペレーティングシステム・バージョンを実行する 7 つのハードウェア・プラットフォームが存在している。

　ルートネームサーバーにとって不幸な点は、13 台すべてのルートネームサーバーが使用不能となった場合、多くのインターネットサービスが利用できなくなるという点だ。しかし、良い点もある。インターネットが接続できないということはルーティングの情報が急激に変化する可能性があることを意味するのである。これはルーティング情報は、参照先のサイトによりシステムに付与されるものだからである。別の言い方をすれば、DNS はサービスだということだ。DNS は、1 台のルートネームサーバーに依存するものではないのである。1 台のルートネームサーバーが機能を停止した場合、他のサーバーが瞬時に代替で機能することが可能である。これは別のロケーションに存在するサーバーでも可能である (ただしドメインネーム・リゾルバによりポイントされた固定 IP アドレスの変更が持つ困難さの度合いにより影響を受ける)。

　ルートサーバー・システムは分散化された予備的な側面を持つが、これにより、たとえば莫大な数の single point of failure (単一機器の故障がシステム全体の障害につながる要素) を防ぐ必要のある公衆電話回線通信システムと比較しても、物理的攻撃に対する脆弱性は小さくなる。

　ネーム サーバーは地理的に幅広く分散しているため、危機的な環境、大災害、単一または複数の攻撃により、すべてのルートネームサーバーが損害を受ける可能性は低い。個々のルートネームサーバーが受信するトラフィック量で考えた場合、40 ％のネームサーバーがオフラインになった状態で、現在の負荷が維持され、障害がほとんど発生しなかった場合には、そのルートネームサーバーは正常に機能すると推測されている。このように、重大な危機や攻撃が発生した場合でも、設置場所が多様化されていれば、障害を発生したネームサーバーの復旧作業中であっても、ルートネームサーバー・システムは正常に稼働することが可能になっている。

　RFC 2870 には以下のように記載されている。「ドメインネームシステムは、ルートサーバーの大半が (おそらく一時的に) 利用不能になった場合でもインターネットの運用には重大な影響を及ぼさないと確信するに足る、十分な強度を持っていることが証明されている」

　しかし、今回の総会でも指摘されたように、ルートサーバー・システムは、DDOS (分散型サービス拒否) 攻撃や関連するソフトウェアベースの脅威に対しては脆弱である可能性がある。DDOS 攻撃に対する保護は、現在のネットワーク・アーキテクチャでは問題が多い。Schneier が提言したように、攻撃の検出と迅速な復旧に論点を移すことが必要となる。

　管理面では、ルートネームサーバーのオペレータは、障害に対する脆弱性を最小限にとどめるため、また攻撃の迅速な検出と復旧を可能にするためのあらゆる対策を行っている。各ルートネームサーバーのサイトは、ゾーンファイルのバックアップコピーを保持しており、万一ルートゾーンファイルの作成や伝送時に障害が発生しても、ルートサーバーは、障害が復旧するまでこのバックアップコピーを使用することができる。加えて、各ルートネームサーバーのオペレータは、他のすべてのオペレータの連絡先情報を (紙媒体で) 保有しており、万一問題点が検出された場合でも、ルートネームサーバーのオペレータは (電話システムが利用できるという前提で) 他のオペレータに連絡を取ることができる。すべてのルートネームサーバーは、最新版の BIND を実行しているため、トラブルシューティングの専門的な知識やネームサーバー解決の問題点を共有できるようになっている。

　ルートネームサーバーのハードウェアの管理に関しては、各ネームサーバーは予備のハードウェアを保有している。一部のケースでは、ハードウェアがホットスペアの形になっており、人為的な操作を行うことで利用可能になっている。またあるケースでは、万一ハードウェアの障害が発生した場合でも、人為的な操作を行うことなく完全なルートゾーンサービスの提供を行うことができる常時稼働の代替マシンとして、ハードウェアが稼働している。しかし、障害発生時には、各ルートネームサーバーのオペレータは、マルチレベルのシステム管理要員を備えており、内部的に設定されたエスカレーション・プロシージャによるサポートを利用できる。

　ソフトウェアとハードウェア以外にも、13 のルートネームサーバーのオペレータは、異なる性質と異なる組織的な設定をミックスしつつ、さまざまなシステムをミラー化している。それにもかかわらず、これらのオペレータは信頼関係に基づく強固な社会的ネットワークを形成しており、情報を共有するための、古い歴史を持つ暗号化通信チャネルを使用している。

　ルート サーバーのオペレータは、ルートネームサーバー・システムのセキュリティ機能向上の計画を数多く作成し、取り組んできた。これには、ゾーンファイル更新の分散化用の専用プライマリの使用などが含まれる。

分野別トップレベルドメイン（gTLD）レジストリ

　現行の gTLD レジストリ － .com，.net，.org，.info，.biz，.name，.aero，.coop，.museum など － の管理を担当する組織は、DNS の安定性と統合性にとり重要な役割を担っている。gTLD レジストリは、その TLD 内のすべての名前について、信頼できるデータベースを保持している。加えて、gTLD レジストリは、Whois データベースサービスなどさまざまな関連サービスを提供している。これはドメイン名登録の登録情報を、オンラインで無料で検索できるサービスである。gTLD レジストリの多くでは、登録者とのやりとりは実際には、競合レジストラ企業により処理されている。

　11 月の ICANN 総会において、gTLD レジストリ部会は、Registry Security Best Practices (レジストリ・セキュリティの最善の行動規範）の包括的な声明文の草案を作成するため、共同で作業を行った。2001 年 6 月には、gTLD レジストリ・オペレータは、Registry Failure Task Force (レジストリ障害タスクフォース) を創設し、レジストリが失敗するケースの処理手順の研究と作成を開始した。レジストリ障害の原因には、自然災害、悪意のある攻撃、テクニカルエラーなどが考えられる。2001 年 11 月の ICANN 総会への準備作業として、gTLDレジストリ・オペレータは、タスクフォースの役割を拡大し、レジストリ・セキュリティをテーマに含めるとともに、各レジストリからの技術面での代表をメンバーに加えることとなった。11 月 14 日にコミュニティに対して公開した同部会のレポートでは、gTLD レジストリが、「インターネットの安定運用の保護と推進に対する最優先の努力」を再度表明しており、「この努力において最も重要な要素は、すべてのレジストリの運営面での統合を確実なものにすることである」という認識を示している。

　「Registry Security Best Practices (レジストリ・セキュリティの最善の行動規範)」の文書は、信頼性とパフォーマンスという、運用面での統合において重要となる 2 つの要素に焦点を当てている。具体的に言えば、DNS にとって必要なのは、インターネットユーザー、ドメイン名所有者、レジストラが、gTLD ネームサーバーの信頼性とパフォーマンスだけでなく、オンライン登録システムにも信頼を寄せていることである。最終的に、「Registry Security Best Practices (レジストリ・セキュリティの最善の行動規範)」の文書には、以下の項目についての仕様が盛り込まれる予定になっている。

　また、gTLD レジストリは、可能な限り CERT Coordination Center (CERT 調整センター) などのような組織と協議の上で、極秘のセキュリティ監査や各レジストリによる自己評価を行っていく必要性についても合意をみた。

国コード・トップレベルドメイン（ccTLD）レジストリ

　gTLD レジストリに加え、DNS には、世界中の国と地理的に区分された地域に対応する 244 の TLD レジストリが存在する。これらの TLD は 2 文字のコードで区別することができる (たとえば .au、.br、.cn、.de、.jp、.uk、.us、.za など)。各 ccTLD はレジストリ・マネージャにより運用されている。このレジストリ・マネージャはローカル・インターネットコミュニティの管理者として活動している。一部の ccTLD レジストリはかなり規模が大きく、数百万の登録を抱えている (.de や .uk など) が、登録数 1000 件以下のかなり小規模なものも存在する (.mz や .om など)。

　一般に、ccTLD レジストリのセキュリティ面の考慮事項は、gTLD レジストリのそれと大差はない。すべてのレジストリは、トップレベルドメイン名登録サービスとネームの解決サービスを提供しているため、レジストリにとっては、オンライン登録システムや情報システム、レジストリとレジストラ間およびレジストリと登録者間の情報のやり取り、自社の TLD ネームサーバー・ネットワークの統合性と信頼性を確保することが必要である。ccTLD マネージャにより繰り返し強調されてきたように、レジストリのセキュリティは、最も脆弱なリンクと同程度の強度しか持っておらず、関連のすべてのパートとプロセスに対し注意を払うことが必要となる。このように、ccTLD レジストリ・マネージャは、内部的なすべての検証作業と、すべての新規サービスまたは手続きの設計に、セキュリティ上の考慮事項を含めることが求められる。ドイツの ccTLD レジストリのマネージャはこう述べている。「セキュリティはステータスではない。セキュリティはコンセプトなのだ」と。

　2001 年 11 月の ICANN 総会では、37 人の ccTLD マネージャのグループとその仲間が DNS セキュリティを議題とした以下の 3 回のセッションを行った。

　ccTLD マネージャは、以下のポイントを中心とした活動項目とタスクフォースの一覧を作成している。

地域インターネット・レジストリ

　ドメイン名の階層下には、数値のインターネット・プロトコル (IP) アドレスが存在する。たとえば、www.icann.org の IP アドレスは 192.0.34.65 となる。インターネット上の各コンピュータは、一意の数値 IP アドレスにより識別される。ドメインネームシステムを使用すると、ユーザーは複雑で長い数字ではなく、覚えやすいテキスト名を使用することができる。インターネット上の指定された受信者にたどり着くためには、データのパケットは通常、受信先のコンピュータのドメイン名で始まるものとなり、DNS を使用して当該ドメイン名に関連する IP アドレスを検索する (これはドメイン名の「解決」として知られる)。そして中間のネットワークに、受信先の IP アドレスへのルーティングを依頼する。

　IP アドレスが必ず国際的に一意のものとなるように、Regional Internet Registry (地域インターネット・レジストリ、RIR) が中心的な役割を果たしている階層システムに従って、IP アドレスが割り当てられる。現在、ARIN(アメリカ大陸とサハラ以南のアフリカを管轄)、RIPE NCC (ヨーロッパ、中東、北部アフリカを管轄)、APNIC (アジア/太平洋地域を管轄) の 3 つの RIR が存在する。各 RIR は、すべての組織に対し、必要十分な IP アドレスを供給する一方で、限られた IP アドレス・スペースが早期に枯渇しないよう温存する作業を行っており、アドレス割り振りにおけるこれら 2 つの対立する考慮事項のはざまでバランスを取っていこうとしているオープンで非営利の会員組織である。

　2001 年 11 月の ICANN 総会で RIR は、RIR 向けのセキュリティ面の考慮事項に関する共同プレゼンテーションを行った。gTLD レジストラのように、RIR は DNS 用の single point of failure (単一機器の故障がシステム全体の障害につながること) を生じさせてはいない。むしろ RIR は、多くのインターネットユーザーが依存している重要なサービスを提供している (逆引きマッピング機能、割り当てられた IP アドレス用の Whois データベース、IP アドレス割り振りサービスの日常業務など)。こうした役割なりに RIR は、中間レベルの IT セキュリティ組織向けの従来の基準に準拠するために、事業体制を構築している。たとえば、サーバー (メンバー データベース、ローカル DNS および Whois サーバー)、ネットワーク、設備、データベース、および DNS 逆引きマッピング機能などがこの例である。

　このように、RIR のセキュリティ関連の業務は、オンライン・サービスプロバイダ向けの一般的な考慮事項で構成される。インターネットサーバーについては、設定、証明、認証、アカウンタビリティ、バックアップ、リカバリの業務。ネットワークについては、セキュリティゾーンの使用 (登録、エンジニアリング、管理/資金調達)、フィルタとファイアウォール、ルータ、逆引きマッピングの業務。施設面については、暖房、換気と空調、火災検知と延焼防止、社員用のアクセス・コントロールとケーブル配線、電源供給とバックアップ電源の業務。

　逆引きマッピング機能は、重要なオンライン DNS サービスで、これを使用すると IP アドレスをドメイン名に変換できる (DNS による、一般的により理解しやすい名称からアドレスへの変換の逆の機能)。RIR は協力してこの機能の管理を行っている。この機能は、ドメイン名「in-addr.arpa」で指定される分散型オンライン・データベースで構成される。IANA は、(Internet Architecture Board との協力のもと) .arpa トップレベルドメインの .arpa とセカンドレベルドメインの in-addr.arpa の管理を行っている。RIR は、in-addr.arpa 下のすべてのゾーンを管理している。これにより、RIR は最新のセキュア DNS プロトコルとツールが標準化され、即導入可能になった際に、それらのプロトコルとツールを利用可能にすべく作業を行っている。これを巡っては、RIPE NCC が Deployment of Internet Security Infrastructure (インターネット・セキュリティ・インフラストラクチャの配備、DISI) というプロジェクトを立ち上げている。これは逆引きマッピング・ツリーにセキュア DNS プロトコルを導入可能かどうかの可能性を検証するものである。

分野別トップレベルドメイン（gTLD）レジストラ

　2001 年 11 月の ICANN 総会で gTLD レジストラは、バックアップ、リカバリ、リストアのセキュリティに関するディスカッションを重視していた。すでに説明したように、 gTLD レジストラは ICANN により認定された組織で、分野別トップレベルドメイン(.com、.net、.org、.info、.biz、.name など) のドメイン名登録者との間の連絡作業や、顧客に代わって管理用の TLD データベース・データの変更作業を担当している。180 以上の組織が gTLD レジストラとして認定され、約 100 の組織が現在業務を行っている。

　一般に、gTLD レジストラには、single point of failure (単一組織での障害がシステム全体の障害につながること) の組織は存在しないが、各組織は自社顧客に対しては、single point of failure となる潜在的な可能性を持っている。さらに、.com、.net、.org の TLD は、分散型 Whois アーキテクチャを使用している。このアーキテクチャでは、各レジストラが、自社担当となっているドメイン名登録情報に関する、公開でオンライン検索型のデータベースを提供している。レジストラに障害が発生した場合、(たとえドメイン 名自体はレジストリ・データベースによる解決が可能であり続けたとしても) 顧客用のオンライン Whois 情報は消失する。同様に、インターネット・コミュニティ全体は、各レジストラに依存しているのであり、各機関がレジストリ・データベースに存在する壊れたデータを垂れ流すパイプとなってしまうような状態に妥協するべきではない。

　従って、gTLD レジストラの関心は、脆弱性の評価、障害回復、レジストリ － レジストラ間のプロトコルの改善措置の必要要件、.com/.net/.org TLD 用の分散型 Whois システムに集まっている。

DNS セキュリティ・プロトコル

　2001 年 11 月の ICANN 総会で、パネルの一つがプロトコル・レベルでの DNS セキュリティについて報告を行った。

　パネリストたちは、DNS が高度に分散化されたシステムであるため、明確にハッキングに対し脆弱であることを認めている。ドメイン名に依存するすべての組織は、自らの DNS の信頼性にも依存している。悪意ある攻撃がローカル・ネットワーク上の DNS サーバーに対して行われた場合、トラフィックを別の場所に誘導し乗っ取る「偽の」DNS 応答が発生する可能性がある。結果として、攻撃者が被害者の Web サーバーに何ら手を加えなくても、誤った Web ページがユーザーに表示される可能性がある。より深刻なのは、破壊された DNS データは、電子メールを誤った場所に誘導し、誤配を起こす可能性があるということだ。世界中に無数の DNS サーバーが存在するという事実 (その数は数百万)、そしてその多くが更新版の DNS ソフトウェアを使用しておらず、さらに悪いことに、設定の誤ったソフトウェアを走らせているという事実により、それらのサーバーが悪意ある活動の標的となっている。ISP による DNS データ キャッシュが広く利用されており、下位レベルのネットワークでは、攻撃者によりキャッシュのデータを改ざんしたり、 改ざんと同様の結果を引き起こすキャッシュ・スプーフィングが行われている。 同様に、DNS は、レジストリ・データベースに含まれる情報の正確さに依存する。数は少なくとも、その重要性によりレジストリ・データベースも攻撃の潜在的な標的になっている。

　こうした状況と、DNS 仕様がもともと存在していない (その起源は 1980 年代初頭にまで遡る) ことにより、インターネット標準作成の主要機関である Internet Engineering Task Force (インターネット・エンジニアリング・タスクフォース) は、DNSSEC と総称されるセキュリティ面の機能拡張ツールのセットの開発に取り組んできた。DNSSEC は、公開鍵暗号化技術を使用して、DNS データの有効性を検証するものである。別の言い方をすれば、DNSSEC は DNS データの信頼性と統合性を確実化するメカニズムであると言える。DNSSEC は、ルートネームサーバーからスタートし、ドメイン名の階層的解決をすすめていく信頼チェーンの構築を容易にするものである。DNS の各レベルにおいて、関連する公開鍵を使用して、上位レベルゾーンの署名が検証される。

　作業は 1996 年から続けられてきたが、DNSSEC のプロトコル仕様はまだ完成していない。数件の試験的試みが研究機関や一部の TLD レジストリによって行われている。たとえば、現在 RIPE NCC の DISI プロジェクトは、DNSSEC プロトコルを使用して署名機能を利用した DNS と逆マッピングゾーンを提供している。インターネット全体が一度に DNSSEC に切り替わらなくとも、プロトコルの配備は、ルートネームサーバーや in-addr.arpa ゾーンなどの中核 DNS インフラストラクチャ要素から開始する必要が出てくるだろう。

　DNSSEC プロトコルは、設定ミス、対象外の旧版ソフトウェア、サービス攻撃の拒絶などの問題点の解決策とはならないが、キャッシュ改ざんやキャッシュ・スプーフィングなど、DNS データの改ざんに基づく攻撃は防止することができる。しかし DNSSEC の配備が可能になるまでは、DNS のすべてのレベルの組織が、DNS ソフトウェアを最新版に更新することの重要性と、設定ミスの危険性に注意を払う必要がある。(インターネット上の DNS サーバーの 12 ％が「危険なレベルで」誤設定された BIND、または古すぎる BIND を使用している)同様に、サービス攻撃の拒絶が広く増加していることは、DNS サーバーを持つ組織が、対攻撃用のソフトウェアを配備する必要があることを意味している。

　この趣旨に沿って、Martin Lindner (CERT Coordination Center) は、TLD レジストリ向けに、すべてを網羅した設定チェックリストを提供した。これは ICANN 総会のアーカイブから入手可能である。

ICANN の次なるステップ

　ICANN 理事会が重視しているのは、セキュリティの要件と優先順位の調整を行う継続的なメカニズムを ICANN 内に確立することが必要であるということだ。ICANN は、DNSおよびアドレス割り振りシステムのセキュリティの根底に存在する、さまざまな技術面、運用面、管理面の関心が交錯するミーティング・ポイントおよびフォーラムとして機能している。DNS のセキュリティの問題を監視・調整し、セキュリティ上の脅威とリスクを正確に特定・評価するため、また新しい必要要件と優先順位を決定し周知させていくためには、適切な人員が投入され、継続的に取り組みを行っていくことが必要となる。そのため理事会では、これらの役割を果たしていく使命を負った常設の諮問委員会を発足させた。

　理事会はまた、脅威やリスクの包括的分析を実行し、保護、検出、回復機能を評価するための継続的な監査機能を確立する必要性があるという認識で一致した。これらの取り組みには、特定のサービスが利用できない状態になりうる時間の長さの計測が含められるべきである。この計測結果をもとに、エスクロー・ポリシーおよびバックアップテスト処理の調整、リカバリおよび修復機能の起動などが通知される。Security Committee (セキュリティ委員会) は、コミュニティ全体でこれらの計測を行い、その結果を調整していく任務を負うことになろう。