Network Working Group Y. Morishita
Request for Comments: 4074 JPRS
Category: Informational T. Jinmei
Toshiba
May 2005
Network Working Group Y. Morishita
Request for Comments: 4074 JPRS
Category: Informational T. Jinmei
Toshiba
May 2005
Common Misbehavior Against DNS Queries for IPv6 Addresses
针对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).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can block IPv4 communication that should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of known cases and discusses their effects.
DNS权威服务器在查询AAAA资源记录时存在一些已知的错误行为。这种行为可能会阻止实际可用的IPv4通信，导致名称解析的显著延迟，甚至造成拒绝服务攻击。本备忘录描述了已知案例的细节，并讨论了其影响。
Many existing DNS clients (resolvers) that support IPv6 first search for AAAA Resource Records (RRs) of a target host name, and then for A RRs of the same name. This fallback mechanism is based on the DNS specifications, which if not obeyed by authoritative servers, can produce unpleasant results. In some cases, for example, a web browser fails to connect to a web server it could otherwise reach. In the following sections, this memo describes some typical cases of such misbehavior and its (bad) effects.
许多支持IPv6的现有DNS客户端（解析程序）首先搜索目标主机名的AAAA资源记录（RRs），然后搜索相同名称的RRs。此回退机制基于DNS规范，如果权威服务器不遵守这些规范，可能会产生令人不快的结果。例如，在某些情况下，web浏览器无法连接到本来可以访问的web服务器。在以下章节中，本备忘录描述了此类不当行为的一些典型案例及其（不良）影响。
Note that the misbehavior is not specific to AAAA RRs. In fact, all known examples also apply to the cases of queries for MX, NS, and SOA RRs. The authors believe this can be generalized for all types of queries other than those for A RRs. In this memo, however, we concentrate on the case for AAAA queries, since the problem is particularly severe for resolvers that support IPv6, which thus affects many end users. Resolvers at end users normally send A and/or AAAA queries only, so the problem for the other cases is relatively minor.
请注意，不良行为并非AAAA RRs特有。事实上，所有已知示例也适用于MX、NS和SOA RRs的查询情况。作者认为这可以推广到除RRs查询之外的所有类型的查询。然而，在本备忘录中，我们将重点讨论AAAA查询的情况，因为对于支持IPv6的解析程序来说，问题尤其严重，因此会影响许多最终用户。最终用户的解析器通常只发送A和/或AAAA查询，因此其他情况下的问题相对较小。
In this memo, we assume a typical network model of name resolution environment using DNS. It consists of three components: stub resolvers, caching servers, and authoritative servers. A stub resolver issues a recursive query to a caching server, which then handles the entire name resolution procedure recursively. The caching server caches the result of the query and sends the result to the stub resolver. The authoritative servers respond to queries for names for which they have the authority, normally in a non-recursive manner.
在本备忘录中，我们假设使用DNS的名称解析环境的典型网络模型。它由三个组件组成：存根解析器、缓存服务器和权威服务器。存根解析器向缓存服务器发出递归查询，然后缓存服务器递归地处理整个名称解析过程。缓存服务器缓存查询结果并将结果发送到存根解析器。权威服务器通常以非递归方式响应对其拥有权限的名称的查询。
Suppose that an authoritative server has an A RR but has no AAAA RR for a host name. Then, the server should return a response to a query for an AAAA RR of the name with the response code (RCODE) being 0 (indicating no error) and with an empty answer section (see Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that there is at least one RR of a different type than AAAA for the queried name, and the stub resolver can then look for A RRs.
假设权威服务器有一个RR，但主机名没有AAAA RR。然后，服务器应返回对名称的AAAA RR查询的响应，响应代码（RCODE）为0（表示无错误），且回答部分为空（参见[1]的第4.3.2节和第6.2.4节）。这样的响应表明，对于查询的名称，至少有一个RR的类型不同于AAAA，然后存根解析器可以查找RRs。
This way, the caching server can cache the fact that the queried name has no AAAA RR (but may have other types of RRs), and thus improve the response time to further queries for an AAAA RR of the name.
通过这种方式，缓存服务器可以缓存被查询名称没有AAAA RR（但可能有其他类型的RR）的事实，从而提高对名称的AAAA RR的进一步查询的响应时间。
There are some known cases at authoritative servers that do not conform to the expected behavior. This section describes those problematic cases.
权威服务器上存在一些不符合预期行为的已知情况。本节介绍这些有问题的案例。
Some authoritative servers seem to ignore queries for an AAAA RR, causing a delay at the stub resolver to fall back to a query for an A RR. This behavior may cause a fatal timeout at the resolver or at the application that calls the resolver. Even if the resolver eventually falls back, the result can be an unacceptable delay for the application user, especially with interactive applications like web browsing.
一些权威服务器似乎忽略了对AAAA RR的查询，导致存根解析程序的延迟退回到对AAAA RR的查询。此行为可能导致冲突解决程序或调用冲突解决程序的应用程序出现致命超时。即使解析器最终会退回，其结果也可能是应用程序用户无法接受的延迟，尤其是在web浏览等交互式应用程序中。
This type of server returns a response with RCODE 3 ("Name Error") to a query for an AAAA RR, indicating that it does not have any RRs of any type for the queried name.
这种类型的服务器返回一个带有RCODE 3（“名称错误”）的响应，以查询AAAA RR，表明它没有任何类型的RRs用于查询的名称。
With this response, the stub resolver may immediately give up and never fall back. Even if the resolver retries with a query for an A RR, the negative response for the name has been cached in the caching server, and the caching server will simply return the negative response. As a result, the stub resolver considers this to be a fatal error in name resolution.
有了这个响应，存根解析器可能会立即放弃，永远不会后退。即使冲突解决程序使用RR查询重试，名称的否定响应也已缓存在缓存服务器中，缓存服务器只会返回否定响应。因此，存根解析器认为这是名称解析中的致命错误。
Several examples of this behavior are known to the authors. As of this writing, all have been fixed.
作者知道这种行为的几个例子。在撰写本文时，所有问题都已解决。
Other authoritative servers return a response with erroneous response codes other than RCODE 3 ("Name Error"). One such RCODE is 4 ("Not Implemented"), indicating that the servers do not support the requested type of query.
其他权威服务器返回带有错误响应代码（RCODE 3除外）的响应（“名称错误”）。其中一个RCODE为4（“未实现”），表示服务器不支持请求的查询类型。
These cases are less harmful than the previous one; if the stub resolver falls back to querying for an A RR, the caching server will process the query correctly and return an appropriate response.
这些案件的危害性比前一次小；如果存根解析器返回到查询RR，缓存服务器将正确处理查询并返回适当的响应。
However, these can still cause a serious effect. There was an authoritative server implementation that returned RCODE 2 ("Server failure") to queries for AAAA RRs. One widely deployed mail server implementation with a certain type of resolver library interpreted this result as an indication of retry and did not fall back to queries for A RRs, causing message delivery failure.
然而，这些仍然会造成严重影响。有一个权威服务器实现将RCODE 2（“服务器故障”）返回给AAAA RRs查询。一个广泛部署的邮件服务器实现使用了某种类型的解析器库，将此结果解释为重试的指示，并且没有返回到对RRs的查询，从而导致消息传递失败。
If the caching server receives a response with these response codes, it does not cache the fact that the queried name has no AAAA RR, resulting in redundant queries for AAAA RRs in the future. The behavior will waste network bandwidth and increase the load of the authoritative server.
如果缓存服务器接收到带有这些响应代码的响应，它不会缓存被查询名称没有AAAA RR的事实，从而导致将来对AAAA RR的冗余查询。这种行为将浪费网络带宽并增加权威服务器的负载。
Using RCODE 1 ("Format error") would cause a similar effect, though the authors have not seen such implementations yet.
使用RCODE1（“格式错误”）会产生类似的效果，尽管作者还没有看到这样的实现。
Another type of authoritative servers returns broken responses to AAAA queries. Returning a response whose RR type is AAAA with the length of the RDATA being 4 bytes is a known behavior of this category. The 4-byte data looks like the IPv4 address of the queried host name.
另一种类型的权威服务器返回对AAAA查询的中断响应。返回RR类型为AAAA、RDATA长度为4字节的响应是此类的已知行为。4字节数据看起来像查询主机名的IPv4地址。
That is, the RR in the answer section would be described as follows:
也就是说，答案部分中的RR描述如下：
www.bad.example. 600 IN AAAA 192.0.2.1
www.bad.example。600英寸AAAA 192.0.2.1
which is, of course, bogus (or at least meaningless).
当然，这是假的（或者至少毫无意义）。
A widely deployed caching server implementation transparently returns the broken response (and caches it) to the stub resolver. Another known server implementation parses the response by itself, and sends a separate response with RCODE 2 ("Server failure").
A widely deployed caching server implementation transparently returns the broken response (and caches it) to the stub resolver. Another known server implementation parses the response by itself, and sends a separate response with RCODE 2 ("Server failure").translate error, please retry
In either case, the broken response does not affect queries for an A RR of the same name. If the stub resolver falls back to A queries, it will get an appropriate response.
在这两种情况下，中断的响应都不会影响对相同名称的RR的查询。如果存根解析器返回到查询，它将得到适当的响应。
The latter case, however, causes the same bad effect as that described in the previous section: redundant queries for AAAA RRs.
但是，后一种情况会产生与上一节所述相同的不良影响：AAAA RRs的冗余查询。
Some authoritative servers respond to AAAA queries in a way that causes lame delegation. In this case, the parent zone specifies that the authoritative server should have the authority of a zone, but the server should not return an authoritative response for AAAA queries within the zone (i.e., the AA bit in the response is not set). On the other hand, the authoritative server returns an authoritative response for A queries.
一些权威服务器响应AAAA查询的方式会导致lame委派。在这种情况下，父区域指定权威服务器应具有区域的权限，但服务器不应为区域内的AAAA查询返回权威响应（即，未设置响应中的AA位）。另一方面，权威服务器返回查询的权威响应。
When a caching server asks the server for AAAA RRs in the zone, it recognizes the delegation is lame, and returns a response with RCODE 2 ("Server failure") to the stub resolver.
当缓存服务器向服务器请求区域中的AAAA RRs时，它会识别委派是lame，并向存根解析程序返回带有RCODE 2（“服务器故障”）的响应。
Furthermore, some caching servers record the authoritative server as lame for the zone and will not use it for a certain period of time. With this type of caching server, even if the stub resolver falls back to querying for an A RR, the caching server will simply return a response with RCODE 2, since all the servers are known to be "lame."
此外，一些缓存服务器将权威服务器记录为区域的lame，并且在一定时间内不会使用它。对于这种类型的缓存服务器，即使存根解析程序返回到查询RR，缓存服务器也会简单地返回带有RCODE 2的响应，因为所有服务器都是已知的“lame”
There is also an implementation that relaxes the behavior a little bit. It tries to avoid using the lame server, but continues to try it as a last resort. With this type of caching server, the stub resolver will get a correct response if it falls back after Server failure. However, this still causes redundant AAAA queries, as explained in the previous sections.
还有一个实现稍微放松了行为。它试图避免使用lame服务器，但作为最后手段仍在继续尝试。使用这种类型的缓存服务器，如果存根解析器在服务器故障后返回，它将得到正确的响应。但是，这仍然会导致冗余AAAA查询，如前几节所述。
The CERT/CC pointed out that the response with RCODE 3 ("Name Error"), described in Section 4.2, can be used for a denial of service attack [2]. The same argument applies to the case of "lame delegation", described in Section 4.5, with a certain type of caching server.
CERT/CC指出，第4.2节中描述的带有RCODE 3（“名称错误”）的响应可用于拒绝服务攻击[2]。同样的论点也适用于第4.5节中描述的“lame委托”的情况，即使用某种类型的缓存服务器。
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.
Erik Nordmark鼓励作者以RFC的形式发布本文件。Akira Kato和Paul Vixie审查了本文件的初步版本。Pekka Savola仔细审查了以前的版本，并提供了详细的评论。Bill Fenner、Scott Hollenbeck、Thomas Narten和Alex Zinin在发布的最后阶段审查并帮助改进了该文档。
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from AAAA queries could cause denial-of-service conditions", March 2003, <http://www.kb.cert.org/vuls/id/714121>.
[2] CERT协调中心，“来自AAAA查询的错误域响应可能导致拒绝服务条件”，2003年3月<http://www.kb.cert.org/vuls/id/714121>.
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
日本东京101-0065西神田千代田区3-8-1号千代田第一栋东13楼日本注册服务有限公司森下橙色安弘研发部
EMail: yasuhiro@jprs.co.jp
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
金美Tatuya公司研发中心，东芝公司1 Komukai Toshiba cho，日本神奈川市川崎市西围区212-8582
EMail: jinmei@isl.rdc.toshiba.co.jp
EMail: jinmei@isl.rdc.toshiba.co.jp
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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 http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。