diff --git a/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt b/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt new file mode 100644 index 0000000000..1094275d3e --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt @@ -0,0 +1,505 @@ + + +IETF DNSOP Working Group Y. Morishita +Internet-Draft JPRS +Expires: July 11, 2004 T. Jinmei + Toshiba + January 11, 2004 + + + Common Misbehavior against DNS Queries for IPv6 Addresses + draft-ietf-dnsop-misbehavior-against-aaaa-00.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on July 11, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + There is some known misbehavior of DNS authoritative servers when + they are queried for AAAA resource records. Such behavior can block + IPv4 communication which should actually be available, cause a + significant delay in name resolution, or even make a denial of + service attack. This memo describes details of the known cases and + discusses the effect of the cases. + +1. Introduction + + Many DNS clients (resolvers) that support IPv6 first search for AAAA + Resource Records (RRs) of a target host name, and then for A RRs of + + + +Morishita & Jinmei Expires July 11, 2004 [Page 1] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + + 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. In the following + sections, this memo describes some typical cases of the misbehavior + and its (bad) effects. + + 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 even 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, and so the problem for the other cases is + relatively minor. + +2. Network Model + + 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 as well as 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. + +3. Expected Behavior + + Suppose that an authoritative server has an A RR but not a AAAA RR + for a host name. Then the server should return a response to a query + for a AAAA RR of the name with the RCODE being 0 (indicating no + error) and with an empty answer section [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. + + This way, the caching server can cache the fact that the queried name + does not have a AAAA RR (but may have other types of RRs), and thus + can improve the response time to further queries for a AAAA RR of the + name. + +4. Problematic Behaviors + + There are some known cases at authoritative servers that do not + conform to the expected behavior. This section describes those + problematic cases. + + + +Morishita & Jinmei Expires July 11, 2004 [Page 2] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + +4.1 Return NXDOMAIN + + This type of server returns a response with the RCODE being 3 + (NXDOMAIN) to a query for a AAAA RR, indicating it does not have any + RRs of any type for the queried name. + + 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 as a fatal + error in name resolution. + + There have been several known examples of this behavior, but all the + examples that the authors know have changed their behavior as of this + writing. + +4.2 Return NOTIMP + + Other authoritative servers return a response with the RCODE being 4 + (NOTIMP), indicating the servers do not support the requested type of + query. + + This case is 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. + + In this case, the caching server 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. + + Using SERVFAIL or FORMERR would cause the same effect, though the + authors have not seen such implementations yet. + +4.3 Return a Broken Response + + Another different type of authoritative servers returns broken + responses to AAAA queries. A known behavior of this category is to + return a response whose RR type is AAAA, but the length of the RDATA + is 4 bytes. The 4-byte data looks like the IPv4 address of the + queried host name. That is, the RR in the answer section would be + described like this: + + www.bad.example. 600 IN AAAA 192.0.2.1 + + which is, of course, bogus (or at least meaningless). + + + + +Morishita & Jinmei Expires July 11, 2004 [Page 3] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + + A widely deployed caching server implementation transparently returns + the broken response (as well as caches it) to the stub resolver. + Another known server implementation parses the response by + themselves, and sends a separate response with the RCODE being 2 + (SERVFAIL). + + 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. + + The latter case, however, causes the same bad effect as that + described in the previous section: redundant queries for AAAA RRs. + +4.4 Make Lame Delegation + + Some authoritative servers respond to AAAA queries in a way causing + lame delegation. In this case the parent zone specifies that the + authoritative server should have the authority of a zone, but the + server does 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. + + When a caching server asks the server for AAAA RRs in the zone, it + recognizes the delegation is lame, and return a response with the + RCODE being 2 (SERVFAIL) to the stub resolver. + + 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 the RCODE being SERVFAIL, since all the servers are + known to be "lame." + + There is also an implementation that relaxes the behavior a little + bit. It basically tries to avoid using the lame server, but still + 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 SERVFAIL. However, this still causes redundant AAAA + queries as explained in the previous sections. + +4.5 Ignore Queries for AAAA + + Some authoritative severs seem to ignore queries for a AAAA RR, + causing a delay at the stub resolver to fall back to a query for an A + RR. This behavior may even cause a fatal timeout at the resolver. + + + + + +Morishita & Jinmei Expires July 11, 2004 [Page 4] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + +5. Security Considerations + + The CERT/CC pointed out that the response with NXDOMAIN described in + Section 4.1 can be used for a denial of service attack [2]. The same + argument applies to the case of "lame delegation" described in + Section 4.4 with a certain type of caching server. + +6. Acknowledgements + + Erik Nordmark encouraged the authors to publish this document as an + Internet Draft. Akira Kato and Paul Vixie reviewed a preliminary + version of this document. Pekka Savola carefully reviewed a previous + version and provided detailed comments. + +Informative References + + [1] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 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 Service Co.,Ltd. + Fuundo Bldg 3F, 1-2 Kanda-Ogawamachi + Chiyoda-ku, Tokyo 101-0052 + 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 + +Appendix A. Live Examples + + In this appendix, we show concrete implementations and domain names + that may cause problematic cases so that the behavior can be + reproduced in a practical environment. The examples are for + + + +Morishita & Jinmei Expires July 11, 2004 [Page 5] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + + informational purposes only, and the authors do not intend to accuse + any implementations or zone administrators. + + The behavior described in Section 4.2 (return NOTIMP) can be found by + looking for a AAAA RR of www.css.vtext.com at 66.174.3.4. + + The behavior described in Section 4.3 (broken responses) can be seen + by querying for a AAAA RR of "www.gslb.mainichi.co.jp," which is an + alias of "www.mainichi.co.jp," at 210.173.172.2. The same behavior + can be found with the name "vip.alt.ihp.sony.co.jp," an alias of + "www.sony.co.jp," at 210.139.255.204. + + The behavior described in Section 4.4 (lame delegation) can be found + by querying for a AAAA RR of "www.ual.com" at 209.87.113.4. + + The behavior described in Section 4.5 (ignore queries) can be seen by + trying to ask for a AAAA RR of "ad.3jp.doubleclick.net," which is an + alias of "ad.jp.doubleclick.net," at 210.153.90.9. + + Many authoritative server implementations show the expected behavior + described in Section 3. Some DNS load balancers reportedly have a + problematic behavior shown in Section 4, but the authors do not have + a concrete example. The CERT/CC provides a list of implementations + that behave as described in Section 4.1 [2]. + + The BIND9 caching server implementation is an example of the latter + cases described in Section 4.3 and Section 4.4, respectively. The + BIND8 caching server implementation is an example of the former case + described in Section 4.3. As for the issue shown in Section 4.4, + BIND8 caching servers prior to 8.3.5 show the behavior described as + the former case in this section. The versions 8.3.5 and later of + BIND8 caching server behave like the BIND9 caching server + implementation with this matter. + + Regarding resolver implementations, the authors are only familiar + with the ones derived from the BIND implementation. These + implementations always fall back regardless of the RCODE; NXDOMAIN, + NOTIMP, or SERVFAIL. It even falls back when getting a broken + response. However, the behavior does not help the situation in the + NXDOMAIN case (see Section 4.1). Lame delegation (Section 4.4) also + causes a fatal error at the resolver side if the resolver is using + some older versions of BIND8 caching server. + + The authors hear that a stub resolver routine implemented in some web + browsers interprets the broken response described in Section 4.3 as a + fatal error and does not fall back to A queries. However, we have not + confirmed this information. + + + + +Morishita & Jinmei Expires July 11, 2004 [Page 6] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + +Appendix B. Change History + + Changes since draft-morishita-dnsop-misbehavior-against-aaaa-00 are: + + o Made a separate appendix and moved live examples to appendix so + that we can remove them when this document is (ever) officially + published. + + o Revised some live examples based on the recent status. + + o Noted in introduction that the misbehavior is not specific to AAAA + and that this document still concentrates on the AAAA case. + + o Changed the section title of "delegation loop" to "lame + delegation" in order to reflect the essential point of the issue. + Wording on this matter was updated accordingly. + + o Updated the Acknowledgements list. + + o Changed the reference category from normative to informative (this + is an informational document after all). + + o Changed the draft name to an IETF dnsop working group document (as + agreed). + + o Applied several editorial fixes. + + + + + + + + + + + + + + + + + + + + + + + + + +Morishita & Jinmei Expires July 11, 2004 [Page 7] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Morishita & Jinmei Expires July 11, 2004 [Page 8] + +Internet-Draft Common Misbehavior against AAAA Queries January 2004 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Morishita & Jinmei Expires July 11, 2004 [Page 9] + +