7
Network Working Group Y. Morishita
8
Request for Comments: 4074 JPRS
9
Category: Informational T. Jinmei
14
Common Misbehavior Against DNS Queries for IPv6 Addresses
18
This memo provides information for the Internet community. It does
19
not specify an Internet standard of any kind. Distribution of this
24
Copyright (C) The Internet Society (2005).
28
There is some known misbehavior of DNS authoritative servers when
29
they are queried for AAAA resource records. Such behavior can block
30
IPv4 communication that should actually be available, cause a
31
significant delay in name resolution, or even make a denial of
32
service attack. This memo describes details of known cases and
33
discusses their effects.
37
Many existing DNS clients (resolvers) that support IPv6 first search
38
for AAAA Resource Records (RRs) of a target host name, and then for A
39
RRs of the same name. This fallback mechanism is based on the DNS
40
specifications, which if not obeyed by authoritative servers, can
41
produce unpleasant results. In some cases, for example, a web
42
browser fails to connect to a web server it could otherwise reach.
43
In the following sections, this memo describes some typical cases of
44
such misbehavior and its (bad) effects.
46
Note that the misbehavior is not specific to AAAA RRs. In fact, all
47
known examples also apply to the cases of queries for MX, NS, and SOA
48
RRs. The authors believe this can be generalized for all types of
49
queries other than those for A RRs. In this memo, however, we
50
concentrate on the case for AAAA queries, since the problem is
51
particularly severe for resolvers that support IPv6, which thus
52
affects many end users. Resolvers at end users normally send A
53
and/or AAAA queries only, so the problem for the other cases is
58
Morishita & Jinmei Informational [Page 1]
60
RFC 4074 Common Misbehavior Against DNS Queries May 2005
65
In this memo, we assume a typical network model of name resolution
66
environment using DNS. It consists of three components: stub
67
resolvers, caching servers, and authoritative servers. A stub
68
resolver issues a recursive query to a caching server, which then
69
handles the entire name resolution procedure recursively. The
70
caching server caches the result of the query and sends the result to
71
the stub resolver. The authoritative servers respond to queries for
72
names for which they have the authority, normally in a non-recursive
77
Suppose that an authoritative server has an A RR but has no AAAA RR
78
for a host name. Then, the server should return a response to a
79
query for an AAAA RR of the name with the response code (RCODE) being
80
0 (indicating no error) and with an empty answer section (see
81
Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that
82
there is at least one RR of a different type than AAAA for the
83
queried name, and the stub resolver can then look for A RRs.
85
This way, the caching server can cache the fact that the queried name
86
has no AAAA RR (but may have other types of RRs), and thus improve
87
the response time to further queries for an AAAA RR of the name.
89
4. Problematic Behaviors
91
There are some known cases at authoritative servers that do not
92
conform to the expected behavior. This section describes those
95
4.1. Ignore Queries for AAAA
97
Some authoritative servers seem to ignore queries for an AAAA RR,
98
causing a delay at the stub resolver to fall back to a query for an A
99
RR. This behavior may cause a fatal timeout at the resolver or at
100
the application that calls the resolver. Even if the resolver
101
eventually falls back, the result can be an unacceptable delay for
102
the application user, especially with interactive applications like
105
4.2. Return "Name Error"
107
This type of server returns a response with RCODE 3 ("Name Error") to
108
a query for an AAAA RR, indicating that it does not have any RRs of
109
any type for the queried name.
114
Morishita & Jinmei Informational [Page 2]
116
RFC 4074 Common Misbehavior Against DNS Queries May 2005
119
With this response, the stub resolver may immediately give up and
120
never fall back. Even if the resolver retries with a query for an A
121
RR, the negative response for the name has been cached in the caching
122
server, and the caching server will simply return the negative
123
response. As a result, the stub resolver considers this to be a
124
fatal error in name resolution.
126
Several examples of this behavior are known to the authors. As of
127
this writing, all have been fixed.
129
4.3. Return Other Erroneous Codes
131
Other authoritative servers return a response with erroneous response
132
codes other than RCODE 3 ("Name Error"). One such RCODE is 4 ("Not
133
Implemented"), indicating that the servers do not support the
134
requested type of query.
136
These cases are less harmful than the previous one; if the stub
137
resolver falls back to querying for an A RR, the caching server will
138
process the query correctly and return an appropriate response.
140
However, these can still cause a serious effect. There was an
141
authoritative server implementation that returned RCODE 2 ("Server
142
failure") to queries for AAAA RRs. One widely deployed mail server
143
implementation with a certain type of resolver library interpreted
144
this result as an indication of retry and did not fall back to
145
queries for A RRs, causing message delivery failure.
147
If the caching server receives a response with these response codes,
148
it does not cache the fact that the queried name has no AAAA RR,
149
resulting in redundant queries for AAAA RRs in the future. The
150
behavior will waste network bandwidth and increase the load of the
151
authoritative server.
153
Using RCODE 1 ("Format error") would cause a similar effect, though
154
the authors have not seen such implementations yet.
156
4.4. Return a Broken Response
158
Another type of authoritative servers returns broken responses to
159
AAAA queries. Returning a response whose RR type is AAAA with the
160
length of the RDATA being 4 bytes is a known behavior of this
161
category. The 4-byte data looks like the IPv4 address of the queried
170
Morishita & Jinmei Informational [Page 3]
172
RFC 4074 Common Misbehavior Against DNS Queries May 2005
175
That is, the RR in the answer section would be described as follows:
177
www.bad.example. 600 IN AAAA 192.0.2.1
179
which is, of course, bogus (or at least meaningless).
181
A widely deployed caching server implementation transparently returns
182
the broken response (and caches it) to the stub resolver. Another
183
known server implementation parses the response by itself, and sends
184
a separate response with RCODE 2 ("Server failure").
186
In either case, the broken response does not affect queries for an A
187
RR of the same name. If the stub resolver falls back to A queries,
188
it will get an appropriate response.
190
The latter case, however, causes the same bad effect as that
191
described in the previous section: redundant queries for AAAA RRs.
193
4.5. Make Lame Delegation
195
Some authoritative servers respond to AAAA queries in a way that
196
causes lame delegation. In this case, the parent zone specifies that
197
the authoritative server should have the authority of a zone, but the
198
server should not return an authoritative response for AAAA queries
199
within the zone (i.e., the AA bit in the response is not set). On
200
the other hand, the authoritative server returns an authoritative
201
response for A queries.
203
When a caching server asks the server for AAAA RRs in the zone, it
204
recognizes the delegation is lame, and returns a response with RCODE
205
2 ("Server failure") to the stub resolver.
207
Furthermore, some caching servers record the authoritative server as
208
lame for the zone and will not use it for a certain period of time.
209
With this type of caching server, even if the stub resolver falls
210
back to querying for an A RR, the caching server will simply return a
211
response with RCODE 2, since all the servers are known to be "lame."
213
There is also an implementation that relaxes the behavior a little
214
bit. It tries to avoid using the lame server, but continues to try
215
it as a last resort. With this type of caching server, the stub
216
resolver will get a correct response if it falls back after Server
217
failure. However, this still causes redundant AAAA queries, as
218
explained in the previous sections.
226
Morishita & Jinmei Informational [Page 4]
228
RFC 4074 Common Misbehavior Against DNS Queries May 2005
231
5. Security Considerations
233
The CERT/CC pointed out that the response with RCODE 3 ("Name
234
Error"), described in Section 4.2, can be used for a denial of
235
service attack [2]. The same argument applies to the case of "lame
236
delegation", described in Section 4.5, with a certain type of caching
241
Erik Nordmark encouraged the authors to publish this document as an
242
RFC. Akira Kato and Paul Vixie reviewed a preliminary version of
243
this document. Pekka Savola carefully reviewed a previous version
244
and provided detailed comments. Bill Fenner, Scott Hollenbeck,
245
Thomas Narten, and Alex Zinin reviewed and helped improve the
246
document at the last stage for publication.
248
7. Informative References
250
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
251
13, RFC 1034, November 1987.
253
[2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from
254
AAAA queries could cause denial-of-service conditions",
255
March 2003, <http://www.kb.cert.org/vuls/id/714121>.
259
MORISHITA Orange Yasuhiro
260
Research and Development Department, Japan Registry Services Co.,Ltd.
261
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
262
Chiyoda-ku, Tokyo 101-0065
265
EMail: yasuhiro@jprs.co.jp
269
Corporate Research & Development Center, Toshiba Corporation
270
1 Komukai Toshiba-cho, Saiwai-ku
271
Kawasaki-shi, Kanagawa 212-8582
274
EMail: jinmei@isl.rdc.toshiba.co.jp
282
Morishita & Jinmei Informational [Page 5]
284
RFC 4074 Common Misbehavior Against DNS Queries May 2005
287
Full Copyright Statement
289
Copyright (C) The Internet Society (2005).
291
This document is subject to the rights, licenses and restrictions
292
contained in BCP 78, and except as set forth therein, the authors
293
retain all their rights.
295
This document and the information contained herein are provided on an
296
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
297
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
298
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
299
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
300
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
301
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
303
Intellectual Property
305
The IETF takes no position regarding the validity or scope of any
306
Intellectual Property Rights or other rights that might be claimed to
307
pertain to the implementation or use of the technology described in
308
this document or the extent to which any license under such rights
309
might or might not be available; nor does it represent that it has
310
made any independent effort to identify any such rights. Information
311
on the procedures with respect to rights in RFC documents can be
312
found in BCP 78 and BCP 79.
314
Copies of IPR disclosures made to the IETF Secretariat and any
315
assurances of licenses to be made available, or the result of an
316
attempt made to obtain a general license or permission for the use of
317
such proprietary rights by implementers or users of this
318
specification can be obtained from the IETF on-line IPR repository at
319
http://www.ietf.org/ipr.
321
The IETF invites any interested party to bring to its attention any
322
copyrights, patents or patent applications, or other proprietary
323
rights that may cover technology that may be required to implement
324
this standard. Please address the information to the IETF at ietf-
329
Funding for the RFC Editor function is currently provided by the
338
Morishita & Jinmei Informational [Page 6]
added
removed
doc/rfc/rfc4074.txt
