contrib/bind9/doc/rfc/rfc4074.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                       Y. Morishita
   8 Request for Comments: 4074                                          JPRS
   9 Category: Informational                                        T. Jinmei
  10                                                                  Toshiba
  11                                                                 May 2005
  12
  13
  14        Common Misbehavior Against DNS Queries for IPv6 Addresses
  15
  16 Status of This Memo
  17
  18    This memo provides information for the Internet community.  It does
  19    not specify an Internet standard of any kind.  Distribution of this
  20    memo is unlimited.
  21
  22 Copyright Notice
  23
  24    Copyright (C) The Internet Society (2005).
  25
  26 Abstract
  27
  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.
  34
  35 1.  Introduction
  36
  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.
  45
  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
  54    relatively minor.
  55
  56
  57
  58 Morishita & Jinmei           Informational                      [Page 1]
  59 \f
  60 RFC 4074         Common Misbehavior Against DNS Queries         May 2005
  61
  62
  63 2.  Network Model
  64
  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
  73    manner.
  74
  75 3.  Expected Behavior
  76
  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.
  84
  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.
  88
  89 4.  Problematic Behaviors
  90
  91    There are some known cases at authoritative servers that do not
  92    conform to the expected behavior.  This section describes those
  93    problematic cases.
  94
  95 4.1.  Ignore Queries for AAAA
  96
  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
 103    web browsing.
 104
 105 4.2.  Return "Name Error"
 106
 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.
 110
 111
 112
 113
 114 Morishita & Jinmei           Informational                      [Page 2]
 115 \f
 116 RFC 4074         Common Misbehavior Against DNS Queries         May 2005
 117
 118
 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.
 125
 126    Several examples of this behavior are known to the authors.  As of
 127    this writing, all have been fixed.
 128
 129 4.3.  Return Other Erroneous Codes
 130
 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.
 135
 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.
 139
 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.
 146
 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.
 152
 153    Using RCODE 1 ("Format error") would cause a similar effect, though
 154    the authors have not seen such implementations yet.
 155
 156 4.4.  Return a Broken Response
 157
 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
 162    host name.
 163
 164
 165
 166
 167
 168
 169
 170 Morishita & Jinmei           Informational                      [Page 3]
 171 \f
 172 RFC 4074         Common Misbehavior Against DNS Queries         May 2005
 173
 174
 175    That is, the RR in the answer section would be described as follows:
 176
 177      www.bad.example. 600 IN AAAA 192.0.2.1
 178
 179    which is, of course, bogus (or at least meaningless).
 180
 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").
 185
 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.
 189
 190    The latter case, however, causes the same bad effect as that
 191    described in the previous section: redundant queries for AAAA RRs.
 192
 193 4.5.  Make Lame Delegation
 194
 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.
 202
 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.
 206
 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."
 212
 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.
 219
 220
 221
 222
 223
 224
 225
 226 Morishita & Jinmei           Informational                      [Page 4]
 227 \f
 228 RFC 4074         Common Misbehavior Against DNS Queries         May 2005
 229
 230
 231 5.  Security Considerations
 232
 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
 237    server.
 238
 239 6.  Acknowledgements
 240
 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.
 247
 248 7.  Informative References
 249
 250    [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
 251         13, RFC 1034, November 1987.
 252
 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>.
 256
 257 Authors' Addresses
 258
 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
 263    Japan
 264
 265    EMail: yasuhiro@jprs.co.jp
 266
 267
 268    JINMEI Tatuya
 269    Corporate Research & Development Center, Toshiba Corporation
 270    1 Komukai Toshiba-cho, Saiwai-ku
 271    Kawasaki-shi, Kanagawa  212-8582
 272    Japan
 273
 274    EMail: jinmei@isl.rdc.toshiba.co.jp
 275
 276
 277
 278
 279
 280
 281
 282 Morishita & Jinmei           Informational                      [Page 5]
 283 \f
 284 RFC 4074         Common Misbehavior Against DNS Queries         May 2005
 285
 286
 287 Full Copyright Statement
 288
 289    Copyright (C) The Internet Society (2005).
 290
 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.
 294
 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.
 302
 303 Intellectual Property
 304
 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.
 313
 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.
 320
 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-
 325    ipr@ietf.org.
 326
 327 Acknowledgement
 328
 329    Funding for the RFC Editor function is currently provided by the
 330    Internet Society.
 331
 332
 333
 334
 335
 336
 337
 338 Morishita & Jinmei           Informational                      [Page 6]
 339 \f