diff options
Diffstat (limited to 'contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt')
| -rw-r--r-- | contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt | 505 |
1 files changed, 0 insertions, 505 deletions
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt deleted file mode 100644 index 1094275..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt +++ /dev/null @@ -1,505 +0,0 @@ - - -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, <http://www.kb.cert.org/vuls/id/714121>. - - -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] - - |
