メインコンテンツへスキップ

トップページ > JPNICライブラリ > ドキュメントライブラリ > 翻訳文書一覧


現在、マイクロソフト セキュリティ情報 MS10-090のパッチを適用したInternet Explorer 8をお使いの方は、 JPNIC Webサイトの内容が印刷できない状態になっています。 印刷をする場合には、 Internet Explorer 8以外のブラウザを利用してください。
この不具合の詳細と、その対処方法については、 マイクロソフトのWebサイトに掲載されている以下の技術情報をご覧いただくか、 マイクロソフトのサポートセンターにお問い合わせください。
 マイクロソフトの技術情報

Recommendations
翻訳文

社団法人日本ネットワークインフォメーションセンター
最終更新[2003年10月2日]

この文書は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レベルにおいて次善策がとられたが、 これらの次善策は潜在的な不安定性の元を追加する結果となっている。

<セキュリティと安定性の問題>

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

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

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

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

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

<見解>

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

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

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

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

<勧告>

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

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

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

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

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

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

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



このページを評価してください
このWebページは役に立ちましたか?
役に立った。
役に立たなかった。
どちらとも言えない。

ページの改良点等がございましたら自由にご記入ください。
  • このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、 お問い合わせ先 をご利用ください。
  • 文中でのHTMLタグ使用はご遠慮ください。
ページトップへ