2004年7月15日

ICANN「セキュリティと安定性に関する諮問委員会」が
COM/NETドメインにおけるリダイレクションに関する報告書を発表

　2004年7月9日、ICANNの「セキュリティと安定性に関する諮問委員会」(SSAC)は、 COM/NETドメインにおけるリダイレクションに関する報告書を発表しました。

　SSACでは、VeriSignのSite Finderサービス(注：ワイルドカードを使用して、存在しないCOM/NETドメイン名を同社が運営するサイトにリダイレクトするサービス。 VeriSignは2003年9月15日に同サービスを開始したが、 ICANNからの要請を受け、2003年10月4日以降一時停止中。) がインターネットのセキュリティと安定性に及ぼす影響について調査を行ってきましたが、今回、その調査結果およびICANNへの勧告を報告書にまとめ、発表しました。

■ICANN「セキュリティと安定性に関する諮問委員会」によるCOM/NETドメインにおけるリダイレクションに関する報告書(2004年7月9日)(PDF, 454KB)

<参照>
・ ICANNがVeriSignのワイルドカードサービスに関する注意勧告を発表(2003年9月22日)
・ ICANNの「セキュリティと安定性に関する諮問委員会」がVeriSignのワイルドカードサービスに関する勧告を発表(2003年9月25日)
・ VeriSignのワイルドカード実施に関するICANN「セキュリティと安定性に関する諮問委員会」特別会議について(2003年10月1日)
・ ICANN「セキュリティと安定性に関する諮問委員会」がVeriSignのワイルドカード実施に関する第二回会議を開催(2003年10月14日)

※以下は、SSACによる報告書の中から、「調査結果および勧告」についての記載を抜粋し、JPNICにて翻訳したものです。

調査結果

調査結果(1)：VeriSignは、NETおよびCOMレジストリに変更をもたらし、それにより、順調に機能していた一連の既存サービスに混乱を及ぼすことになった。ミスタイプされたドメイン名、失効したドメイン名、 DNSに登録はされているが委任されていないドメイン名、もしくは一度もDNSに登録されたことがないドメイン名などが、あたかも存在しているかのように名前解決されたのである。その結果、特定のEメールシステム、スパムフィルター、およびその他のサービスが機能しなくなり、第三者へ直接的および間接的に余計な費用負担を強いることになった。それらは、あるクラスのユーザーにとってはネットワーク使用料の増額という形で、あるいはパフォーマンスの低下という形で、あるいは結果として生じた障害を補償するために必要な作業の構築という形で発生したのである。

調査結果(2)：この変更は、各アーキテクチャ層の間の明瞭な境界を曖昧にすることにより、インターネットエンジニアリングの基本原則に違反した。 VeriSignは、 HTTPプロトコルを使用することでWebブラウザをSite Finderサービスの対象としたが、一方でDNSプロトコルは、実際のところ、その問い合わせの引き金となったプロトコルに関しては何の想定もしていない (そして、中立的である)。その結果、VeriSignは、多くのプロトコルのためのトラフィックを、さらなる仕掛けのためにSite Finderサービスへと導いた。それにより、より多くのコントロールが周辺部から一ヶ所に集中し、古くからのエンド・ツー・エンドのデザインの原則に背くことになった。

調査結果(3)：HTTP以外のプロトコルにおける変更の望ましくない影響を改善するためにVeriSignが提案したメカニズムは、 DNSを利用するすべての既存および将来のプロトコルの実装に VeriSignを関与させるものである。そのようなプロトコルのすべては、 "no such domain" に対するそれぞれのプロトコルの反応をシミュレートする方法を見出すために、 VeriSignに助言を求めなければならなくなる。これは、明確なレイヤー構造への受け入れがたい侵害である。

調査結果(4)：長期間にわたる内部調査および開発にもかかわらず、このシステムは唐突に登場した。この変更の唐突さは、一般による検討、コメント、および核となるシステムへの変更の試験を要請するという一般的な行動規範に違反するものであった。こうしたプロセスは、既存のサービスへ及ぼす混乱を最小限に抑えた形で、そしてそれゆえに、インターネットのセキュリティおよび安定性へ及ぼす混乱を最小限に抑えた形で、各種変更が導入されることを確実にするために存在しているのである。またこの唐突さは、管理者、IT部門、ISP、およびエンドユーザーが利用するその他の仲介者が、その結果に対処するために適切な準備を行う可能性を排除した。

調査結果(5)：これに応じて、回避策やパッチが迅速に導入され、システムの全体的な一貫性を累積的に低減させることになり、そしてまた、核となるサービスが実装・展開される前に行う一般による評価、試験、議論、および検討という慣習が破られることになったのである。これらの回避策は、インターネットの強固なアーキテクチャに固有の機能上のレイヤーをさらに不明瞭にし、また場合によっては、さらなる、かつ予期せぬ悪影響を生み出した。

調査結果(6)：対象とするEメール送信者および受信者に関する情報は、送信者もしくは受信者の認識あるいは同意がないのにもかかわらず、 VeriSignのサーバーが必然的に受け取っていた。 VeriSignは、この情報の保持について強く否定した。

調査結果(7)：Webサイトへとリダイレクトされたエンドユーザーの行動は、 Site Finderサービスに組み込まれたプログラムによって監視された。そしてユーザーは、このサービスを受け入れることも、拒否することも、別の類似のサービスに置き換えることもできなかったのである。

調査結果(8)：繰り返される変更および対応は、全体として、信頼できるふるまいについての期待を損なわせ、その際、システムのセキュリティおよび安定性に対する信頼を低減させた。

勧告

勧告(1)：合成された応答をトップレベルドメイン(TLD) もしくは公共的な役割を果たすゾーンに導入すべきではない。そのゾーンに含まれる内容は主として委任とグルーレコードである。また、そこにおける委任は組織間の境界を越えるものであり、そのような境界においてゾーン管理者がコントロールや影響を持つことは許されないのである。存在しない名前に関するDNSの問い合わせに応えてデフォルトの回答 (明示的な設定がされていない場合に返す回答) を提供するというワイルドカード機能については、 RFC(Requests for Comment)規定に文書化されているが、それは一般的に狭義のコンテクスト (例えば、EメールアプリケーションのMXレコードなど) においてのみ使用されることを意図しており、またそれは一般的に単一の企業内で使用されていた。そして現在では、一般的に小規模で整然と管理されたトップレベルドメインにおいて使用されている。

勧告(2)：現在使用している合成された応答については、 TLDもしくは公共的な役割を果たすゾーンにおいて徐々に廃止すべきである。そのゾーンに含まれる内容は主として委任とグルーレコードである。また、そこにおける委任は組織間の境界を越えるものである。

勧告(3)：DNSワイルドカードの仕様およびその利用には欠陥が存在する。 RFC規定を、以下の二つの成果を生み出すことに焦点を合わせて検討し、必要に応じて修正すべきである。一つ目は、 DNSプロトコルにおける合成された応答の使用とは何かを明確化することであり、二つ目は、DNSの階層化構造における合成された応答の使用に関して、補足の指針を提供することである。

勧告(4)：レジストリサービスにおける変更は、技術コミュニティとさらに大きなユーザーコミュニティ双方が関与した上で、通知、コメント、そしてコンセンサス形成のための十分な期間を経た後でのみ行うべきである。このプロセスは、 (i)セキュリティおよび安定性の問題を考慮し、 (ii)試験および改良のための十分な時間的余裕があり、 (iii)影響を受ける、もしくは影響を受ける可能性のあるシステム管理者とエンドユーザーへの適切な通知、およびそうした人々との連携を可能にするものでなければならない。 (インターネットの発展における)30年間の経験が、この戦略が強固なエンジニアリングを保証し、システムおよびその維持・発展を取り巻くプロセスへの信頼を生むということを証明している。

以上