2003年9月25日

ICANNの「セキュリティと安定性に関する諮問委員会」が
VeriSignのワイルドカードサービスに関する勧告を発表

　ICANNの「セキュリティと安定性に関する諮問委員会」は、 ICANNからの要請を受け、 VeriSignのワイルドカードサービスに関する見解および勧告を発表しました。

　同委員会では、ワイルドカードサービスがインターネットのセキュリティおよび安定性に対して及ぼす影響について、継続して調査を行っており、すべての利害関係者からの意見・情報を求めています。

　また委員会は、 2003年10月7日にワシントンD.C.において公開会合の開催を予定しており、同会合では、インターネットのセキュリティおよび安定性に関する事実情報について、関係者による発表が行われる予定です (会合の詳細については近日中に発表予定)。

「VeriSignによる、COM/NETにおける実在しないドメインに対するワイルドカード応答の導入に関する勧告」(2003年9月22日)

http://www.icann.org/correspondence/secsac-to-board-22sep03.htm

※以下は、上記文書をJPNICにて翻訳したものです。

セキュリティと安定性に関する諮問委員会からICANN理事会へのメッセージ

2003年9月22日

VeriSignによる、 COM/NETにおける実在しないドメインに対するワイルドカード応答の導入に関する勧告

ICANN セキュリティと安定性に関する諮問委員会

＜背景＞

　2003年9月15日、 VeriSignは、問い合わせを受けたCOMまたはNETドメイン名のネームサーバー・レコードが存在しない場合のCOMおよびNETのネームサーバーの応答方法を変更した[1]。この変更については、 2003年9月5日[2]および9月9日[3]にレポートされているが、その変更の意味についてはそれが展開されるまで広く認識されるものではなかった。

　これまでは、上記のようなクエリ(問い合わせ)にはRCODE 3("name error") が返されるようになっていた。これは、 DNSプロトコルの正式な仕様であるRFC1035 [4]で定義されているネガティブ応答である。 VeriSignは現在、特別なサーバーのIPアドレスを返すようにしており、それによりリクエストされたドメイン名が存在しているかのような見え方となっている。この特別なサーバーは、アプリケーションレベルのサービス(例えば、WebやEメールなど) に対する引き続きのリクエストを処理するようになっている。

　この特別なサーバーは現在、 HTTP(Web)のための80番ポートおよびSMTP(Eメール) のための25番ポートをリッスンするようになっている。 Webサーバーは、当該ドメイン名が登録されていないということを示すページを返すとともに、検索サービスおよび/またはドメイン名登録サービスを提供するようになっている。 Eメールサーバーは、当初よりすべてのEメールを550番エラーコードとともにバウンスするようになっている。これは、永続的な失敗を示すものであり、結果的にメッセージは送信元にバウンスされることになる。その細かなふるまいは、コミュニティからのフィードバックにより今後変更する可能性があり、 COMおよびNETドメインにおいては、Eメールが待ち行列に入り、配送され、応答される方法が実質的に変わっていくことになる。

　存在しないドメインのためのRCODE 3応答にこれまで依拠していたアプリケーションやプロトコルは、 COMおよびNETに関するふるまいについての今回の変更により被害を被っている。今回のワイルドカードの影響をくい止めるために、ルーティングおよびDNSレベルにおいて次善策がとられたが、これらの次善策は潜在的な不安定性の元を追加する結果となっている。

＜セキュリティと安定性の問題＞

　セキュリティと安定性に関する諮問委員会は、現在の状況をいくつかの観点から精査している。

エンジニアリング・コミュニティによって定義されているプロトコル仕様に合致しているかどうか。
エンジニアリング・コミュニティおよびオペレーション・コミュニティによって定義されているベストプラクティスおよび運用手続きに合致しているかどうか。
VeriSignによる変更およびそれに対応して行われた他の人々による変更の両方を考慮に入れた上での、ドメインネームシステムおよびインターネット全般について、その技術的安定性とセキュリティについての検討。
インターネットの非常に重要な部分に対する変更についての再検討と分析を確実に行うために用意されている現在の手続きとガバナンス管理。
インターネットの安定性と信頼性の高い運用についての社会全体からの信頼。セキュリティと安定性は、プロトコル文書に書かれている技術仕様という狭い解釈に限定されるものではなく、それはまた、エンジニアリング上の問題、オペレーション上の問題、ビジネス上の問題、ポリシー上の問題を含むものである。

　セキュリティおよび安定性が意味するところに関する情報を収集するため、当委員会はすべての利害関係者からの意見・情報を求める。

意見・情報の送付先：<secsac-comment@icann.org>

　また当委員会は、 2003年10月7日にワシントンD.C.において公開会合を開催し、インターネットのセキュリティおよび安定性に関する事実情報について、関係者による発表が行われる予定である。会合の詳細については近日中に発表の予定。

　当委員会では今後も意見・情報を集め続けるものの、すでに以下に示す見解および勧告を裏付けるための十分な情報を持ち合わせている。

＜見解＞

　VeriSignによる変更は、曖昧かつ不正確なDNSの応答を引き起こすところとなり、インターネットの安定性を著しく弱体化させたと思われる。また、今回の件に対する対策、さらにその対策に対する対策を講じるなど、連鎖反応を拡大させ、不安定性をさらに助長することとなった。

　VeriSignによる変更は、ドメインネームシステムの正確で安定的かつ信頼性のある運用に依存している既存のサービスの一部を実質的に妨害している。

メールに見られる多くのコンフィギュレーションエラーや一時的な停止は良性の病気と呼べるものであったが、ワイルドカードの存在という致命的な状態となった。
アンチスパムサービスは、メール送信元のねつ造を識別するためにRCODE 3応答に依拠していた。
ある環境においては、DNSは一連の問い合わせサービスの一部となっている。この場合、一つのサービスが問い合わせに失敗すると、その問い合わせアプリケーションは希望する情報を求めて次のサービスへと移行していく。今回のVeriSignによる変更により、DNS問い合わせが失敗するという状況はなくなり、これにより希望する情報を見つけることもできなくなってしまった。

　VeriSignの今回の行動は、ISP、ソフトウェアベンダー、その他利害関係者がさまざまな対応をする結果となったが、これらすべては今回の変更による影響を少なくしようとするものであった。こうした一連の変更およびその変更のための変更の結果、ドメインネームシステム全体およびそれを使用するアプリケーションにおいて、複雑性が増し、安定性が減少してしまうことになる。この流れは、まさに誤った方向へ導くものである。システムというものは、可能な限り、アーキテクチャ上のレイヤーを明確に分離し、シンプルかつ理解しやすい状態に維持されるべきである。

　当委員会は、いくつかのネットワークやアプリケーションが、 VeriSignによる変更以前に同様のサービスを行っていたことを言及しておく。実際、あるユーザー・アプリケーションやサービスは、ユーザーが使用するネットワークによって、異なる動きをしていた。しかし、VeriSignによる変更は、こうしたサービスをプロトコル・スタックにおけるより低いレイヤーへ、また、インターネットのグローバルなインフラストラクチャにおけるより深い場所へと押しやるものである。これにより、存在しないドメインへの問い合わせが行われた際に、使用するサービスや手順をユーザーが選択することができなくなってしまう。

＜勧告＞

　ワイルドカードサービスについてのコミュニティにおける懸念を認識し、当委員会はVeriSignに対し同サービスを自発的に一時停止すること、さらに現在進行中のさまざまな検討プロセスに参加することを要請する。

　当委員会はICANNに対し、ユーザーを突然のサービス変更から保護するための規定を含め、サービス変更のための手続きを検討するよう要請する。

　当委員会はIAB、IETF、およびオペレーション・コミュニティに対し、ドメインネームシステムの仕様を精査し、追加的仕様によってシステム全体の安定性を向上させることが可能かどうかを検討するよう要請する。最も緊急の措置として、 TLDおよびルートドメインにおけるワイルドカードDNSドメイン名の使用および運用に関し、明確な勧告を行うことを要請する。これにより、方策と将来の見込みを世界で共有することができる。より広範なアーキテクチャ上の問題に関しては、当委員会は技術コミュニティに対し、エラー応答の役割、特にアーキテクチャ上のレイヤーの分離における役割を明確にし、さらに、セキュリティおよび安定性との相互関係について明確にするよう要請する。

[1] VeriSignの変更についてのニューヨークタイムズによるアナウンス

[2] VeriSignの変更についてのウォールストリートジャーナルによるレポート

[3] VeriSignの変更についてのコンピュータ・ビジネスレビューによるレポート

[4] RFC1035：ドメイン名 - 実装と仕様