+++ /dev/null
-
-
-
-
-IETF DNSOP Working Group Y. Morishita
-Internet-Draft JPRS
-Expires: April 23, 2005 T. Jinmei
- Toshiba
- October 23, 2004
-
-
- Common Misbehavior against DNS Queries for IPv6 Addresses
- draft-ietf-dnsop-misbehavior-against-aaaa-02.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
- 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 April 23, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004).
-
-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.
-
-
-
-Morishita & Jinmei Expires April 23, 2005 [Page 1]
-\f
-Internet-Draft Common Misbehavior against AAAA Queries October 2004
-
-
-1. Introduction
-
- 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.
-
- 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 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.
-
- 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.
-
-
-
-
-Morishita & Jinmei Expires April 23, 2005 [Page 2]
-\f
-Internet-Draft Common Misbehavior against AAAA Queries October 2004
-
-
-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.
-
-4.1 Ignore Queries for AAAA
-
- Some authoritative servers 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 or
- at the application which 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.
-
-
-4.2 Return "Name Error"
-
- This type of server returns a response with the RCODE being 3 ("Name
- Error") 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 fixed their behavior as of this
- writing.
-
-4.3 Return Other Erroneous Codes
-
- Other authoritative servers return a response with other erroneous
- response codes than RCODE 3 ("Name Error"). One well-known such
- RCODE is 4 ("Not Implemented"), indicating the servers do not support
- the requested type of query.
-
- 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.
-
- 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
-
-
-
-Morishita & Jinmei Expires April 23, 2005 [Page 3]
-\f
-Internet-Draft Common Misbehavior against AAAA Queries October 2004
-
-
- 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 failure of message delivery.
-
- 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.
-
- Using RCODE 1 ("Format error") would cause a similar effect, though
- the authors have not seen such implementations yet.
-
-4.4 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).
-
- 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
- ("Server failure").
-
- 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.5 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.
-
-
-
-Morishita & Jinmei Expires April 23, 2005 [Page 4]
-\f
-Internet-Draft Common Misbehavior against AAAA Queries October 2004
-
-
- When a caching server asks the server for AAAA RRs in the zone, it
- recognizes the delegation is lame, and returns a response with the
- RCODE being 2 ("Server failure") 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 2, 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 Sever failure. However, this still causes redundant AAAA
- queries as explained in the previous sections.
-
-5. Security Considerations
-
- 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.
-
-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. 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", 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>.
-
-
-
-
-
-
-
-
-
-Morishita & Jinmei Expires April 23, 2005 [Page 5]
-\f
-Internet-Draft Common Misbehavior against AAAA Queries October 2004
-
-
-Authors' Addresses
-
- MORISHITA Orange Yasuhiro
- Research and Development Department, Japan Registry Service 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
-
-Appendix A. Change History
-
- [NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION UPON PUBLICATION.]
-
- 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.
-
- Changes since draft-ietf-dnsop-misbehavior-against-aaaa-00 are:
-
- o Removed the appendix talking about live examples since these were
- not appropriate for official publication.
- o Added a note to rfc editor asking to remove this section upon
- publication.
-
-
-
-
-Morishita & Jinmei Expires April 23, 2005 [Page 6]
-\f
-Internet-Draft Common Misbehavior against AAAA Queries October 2004
-
-
- Changes since draft-ietf-dnsop-misbehavior-against-aaaa-01 are:
-
- o Used the standard keywords for describing RCODEs.
- o Provided more specific references for RFC1034.
- o Described an additional known issue regarding RCODE 2 ("Server
- failure"). Also changed the section title accordingly.
- o Moved the "Ignore Queries" section to the first of Section 4,
- since it looks the most widely seen misbehavior.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Morishita & Jinmei Expires April 23, 2005 [Page 7]
-\f
-Internet-Draft Common Misbehavior against AAAA Queries October 2004
-
-
-Intellectual Property Statement
-
- 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
- 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.
-
-
-Disclaimer of Validity
-
- 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.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2004). 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.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Morishita & Jinmei Expires April 23, 2005 [Page 8]
-\f
-
projects / thirdparty / bind9.git / commitdiff
