IAB Commentary
翻訳文

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

この文書は2003年9月20日に公開された
http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html
を翻訳したものです。
JPNICはこの翻訳を参考のために提供しますが、その品質に責任を負いません。

2003年9月19日

IABによる論評:
DNSワイルドカードの使用に関するアーキテクチャ上の懸念について

　DNSの動作に関するアーキテクチャ上の前提条件は、 DNSについて規定するIETF標準文書には明示されておらず、しかしながら、インターネットプロトコルやアプリケーションの動作に深く組み込まれているものが多数あります。これらの前提条件は、 DNSを1つの構成要素とするネットワークアーキテクチャの本質的な部分なのです。

　DNSワイルドカードはこれらの前提条件に違反する方法で使用することができるということが以前から知られています。

　最近設定されたDNSツリー構造内の上位レベルでのAレコードを使用した DNSワイルドカードは、このような前提条件に違反するとコストが高く付くことを経験的に明らかに示しています。本文書では、DNSワイルドカードがどのように機能するのかについて説明し、その無分別な使用が、一つ一つのインターネットアプリケーション、そして、インターネットアーキテクチャそのものに悪影響を与えることを示す多くの例を提示します。

　特に、ゾーン管理者がリスクを熟知していない限り、 DNSワイルドカードをそのゾーン内で使用しないこと、そのゾーンの下で委任を受けている人々の同意なしに使用しないことを推奨します。

DNSワイルドカードの概要

　DNS「ワイルドカード」の仕組みは、 DNSの最初の仕様が20年前に作成されて以来、 DNSプロトコルの一部となっていますが、ワイルドカードの機能と制限事項には注意が必要であるため、ワイルドカードをどのように実装するかについてのプロトコルの詳細およびワイルドカードをどのように使用すべきか、または使用すべきでないかに関する運用上の詳細については検討が現在も続けられています。このセクションではワイルドカードがどのように機能するかについての基本的な事項について説明しますが、詳細については、DNS仕様([RFC 1034]およびそれに続くもの)を参照してください。

　基本的に、DNSワイルドカードは、権威あるネームサーバがDNSリソースレコードをその場で合成することを可能にするルールです。基本的なメカニズムは非常に単純ですが、複雑なのは、その詳細とそれが意味するところです。

　DNSプロトコルにおいて最も基本的で、最も一般的な操作は、入力した問い合わせドメイン名(query name)、問い合わせクラス(query class)、問い合わせタイプ(query type) と一致するすべてのリソースレコードを検索する単純な問い合わせです。 (単純化のため) すべての関連するソフトウェアとネットワークが正常に動作していると仮定すると、上記のような問い合わせを行った場合、次の3つの内いずれか1つの結果が得られます。

success: システムが3つのパラメータすべてと一致するものを見つけた場合、一致するリソースレコードの集合を返します。
no data: システムが問い合わせドメイン名と問い合わせクラスが一致するものを見つけたものの、問い合わせタイプとの一致が見つからない場合、名前は存在するが、指定された問い合わせタイプと一致するデータが存在しない旨を返します。
no such name: システムが指定された問い合わせドメイン名と問い合わせクラスが一致するものを見つけることができない場合、名前が存在しない旨を返します。

　通常、3つのパラメータはすべて完全一致する必要があります。ここで、ワイルドカードが重要な役割を持つようになります。

　ワイルドカードレコードは、通常のDNSリソースレコードと同じですが、左端(重要度では一番下)のラベルが、 *.bar.exampleのようにアスタリスク文字(「*」)1個から構成されます。概念的には、アスタリスクはドメイン名の左端(重要度では一番下) の1つまたは複数のラベルと一致するということになります。

　ワイルドカードレコードが存在する場合、ルールはさらに複雑になります。具体的には、問い合わせクラスが一致し、問い合わせドメイン名との完全一致がなく、問い合わせドメイン名と最も近い一致がワイルドカードである場合、システムは、ワイルドカードにあるリソースレコードが問い合わせドメイン名であるとみなして、問い合わせドメイン名と一致するリソースレコードのセットをその場で合成します。このため、そのワイルドカードが希望する問い合わせタイプと一致するレコードを持つ場合、システムは上記の「success」の場合と同様にそのレコードを返します。そうでない場合は、「no data」の場合と同様に、ドメイン名は存在するが、指定された問い合わせタイプと一致するデータは存在しない旨を返します。この応答は、問い合わせドメイン名に対する通常の「success」応答と同じなので、問い合わせを発行したリゾルバは、受け取った結果がワイルドカード拡張の結果であるかどうかは判別がつきません。

　ワイルドカード一致の場合、「no such name」は発生しないことに注意してください。ワイルドカード一致ではこうなる可能性はありません。また、ワイルドカードが一致するかどうかを決定するためには、問い合わせドメイン名と問い合わせクラスのみが重要であることにも注意してください。レコードタイプが問い合わせタイプと偶然一致するかどうかにかかわらず、どのようなレコードタイプでもワイルドカード一致が生じることになります。

ワイルドカードレコードに関する問題

　ワイルドカードの主な既知の弱点と危険性の1つは、「no such name」応答があるということを前提にDNSを使用している場合、正しく動作しないことです。そのような使い方をしている事例がたくさんあることがわかっていますが、これについては、後のセクションで詳細に説明します。

　ワイルドカードレコードの別の既知の弱点と危険性は、ゾーン内にあるワイルドカードではない名前が、ワイルドカードよりも問い合わせドメイン名と一致しない限り、ワイルドカードラベルはすべてと一致するという事実に起因します。これは、異なるレコードタイプを使用するよりもむしろ、ドメイン名の左端(重要度では一番下)にあるラベルを、様々なサービスに関連するリソースレコードを識別するために利用している規則の数、およびいくつかの場合においてはプロトコルの数を考慮に入れるまでは大きな問題のようには見えませんでした。つまり、これらの場合、関連しない複数のサービスが同じレコードタイプを使用しており、クライアント(すなわちユーザ)は利用したいと思う特定のサービスに特定の名前を対応させて使用することが期待されています。これは、www.foo.exampleなど[RFC 2219]に記載されているアドホック命名規則と、命名機構が正式なプロトコルの一部であるSRVレコードタイプ[RFC 2782]などの仕組みに適用されます。この種の名前が、 *.bar.exampleという名前のアドレスレコードのワイルドカードに該当する場合、そのワイルドカードは、問い合わせドメイン名に埋め込まれているサービス名にかかわらず、同じアドレスレコードを返します。このため、ftp.foo.bar.example、mail.foo.bar.example、 ntp.foo.bar.exampleなどはすべて同じ合成されたアドレスレコードになります。この問題は、SRVの場合はさらに深刻です。なぜなら、_finger._tcp.foo.bar.exampleなどの名前はプロトコルの一部であり、 SRVレコードは TCPおよびUDPポート番号を含むため、クライアントは、どのホストにアクセスするかだけではなく、そのホストにアクセスするポートに関しても混乱してしまいます。この種の名前に関するこれらの問題を回避する唯一の方法は、そのような名前についての明示的なレコードをDNSに追加することです。

　最後に、上記の2つの要素 (「すべてと一致する」動作および「no such name」応答に依存するものとうまく対話できないこと)は、一般的なおよび予測可能なヒューマンエラーとの相互作用により、ワイルドカードはその意図した適用範囲を超えて影響を及ぼすことがあります。正確に言えば、定義により、ワイルドカードレコードはゾーンに実際に存在する名前とは決して一致せず、したがって、親ゾーンから子供ゾーンへの名前空間の(非ワイルドカード)委任部分と一致しないため、ワイルドカードレコードの適用範囲は、1つのゾーンに限定されます。 (ワイルドカードNSレコードは、理論的には可能ですが、意味的にかなりおかしいので、 DNSソフトウェアの耐久テストに使用を限定するのがおそらく最も良いでしょう。) このため、一見したところ、ゾーンの管理者は、そのゾーンにおいて委任された子供に対する影響を気にすることなくワイルドカードを自由に使用できるように思われます。残念ながら、これは正しくないということがわかります。なぜなら、ドメイン名はユーザインターフェイスで頻繁に使用され、ユーザは人間でありミスをすることがあるためです。 bar.exampleゾーンを委任している場合、ワイルドカードレコード *.exampleは、 foo.bar.exampleと入力するところを誤ってfoi.bar.exampleと入力したユーザに影響を与えることはありませんが、そのエラーがfoo.bat.exampleである場合は、そのユーザに影響を与えることになります。このため、ユーザの立場からみると、ワイルドカードの影響の一部は親ゾーンから子供ゾーンに及びます。親ゾーンと子供ゾーンが1つの同一組織に関係付けられる場合は大きな問題ではありませんが、親ゾーンと子供ゾーンが、利害が完全に一致しない異なる組織と関係付けられる場合は、実際に問題となることがあります。

　上記は、おそらく、網羅的な一覧ではありません。 DNSに関して20年間の経験があるにもかかわらず、予期していなかったワイルドカードの使用の影響は、非常に驚くところがあります。なぜなら、リソースレコードの検索ルールを変更するという簡単でしかしながら根本的な方法は、すでに展開されているDNS利用ソフトウェアにとっての暗黙的な (またはしばしば明示的な)前提条件を妨害する厄介なものだったからです。

　このような理由から、DNSワイルドカードのほとんどすべての使用は、比較的少数のよく理解されている役割に限定されてきており、そして、多くのワイルドカード使用は1つの役割、つまりメール配信に使用されるMXレコードに制限されてきました。

　MXレコードは電子メール配信にのみ使用されるものであるため、ワイルドカードMXレコードは比較的安全であり、また、いかなるドメイン名の電子メールも、通常、 DNS委任ツリーの最下位に位置する組織において配送されるので、ワイルドカードMXレコードはその影響が組織の境界を超えないゾーン内で使用される傾向にあります。後者は普遍的な真実というわけではありませんが、ワイルドカードレコードの主な使用は、これまでも、また今も、一つの組織内のメールを処理するためのワイルドカードMXレコードとなっています。

　このような問題を考慮すると、複数のプロトコルに影響を与えるレコードタイプにおいてワイルドカードを使用する場合は注意が必要です。また、組織の境界を超えて影響が及ぶような状況でワイルドカードを使用する場合にも注意が必要です。さらに、組織の境界を超えて影響が及ぶような状況で複数のプロトコルに影響を与えるレコードタイプにおいてワイルドカードを使用する場合は、非常に注意をする必要があります。

留意すべき原則

　本文書のこれ以降の項を読むにあたっては、インターネットで長年使われてきているアーキテクチャ設計における2つの基本原則を留意すると役に立つかもしれません。

強さ(Robustness)の原則:「自分が行うことは保守的であるように努め、他人の行いを受け入れるときは寛大であること」[Jon Postel, RFC 793]
驚きを最小限に(Least Astonishment)抑える原則:「プログラムというものは、ユーザを最も驚かせないような方法で常に応答する必要がある」[古くからの伝え。原作者不明]

　これらのポイントについては、次のセクションの後に説明します。

ワイルドカードに関する最近の実験で生じた問題

　最近、大規模なトップレベルドメインでワイルドカード使用に関する実験の結果を見る機会がありましたが、それはあまり望ましいものではなく、また予期しない結果でした。このセクションでは、今回の展開の結果として世界中のネットワークユーザとネットワーク運用者が遭遇した問題の幾つかについて詳しく説明します。

　今回の展開は、技術的には、ワイルドカードレコードの正当な使用であり、 DNS仕様そのものには全く違反していないことを強調しなければなりません。私達がここでとりあげる主なポイントの1つは、プロトコル仕様の文面に単純に適合しているだけでは、 DNSに依存するアプリケーションの運用上の安定性を確実なものとするのに十分ではないということです。ある特定の状況で使用すると安全でないプロトコル機能もあります。

　今回の展開で当該オペレータが行った変更は、影響を受ける各ゾーンの頭に1つのワイルドカードアドレスレコードを追加することでした。この変更の直接的な結果として、2つのことが発生しました。

これらの2つのゾーンの権威あるサーバは、それぞれのゾーンにおいて可能なすべての名前に対して「no such name」応答を出さなくなりました。
今回の変更まで全く存在していなかった、これらのゾーンのいずれかに属するであろうすべての可能な名前は、現在、このゾーンのオペレータによって運用される「リダイレクトサーバ」を指す合成されたアドレスレコードを持つようになっています。

　この単純な変更は、多くのさまざまな意味を持っています。以下のリストは、すべてを網羅するものではありません。

Webブラウジング

　世界中で使用されているWebブラウザで、当該TLDの下に属するURLを正しく指定しない場合、各ユーザのローカル言語および文字セットでの「page not found(ページが見つかりません)」という表示が出なくなりました。その代わりに、これらのブラウザには、当該ゾーンオペレータによって運用されているWebサーバから英語による検索ページが表示されるようになっています。

　HTTPプロトコルの言語タグはローカルブラウザで使用される言語と必ず一致するわけではないことに注意する必要があります。したがって、たとえそのグローバル検索ページが動的なものであり、ユーザがどの言語とスクリプトを使用しているかを推定するために、 HTTPリクエストの情報を活用したとしても、ユーザが期待することを実現することは決してできないでしょう。簡単に言えば、HTTPプロトコルには、そのような検索ページを生成するエンジンのために十分な情報がないのです。

　多くの状況において、Webブラウザは、DNS検索に失敗した場合、そのWebブラウザのローカルな規則、ディレクトリ、言語に基づいてユーザに対して一定の支援を提供するように作成されています。これらすべてのシステムは、当該TLDの下にあるURLに対しては現在無効なものとなっています。なぜなら、指定された宛先が存在しない場合でも、 DNS検索が失敗するということがないからです。

　これらの変更がたとえ受入可能なものであったとしても、この新しい仕組みはスケーラビリティに乏しい特質をもっており、当該オペレータが大規模で頑強なWebサーバ体制を維持するために多大な資金を投資しない限り、ユーザの経験はさらに悪化することになります。すなわち、ローカル言語でエラーメッセージが出ることもなく、英語の検索ページが出ることもなく、ユーザは「attempting to connect...(ただ今接続中...)」というメッセージの表示の後、長く待たされることになります。

電子メール

　当該TLD下の存在しないホスト名への全メールは、現在、当該レジストリオペレータのサーバに送られ、そこでバウンスするようになっています。一部のネットワーク運用者はこれを耐え難いものと考え、この「バウンスサービス」をバイパスするようにメールシステムの設定を変更しましたが、大多数のメールサーバは、当該TLDの存在しない名前に対するメールについて直接バウンスするのではなく、おそらくバウンスサーバに配送しています。これによっていくつかの結果がもたらされます。

ネットワーク運用者達がバウンスサーバにメールが行くことを許容した場合、彼らはバウンスサーバへ向かうメッセージの追加的な経路の処理をするためメール負荷の増加をみることになります。ネットワーク運用者達がバウンスサーバにメールが行くことを許容しない場合は、それを防止するサーバ設定のためにさらに開発と維持の手間が必要となります。
バウンスサーバにメールが行くことを許容するネットワーク運用者は、バウンスサーバのパフォーマンスに依存することになります。バウンスサーバが遅くなるか、または障害が発生した場合、以前ならバウンスされていたメールは、SMTPリレーのキューに、そのリレーに設定されている時間だけとどめられた後、ユーザにバウンスされるという形になります。このため、以前には直ちにバウンスされた入力エラーのメールが数日間も通知されない形になるため、ユーザにとって非常に悪い経験を生み出すことになります。
バウンスサーバにメールが行くことを許容するネットワーク運用者はまた、バウンスサーバの正常な運用に依存することになります。バウンスサーバにバグがある場合(今回の初公開で、たまたまそのような事実がありましたが)、メールがまったくバウンスされないという可能性もあります。実際には跡形もなく消滅したにもかかわらず、正しく配送されたとユーザに通知されることもあるかもしれません。これはまた、ユーザにとって非常に悪い経験を生み出すことになります。
あるドメイン名に関連するMXレコード一式に、存在しないホスト名を指す誤った設定のレコードが含まれていたケースでは、今回のワイルドカードレコードの設定が、「誤った設定だが機能している」メール設定を壊す最後の一手となりました。以前は、存在しないホスト名は名前解決されず、無視されましたが、今はバウンスされるようになってしまいました。
アドレスにタイプミスがある場合、SMTPのクライアントからのデータの通常のフローは次のとおりです。
1. クライアントは、DNSで送信用SMTPプロキシのIPアドレスを検索します。
2. クライアントは、送信用SMTPプロキシへのTCP接続を開きます。
3. クライアントは、自分自身に関する情報をSMTPプロキシに送信します。
4. プロキシは、クライアントを受け付けるかまたは拒否します。
5. クライアントは、受信者に関する情報をSMTPプロキシに送信します。
6. プロキシは、DNSで宛先を検索し、「no such name」を受け取ります。
7. プロキシは、アドレスが間違っているという情報をクライアントに送信します。
ミスタイプされたドメインのためにワイルドカードが存在している場合、次のようになります。
1. クライアントは、DNSで送信用SMTPプロキシのIPアドレスを検索します。
2. クライアントは、送信用SMTPプロキシへのTCP接続を開きます。
3. クライアントは、自分自身に関する情報をSMTPプロキシに送信します。
4. プロキシは、クライアントを受け付けるかまたは拒否します。
5. クライアントは、受信者に関する情報をSMTPプロキシに送信します。
6. プロキシは、DNSで宛先を検索し、「success」を受け取ります。
7. プロキシは、メッセージを受け付け、クライアントとの接続を閉じます。
8. プロキシは、バウンスサーバへのTCP接続を開きます。
9. プロキシは、自分が持っている情報をバウンスサーバに送信します。
10. バウンスサーバは、受信者アドレスが受け入れられないことを示します。
11. プロキシは、エラーメッセージを生成し、送信者のメールアドレスに返送します。
送信用SMTPプロキシの名前が誤った形でSMTPクライアントが正しく設定されていない場合は、別の流れが発生します。そのドメイン名がワイルドカードを使って名前解決されるため、クライアントはバウンスサーバに接続し、それに対してメール送信を開始します。その結果、バウンスサーバ(ワイルドカードのIPアドレスとなっている)は、受信者アドレスが実際には正しい場合でも、それが間違っていると通知します。ユーザに通知されるこのエラーは正しくありません。なぜなら、間違っているのは受信者の名前ではなく、送信用プロキシの名前であるからです。

ユーザへのエラーの通知

　多くのアプリケーションのGUIは、ユーザが次のステップに進む前にドメイン名の有効性をチェックします。たとえば、送信前に電子メールアドレスのドメイン名が名前解決されることを直接チェックする電子メールクライアントや、設定を受け入れる前にプリントスプーラ名が有効であることを確認するネットワークプリンタ設定ツールなどがあります。以前は、ドメイン名にエラーがあることが早期にユーザに通知さたものでした。電子メールの場合、現在は、エラーが送信時には通知されず、電子メールが後でバウンスされる際に通知される形になっています。また、プリンタの設定の場合は、設定中にエラーが通知されるのではなく、後で印刷が失敗したときに通知される形になっています。このため、問題の分析がさらに難しくなります。

スパムフィルタ

　今回のワイルドカードレコードの設定は、フロントエンド受信メールサーバで通常使われている幾つかの単純なスパムフィルタを壊し、また、明らかに偽の送信者を排除するために送信ドメインの存在をチェックするさらに複雑なフィルタをも壊しました。このフィルタリングの仕組みが増加するにつれて、このスパム・テクニックは少なくなってきましたが、あるネットワーク運用者は、この種のものが、大規模な共用MXクラスタでの受信メールの約10%に相当すると報告しています。今回の問題を知っているISPは、これらのワイルドカードレコードによって返されるアドレスについての特別な知識を持つようにフィルタルールを拡張すると考えられますが、それを行うためにはプログラムのメンテナンスとフィルタによる実行時間の増加という点でコストを負担する必要があります。

その他のプロトコルとの相互作用

　ワイルドカードアドレスレコードは、いかなるネットワークサービスのDNS検索も捉えてしまいますが、インターネットで使用されているプロトコルの数は非常に多いので (IANAに登録されているポート番号あるいは登録されていないポート番号を使って、複数の当事者間で使用されているプライベートプロトコルを含む)、ゾーン管理者(またはその他の誰でも) がそのすべてのプロトコルにリダイレクトサービスを提供することは不可能です。今回の例では、当該ゾーンオペレータは、 HTTPの処理(検索ページにリダイレクト)およびSMTPの処理(バウンスさせる) のみを提供しています。その他のプロトコルはすべて、せいぜいTCPリセットを受けるか、または幾つかのケースでは、単純にパケットが廃棄されることになります。 DNSを使用するアプリケーションは、「no such name」エラーを処理する方法を持っています(持つ必要があります)。ほとんどの場合、エラーメッセージは経験豊かなユーザには明らかなので、誤ったドメイン名を指定したためにアプリケーションが失敗した場合はすぐ分かります。しかしながら、これらのワイルドカードレコードが設定されている場合、ワイルドカードレコードによって一致した誤ったドメイン名はDNSエラーとして表示されず、代わりに不可解な接続の失敗が生じたり、当該ゾーンオペレータがリダイレクトしないすべてのサービスのためにアクセスできない宛先などが発生します。アプリケーションプロトコルとその実装の詳細によりますが、今回の変更により、明らかに「重大な障害」(間違った名前)が軽微な障害へと変更され、上記の電子メールの場合と同様に、そのアプリケーションは再試行すべきと考えるようになります。その結果、些細なエラーでもユーザが気がつくまでに非常に長い遅延、おそらく数日または数週間の遅延が生じることがあります。 UDPを使用しているトランスポートプロトコルも、トランスポートプロトコルの再試行の上限数に達するまで再試行を行うことになります (特にICMPメッセージがファイアウォールでフィルタされる場合)。この場合、宛先のタイプミスがあることを示すエラーをユーザに返すのに、以前かかっていたよりも非常に長い時間かかる可能性があります。

自動化ツール

　HTTPを使用するが、ユーザインターフェイスを備えていない自動化されたツールまたは組み込まれたツールも、今回の変更によって混乱する可能性があります。というのは、このようなツールは設定の失敗がDNSエラーとして表示されるものと予想し、当該ゾーンオペレータの検索ページから受け取ったHTTP応答が、アクセスしようとしたページではないと認識しないからです。このようなツールは予期しない仕方で失敗し、アップグレードが容易でない場合があります。

課金

　問題となっているサービスから現在受け取る応答は 17KBを越えるデータとなっています。これは、クライアントがTCP接続を開き、かなりの量のデータを受け取る必要があるからです。「no such data」応答であれば、1つのパケットに収まります。インターネットアクセスに対して従量課金となっている場合 (多くの移動体データサービスなどのように)、受信者はさらに料金を支払う必要があるでしょう。

障害となる単一箇所

　たとえリダイレクトサービスが意図した通りに動作した場合であっても、そのようなサービスは非常に大規模な「障害となる単一箇所(Single Point of Failure)」を生み出します。「障害となる単一箇所」は、用意周到な攻撃とルートゾーンの DNSネームサーバにおけるトラフィックの多くを生じさせるバグや設定エラーが原因で生じる偶然の「攻撃」の明らかなターゲットとなります。さらに、この「障害となる単一箇所」に付けられているIPアドレスは、そのIPアドレスを他のサーバにリダイレクトすることを意図したルーティング攻撃のターゲットとなり得ます。

プライバシー

　この種の範囲のインターセプション(トラフィックの横取り)サービスは、プライバシーに関して重大な懸念を生じさせます。なぜなら、このインターセプションサービスによって受け取られるトラフィックは、定義によるならば、送信者が当初意図した場所に送られなかったものだからです。この状況において悪用の可能性は非常に高く、また、このインターセプションサービスは、そのような悪用をするために管理権限を得ようとする攻撃者の格好のターゲットとなります。

予約ドメイン名

　このようなワイルドカードの使用は、 DNSゾーン自体に追加しないという明確な意図のもと、レジストリにおいてドメイン名を予約するということに依拠するDNSの使い方とは相容れません。このような使用の一例としては、 JET(Joint Engineering Team)によって進められているIDN(国際化ドメイン名) アプローチにおける「レジストリ制限」と「予約ドメイン名」があります。これは予約されているドメイン名が存在し、それに関係づけられているドメイン名の保有者のみそれを登録することが可能であるという状況に依拠し、しかしそれはDNSには現れないというものです。現在のICANN IDNポリシーに関する幾つかの文書によると、この「予約ドメイン名」アプローチを支持することが求められています。利用者の混乱を軽減するためには、予約ドメイン名は名前解決できないようにする必要があります。この予約ドメイン名のアプローチは、このようなワイルドカード使用とまったく相容れないように見えます。ワイルドカードは常に返すべき結果を生み出し、それはゾーンに現れない予約ドメイン名についてもそのようになるため、この件については両方を支持することはできず、いずれか1つを支持することになります。

望ましくない次善策

　ISPは、今回のワイルドカードの展開に対していくつかの方法で対応していますが、そのすべては理解できるものではありますが、懸念もあります。一部のISPは、当該ゾーン管理者のリダイレクトサーバ宛のすべてのパケットをブラックホールに廃棄するようにルーティングシステムを変更することを考えました。その他のISPは、これらのワイルドカードレコードの影響を抑えるDNSリゾルバ向けのパッチを配布しました。さらに別のISPは、自分自身の利益のために、当該ゾーンオペレータと同じことを行う良い機会であると考えています。これらの対応はすべて理解できるものであり、また予想できていたものですが、いずれも適切ではありません。さらに厄介なのは、この問題に対するアプローチがISPごとに異なっていることで、これによって分断化の問題が生じる恐れがあり、複数のネットワークをまたいだDNS またはアプリケーションのデバッグを行う必要がある人にとって頭痛の種になる可能性があります。

原則、結論、および推奨事項

　強さの原則によれば、上記の問題のいくつか(すべてではなく)においては、両方の当事者が誤っているとみなすことができます。幾つかのケースにおいては、これは驚くべきことでも何でもありません。特にスパムフィルタは、本質的に極めて場当たり的で、やや脆弱である傾向があります。明らかに、これは関係者全員にとって良い教訓となります。

　驚きを最小限に抑える原則によれば、ワイルドカードの展開はユーザにとっては悲惨なものであることを示唆しています。これは、当該ゾーンオペレータによって数え上げられる数をはるかに超えたインターネットのその他のユーザにも広範な影響を与え、幾つかの新しい問題を生み出し、その他のインターネットの構成団体が、今回の変更に対応するため、性急で、互いに互換性がなく、 (インターネット全体にとって) おそらく有害な変更をそれぞれの運用において行わせるという結果を引き起こしました。

　これらの検討事項はいかなるワイルドカードの展開にも適用されることに留意してください。今回のケースにおいて生じた問題の一覧は、ワイルドカードレコードは基本的なDNSプロトコルの一部ではあるものの、その使用が安全でない場合もあるということを明示的に示しています。先のセクションで書いたとおり、この種のワイルドカードの展開は危険であることを示唆する2つの警告フラグは次のとおりです。

複数のプロトコルに影響を及ぼしました。
DNS階層の十分に上位の場所で行われ、その影響はワイルドカードレコードを展開することを選択した組織に限定されませんでした。

　また、一覧に載った問題の一部の重要な部分は、正確にはワイルドカードが原因で生じた動作ではなく、長年使用されてきているインフラストラクチャの仕組みにおける動作を急に変更したために生じたものであるということに留意してください。

　結論としては、ワイルドカードレコードを展開するにはリスクがありすぎるという場合のガイドラインを提案し、また、今後の対策に関する推奨事項を示します。

提案するガイドライン:: ワイルドカードを自分のゾーンで使用することを望み、同時にそのリスクを理解している場合は使用してもかまいません。ただし、ゾーン内で委任を受けている人々の同意を得られた時のみ使用するようにしてください。

　通常、複数のアプリケーションプロトコルに影響を与えるレコードタイプにワイルドカードを使用することは推奨しません。現時点では、複数のアプリケーションプロトコルに影響を与えない唯一のレコードタイプは、 MXレコードです。

　委任を行うゾーンでは、ワイルドカードMXレコードも推奨しません。ワイルドカードMXレコードが使用される場合、そのゾーンから委任されたゾーンのオーナにそのポリシーを通知し、委任されたゾーン内でMX名が適切に動作するように支援を受ける必要があります。換言すれば、親ゾーン管理者は、子供ゾーンの許可なしに子供ゾーン宛のメールに関して経路変更しないようにする必要があります。

「レジストリ」クラスのゾーンでワイルドカードを使用することを一律に禁止することには躊躇しますが、ワイルドカードの意図した使用がDNS の安定した運用またはアプリケーションとユーザの予想可能な動作に対して脅威とならないことをレジストリが証明する必要があるということを強く提示します。

　このガイドラインに従わない方法でワイルドカードを使用するすべてのTLDは、できるだけ早急にそのようなワイルドカードを削除することを推奨します。

謝辞

　IABは、有益な助言と、また幾つかのケースにおいては多数の文書に関して、 David Schairer、John Curran、John Klensin、Steve Bellovin の親切な支援に感謝の意を表明します。これらの寄稿者達は、その寄稿を使用してIABが行ったことに関して責任を負いません。 Leslie Daigleは本文書の作成に関与していません。