340 lines
13 KiB
Plaintext
340 lines
13 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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
|
||
|
||
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).
|
||
|
||
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.
|
||
|
||
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 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.
|
||
|
||
|
||
|
||
Morishita & Jinmei Informational [Page 1]
|
||
|
||
RFC 4074 Common Misbehavior Against DNS Queries May 2005
|
||
|
||
|
||
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 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.
|
||
|
||
3. Expected Behavior
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
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 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.
|
||
|
||
4.2. Return "Name Error"
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
Morishita & Jinmei Informational [Page 2]
|
||
|
||
RFC 4074 Common Misbehavior Against DNS Queries May 2005
|
||
|
||
|
||
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.
|
||
|
||
Several examples of this behavior are known to the authors. As of
|
||
this writing, all have been fixed.
|
||
|
||
4.3. Return Other Erroneous Codes
|
||
|
||
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.
|
||
|
||
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
|
||
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.
|
||
|
||
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 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Morishita & Jinmei Informational [Page 3]
|
||
|
||
RFC 4074 Common Misbehavior Against DNS Queries May 2005
|
||
|
||
|
||
That is, the RR in the answer section would be described as follows:
|
||
|
||
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 (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").
|
||
|
||
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 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.
|
||
|
||
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.
|
||
|
||
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."
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Morishita & Jinmei Informational [Page 4]
|
||
|
||
RFC 4074 Common Misbehavior Against DNS Queries May 2005
|
||
|
||
|
||
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
|
||
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, <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
|
||
|
||
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
|
||
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.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Morishita & Jinmei Informational [Page 6]
|
||
|