HTTP/1.1 200 OK Date: Mon, 14 Jul 2025 23:29:20 GMT Last-Modified: Tue, 13 Jun 2023 05:32:56 GMT ETag: "3eda-5fdfc2ad8f200" Accept-Ranges: bytes Content-Length: 16090 Content-Type: text/plain; charset=utf-8 Strict-Transport-Security: max-age=2592000 ネットワークワーキンググループ Y. Morishita RFC: 4074 JPRS 分類: 情報提供(Informational) T. Jinmei Toshiba 2005年5月 IPv6アドレスへのDNS問い合わせを阻害する一般的な誤った振る舞い Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). 要旨 DNS権威サーバーがAAAAリソースレコードを問い合わされた際に、幾つかの 誤った振る舞いをすることが知られている。そのような振る舞いは、本来 利用可能であるべきIPv4通信をブロックしてしまう可能性があり、その結果 名前解決で大幅な遅延が生じる。あるいは、サービス不能攻撃を引き起こして しまうことすらある。本文書は、既知の事例の詳細を記述し、その影響に ついて議論する。 1. はじめに IPv6をサポートする多数の既存DNSクライアント(リゾルバー)は、はじめに 対象ホスト名のAAAAリソースレコード(RR)を検索し、次いで同じ名前の A RRを検索する。このフォールバックの仕組みはDNS仕様に基づくものであり、 権威サーバーに追従されない場合、不愉快な結果を生じさせる可能性がある。 例えば、ある事例では、Webブラウザーが本来であれば到達できたかも しれないWebサーバーとの接続に失敗する。以下のセクションにおいて、 本文書はそのような誤った振る舞いとその(悪)影響の典型的な事例を記述 する。 誤った振る舞いはAAAA RR固有ではないことに注意せよ。実際、既知の例は すべてMX、NS、SOA RRへの問い合わせの事例にも適用される。著者らは、A RR 以外のすべてのタイプの問い合わせに一般化され得ると考えている。とは言え、 本文書では、AAAAへの問い合わせに集中する。AAAAの問題はIPv6をサポート するリゾルバーにとって特に深刻であり、多数のエンドユーザーに影響する からである。エンドユーザーのリゾルバーは、A、AAAAのどちらかあるいは 両方しか送信しないので、他の事例の問題は相対的に軽微である。 Morishita & Jinmei Informational [Page 1]  RFC 4074 Common Misbehavior Against DNS Queries May 2005 2. ネットワークモデル 本文書では、DNSを使用する名前解決環境の典型的なネットワークモデルを 想定する。モデルは三つの構成要素、スタブリゾルバー、キャッシング サーバー、権威サーバーで構成される。スタブリゾルバーは再帰問い合わせを キャッシングサーバーに発行し、キャッシングサーバーは名前解決 手続きすべてを再帰的に処理する。キャッシングサーバーは問い合わせの結果を キャッシュし、その結果をスタブリゾルバーに送信する。権威サーバーは、 自分が権威を持つ名前への問い合わせに対し、通常は非再帰的な方法で応答 する。 3. 期待される振る舞い 権威サーバーが、あるホスト名のA RRは保持しているが、AAAA RRは保持して いない状況を考える。その場合、サーバーは、その名前のAAAA RRへの問い合わせ に対し、応答コード(RCODE)が0(エラー無しを提示)で回答部が空の応答を 返すべきである([1]のセクション4.3.2及び6.2.4を参照)。そのような 応答は、問い合わせ名に対してAAAAとは異なるタイプのRRが少なくとも一つ 存在することを示しているので、スタブリゾルバーは次にA RRを検索する ことができる。 このようにして、キャッシングサーバーは問い合わせ名はAAAA RRを保持しない (が、他のタイプのRRは保持するかもしれない)という事実をキャッシュする ので、以後は同じ名前のAAAA RRへの問い合わせ応答時間を改善できる。 4. 問題のある振る舞い 権威サーバーが期待される振る舞いに合致しない既知の事例が幾つか存在 する。本セクションはそれら問題のある事例を記述する。 4.1. AAAAへの問い合わせを無視する ある種の権威サーバーは、AAAA RRへの問い合わせを無視するように見える。 その結果、スタブリゾルバーがA RRへの問い合わせにフォールバックするために 遅延を生じさせる。この振る舞いは、リゾルバーまたはリゾルバーを呼び出した アプリケーションにおいて致命的なタイムアウトを引き起こすかもしれない。 たとえリゾルバーが結果的にフォールバックしたとしても、アプリケーション ユーザーにとって、特にWebブラウジングのような対話的なアプリケーション ユーザーにとって許容できない遅延が生じる可能性がある。 4.2. "ドメイン名不在"を返す このタイプのサーバーは、AAAA RRへの問い合わせに対してRCODE 3 ("ドメイン名不在")を指定した応答を返す。これは問い合わせ名に対して、 どのようなタイプのどのようなRRも保持しないことを示すものである。 Morishita & Jinmei Informational [Page 2]  RFC 4074 Common Misbehavior Against DNS Queries May 2005 この応答を受け取ったスタブリゾルバーは、直ちに処理を諦め、決して フォールバックはしない。たとえリゾルバーがA RRへの問い合わせをリトライ しても、その名前に対する不在応答がキャッシングサーバーにキャッシュ されているので、キャッシングサーバーは単に不在応答を返すだけだろう。 結果として、スタブリゾルバーは名前解決処理において致命的なエラーが 生じたとみなす。 この振る舞いの幾つかの例は著者らも知っている。本文書執筆時点では、 すべて修正されている。 4.3. 他のエラーコードを返す 他の権威サーバーは、RCODE 3("ドメイン名不在")以外のエラー応答コードを 指定した応答を返す。そのようなRCODEの一つが4("未実装")である。これは そのサーバーが問い合わせでリクエストされたタイプをサポートしないことを 示すものである。 これらの事例は先に紹介したものよりも害は少ない。スタブリゾルバーが A RRへの問い合わせにフォールバックすれば、キャッシングサーバーは正しく 問い合わせを処理し、適切な応答を返すからである。 しかし、これらは依然として深刻な影響を引き起こす可能性がある。 AAAA RRへの問い合わせに対し、RCODE 2("サーバー障害")を返す権威サーバー 実装が存在した。広く普及しているあるメールサーバー実装と特定の タイプのリゾルバーライブラリの組み合わせは、この結果をリトライの提示 であると解釈し、A RRへの問い合わせへのフォールバックを行わない。その 結果、メッセージ配送は失敗する。 これらの応答コードが指定された応答をキャッシングサーバーが受信した 場合、問い合わせ名がAAAA RRを保持しないという事実をキャッシュしない。 その結果、将来において冗長なAAAA RRへの問い合わせが発生する。この 振る舞いはネットワーク帯域を浪費し、権威サーバーの負荷を増大させる ことになる。 著者はらそのような実装を見たことがないが、RCODE 1("フォーマット エラー")が指定される場合も同様の影響が生じるだろう。 4.4. 壊れた応答を返す 別のタイプの権威サーバーは、AAAAへの問い合わせに壊れた応答を返す。 RRタイプがAAAAでRDATA長が4バイトになっている応答を返すのがこの類の 既知の振る舞いである。4バイトのデータは、問い合わせホスト名のIPv4 アドレスのように見える。 Morishita & Jinmei Informational [Page 3]  RFC 4074 Common Misbehavior Against DNS Queries May 2005 つまり、回答部のRRは以下のように記述されるだろう。 www.bad.example. 600 IN AAAA 192.0.2.1 これはもちろん不正である(少なくとも無意味である)。 広く普及しているキャッシングサーバー実装は、壊れた応答を透過的に スタブリゾルバーに返す(またキャッシュもする)。別の既知のサーバー実装は 応答を自身で構文解析し、RCODE 2("サーバー障害")を指定した独立した 応答を送信する。 いずれの場合においても、壊れた応答は同じ名前のA RRへの問い合わせに 影響を与えない。スタブリゾルバーはA RRへの問い合わせにフォールバックし、 適切な応答を得るだろう。 しかし、後者の場合、先のセクションに記述したのと同じ悪影響、すなわち 冗長なAAAA RRへの問い合わせが生じる。 4.5. 不適切な委任(Lame Delegation)を生じさせる 幾つかの権威サーバーは、AAAAへの問い合わせに対し、不適切な委任を生じ させるような応答をする。この場合、親ゾーンは権威サーバーがゾーンの 権威を持つべきだと指定しているが、権威サーバー自身はゾーン内にある AAAAへの問い合わせに対して権威を持つ応答を返さない(応答にAAビットが 設定されない)。その一方で、その権威サーバーはAへの問い合わせに対しては 権威を持つ応答を返す。 キャッシングサーバーがゾーン内のAAAA RRを要求すると、委任が不適切で あると認識し、スタブリゾルバーにはRCODE 2("サーバー障害")を指定した 応答を返す。 更に、幾つかのキャッシングサーバーは、そのゾーンの権威サーバーは 不適切であると記録し、一定の期間使用しなくなる。この種のキャッシング サーバーを使用する場合、たとえスタブリゾルバーがA RRへの問い合わせに フォールバックしても、キャッシングサーバーはすべての権威サーバーが "不適切である"という理由で、単にRCODE 2を指定した応答を返すだけになる。 振る舞いが若干緩和された実装も存在する。それらは不適切なサーバーの 使用を回避しようと試みるが、最後の手段としてそのようなサーバーも試行 する。この種のキャッシングサーバーを使用する場合、スタブリゾルバーは サーバー障害提示後にフォールバックすれば正しい応答を取得する。しかし、 この実装は依然として先のセクションで説明された冗長なAAAA問い合わせを 生じさせる。 Morishita & Jinmei Informational [Page 4]  RFC 4074 Common Misbehavior Against DNS Queries May 2005 5. セキュリティに関する考慮点 CERT/CCは、セクション4.2記載のRCODE 3("名前エラー")を指定した応答が サービス不能攻撃に使用できると指摘した[2]。セクション4.5記載の "不適切な委任"に特定のタイプのキャッシングサーバーが組み合わされた 環境にも同じ議論が当てはまる。 6. Acknowledgements Erik Nordmark encouraged the authors to publish this document as an RFC. Akira Kato and Paul Vixie reviewed a preliminary version of this document. Pekka Savola carefully reviewed a previous version and provided detailed comments. Bill Fenner, Scott Hollenbeck, Thomas Narten, and Alex Zinin reviewed and helped improve the document at the last stage for publication. 7. Informative References [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from AAAA queries could cause denial-of-service conditions", March 2003, . Authors' Addresses MORISHITA Orange Yasuhiro Research and Development Department, Japan Registry Services Co.,Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan EMail: yasuhiro@jprs.co.jp JINMEI Tatuya Corporate Research & Development Center, Toshiba Corporation 1 Komukai Toshiba-cho, Saiwai-ku Kawasaki-shi, Kanagawa 212-8582 Japan EMail: jinmei@isl.rdc.toshiba.co.jp Morishita & Jinmei Informational [Page 5]  RFC 4074 Common Misbehavior Against DNS Queries May 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at https://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Morishita & Jinmei Informational [Page 6]