idnits 2.17.1 draft-ietf-dnsop-misbehavior-against-aaaa-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 316. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2004) is 7122 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF DNSOP Working Group Y. Morishita 3 Internet-Draft JPRS 4 Expires: April 23, 2005 T. Jinmei 5 Toshiba 6 October 23, 2004 8 Common Misbehavior against DNS Queries for IPv6 Addresses 9 draft-ietf-dnsop-misbehavior-against-aaaa-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 23, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 There is some known misbehavior of DNS authoritative servers when 45 they are queried for AAAA resource records. Such behavior can block 46 IPv4 communication which should actually be available, cause a 47 significant delay in name resolution, or even make a denial of 48 service attack. This memo describes details of the known cases and 49 discusses the effect of the cases. 51 1. Introduction 53 Many existing DNS clients (resolvers) that support IPv6 first search 54 for AAAA Resource Records (RRs) of a target host name, and then for A 55 RRs of the same name. This fallback mechanism is based on the DNS 56 specifications, which if not obeyed by authoritative servers can 57 produce unpleasant results. In some cases, for example, a web 58 browser fails to connect to a web server it could otherwise reach. 59 In the following sections, this memo describes some typical cases of 60 such misbehavior and its (bad) effects. 62 Note that the misbehavior is not specific to AAAA RRs. In fact, all 63 known examples also apply to the cases of queries for MX, NS, and SOA 64 RRs. The authors even believe this can be generalized for all types 65 of queries other than those for A RRs. In this memo, however, we 66 concentrate on the case for AAAA queries, since the problem is 67 particularly severe for resolvers that support IPv6, which thus 68 affects many end users. Resolvers at end users normally send A 69 and/or AAAA queries only, and so the problem for the other cases is 70 relatively minor. 72 2. Network Model 74 In this memo, we assume a typical network model of name resolution 75 environment using DNS. It consists of three components; stub 76 resolvers, caching servers, and authoritative servers. A stub 77 resolver issues a recursive query to a caching server, which then 78 handles the entire name resolution procedure recursively. The 79 caching server caches the result of the query as well as sends the 80 result to the stub resolver. The authoritative servers respond to 81 queries for names for which they have the authority, normally in a 82 non-recursive manner. 84 3. Expected Behavior 86 Suppose that an authoritative server has an A RR but not a AAAA RR 87 for a host name. Then the server should return a response to a query 88 for a AAAA RR of the name with the response code (RCODE) being 0 89 (indicating no error) and with an empty answer section (see Sections 90 4.3.2 and 6.2.4 of [1]). Such a response indicates that there is at 91 least one RR of a different type than AAAA for the queried name, and 92 the stub resolver can then look for A RRs. 94 This way, the caching server can cache the fact that the queried name 95 does not have a AAAA RR (but may have other types of RRs), and thus 96 can improve the response time to further queries for a AAAA RR of the 97 name. 99 4. Problematic Behaviors 101 There are some known cases at authoritative servers that do not 102 conform to the expected behavior. This section describes those 103 problematic cases. 105 4.1 Ignore Queries for AAAA 107 Some authoritative servers seem to ignore queries for a AAAA RR, 108 causing a delay at the stub resolver to fall back to a query for an A 109 RR. This behavior may even cause a fatal timeout at the resolver or 110 at the application which calls the resolver. Even if the resolver 111 eventually falls back, the result can be an unacceptable delay for 112 the application user, especially with interactive applications like 113 web browsing. 115 4.2 Return "Name Error" 117 This type of server returns a response with the RCODE being 3 ("Name 118 Error") to a query for a AAAA RR, indicating it does not have any RRs 119 of any type for the queried name. 121 With this response, the stub resolver may immediately give up and 122 never fall back. Even if the resolver retries with a query for an A 123 RR, the negative response for the name has been cached in the caching 124 server, and the caching server will simply return the negative 125 response. As a result, the stub resolver considers this as a fatal 126 error in name resolution. 128 There have been several known examples of this behavior, but all the 129 examples that the authors know have fixed their behavior as of this 130 writing. 132 4.3 Return Other Erroneous Codes 134 Other authoritative servers return a response with other erroneous 135 response codes than RCODE 3 ("Name Error"). One well-known such 136 RCODE is 4 ("Not Implemented"), indicating the servers do not support 137 the requested type of query. 139 These cases are less harmful than the previous one; if the stub 140 resolver falls back to querying for an A RR, the caching server will 141 process the query correctly and return an appropriate response. 143 However, these can still cause a serious effect. There was an 144 authoritative server implementation that returned RCODE 2 ("Server 145 failure") to queries for AAAA RRs. One widely deployed mail server 146 implementation with a certain type of resolver library interpreted 147 this result as an indication of retry and did not fall back to 148 queries for A RRs, causing failure of message delivery. 150 If the caching server receives a response with these response codes, 151 it does not cache the fact that the queried name has no AAAA RR, 152 resulting in redundant queries for AAAA RRs in the future. The 153 behavior will waste network bandwidth and increase the load of the 154 authoritative server. 156 Using RCODE 1 ("Format error") would cause a similar effect, though 157 the authors have not seen such implementations yet. 159 4.4 Return a Broken Response 161 Another different type of authoritative servers returns broken 162 responses to AAAA queries. A known behavior of this category is to 163 return a response whose RR type is AAAA, but the length of the RDATA 164 is 4 bytes. The 4-byte data looks like the IPv4 address of the 165 queried host name. That is, the RR in the answer section would be 166 described like this: 168 www.bad.example. 600 IN AAAA 192.0.2.1 170 which is, of course, bogus (or at least meaningless). 172 A widely deployed caching server implementation transparently returns 173 the broken response (as well as caches it) to the stub resolver. 174 Another known server implementation parses the response by 175 themselves, and sends a separate response with the RCODE being 2 176 ("Server failure"). 178 In either case, the broken response does not affect queries for an A 179 RR of the same name. If the stub resolver falls back to A queries, 180 it will get an appropriate response. 182 The latter case, however, causes the same bad effect as that 183 described in the previous section: redundant queries for AAAA RRs. 185 4.5 Make Lame Delegation 187 Some authoritative servers respond to AAAA queries in a way causing 188 lame delegation. In this case the parent zone specifies that the 189 authoritative server should have the authority of a zone, but the 190 server does not return an authoritative response for AAAA queries 191 within the zone (i.e., the AA bit in the response is not set). On 192 the other hand, the authoritative server returns an authoritative 193 response for A queries. 195 When a caching server asks the server for AAAA RRs in the zone, it 196 recognizes the delegation is lame, and returns a response with the 197 RCODE being 2 ("Server failure") to the stub resolver. 199 Furthermore, some caching servers record the authoritative server as 200 lame for the zone and will not use it for a certain period of time. 201 With this type of caching server, even if the stub resolver falls 202 back to querying for an A RR, the caching server will simply return a 203 response with the RCODE being 2, since all the servers are known to 204 be "lame." 206 There is also an implementation that relaxes the behavior a little 207 bit. It basically tries to avoid using the lame server, but still 208 continues to try it as a last resort. With this type of caching 209 server, the stub resolver will get a correct response if it falls 210 back after Sever failure. However, this still causes redundant AAAA 211 queries as explained in the previous sections. 213 5. Security Considerations 215 The CERT/CC pointed out that the response with RCODE 3 ("Name Error") 216 described in Section 4.2 can be used for a denial of service attack 217 [2]. The same argument applies to the case of "lame delegation" 218 described in Section 4.5 with a certain type of caching server. 220 6. Acknowledgements 222 Erik Nordmark encouraged the authors to publish this document as an 223 Internet Draft. Akira Kato and Paul Vixie reviewed a preliminary 224 version of this document. Pekka Savola carefully reviewed a previous 225 version and provided detailed comments. Bill Fenner, Scott 226 Hollenbeck, Thomas Narten, and Alex Zinin reviewed and helped improve 227 the document at the last stage for publication. 229 7 Informative References 231 [1] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 232 1034, November 1987. 234 [2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from 235 AAAA queries could cause denial-of-service conditions", March 236 2003, . 238 Authors' Addresses 240 MORISHITA Orange Yasuhiro 241 Research and Development Department, Japan Registry Service Co.,Ltd. 242 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 243 Chiyoda-ku, Tokyo 101-0065 244 Japan 246 EMail: yasuhiro@jprs.co.jp 248 JINMEI Tatuya 249 Corporate Research & Development Center, Toshiba Corporation 250 1 Komukai Toshiba-cho, Saiwai-ku 251 Kawasaki-shi, Kanagawa 212-8582 252 Japan 254 EMail: jinmei@isl.rdc.toshiba.co.jp 256 Appendix A. Change History 258 [NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION UPON PUBLICATION.] 260 Changes since draft-morishita-dnsop-misbehavior-against-aaaa-00 are: 262 o Made a separate appendix and moved live examples to appendix so 263 that we can remove them when this document is (ever) officially 264 published. 265 o Revised some live examples based on the recent status. 266 o Noted in introduction that the misbehavior is not specific to AAAA 267 and that this document still concentrates on the AAAA case. 268 o Changed the section title of "delegation loop" to "lame 269 delegation" in order to reflect the essential point of the issue. 270 Wording on this matter was updated accordingly. 271 o Updated the Acknowledgements list. 272 o Changed the reference category from normative to informative (this 273 is an informational document after all). 274 o Changed the draft name to an IETF dnsop working group document (as 275 agreed). 276 o Applied several editorial fixes. 278 Changes since draft-ietf-dnsop-misbehavior-against-aaaa-00 are: 280 o Removed the appendix talking about live examples since these were 281 not appropriate for official publication. 282 o Added a note to rfc editor asking to remove this section upon 283 publication. 285 Changes since draft-ietf-dnsop-misbehavior-against-aaaa-01 are: 287 o Used the standard keywords for describing RCODEs. 288 o Provided more specific references for RFC1034. 289 o Described an additional known issue regarding RCODE 2 ("Server 290 failure"). Also changed the section title accordingly. 291 o Moved the "Ignore Queries" section to the first of Section 4, 292 since it looks the most widely seen misbehavior. 294 Intellectual Property Statement 296 The IETF takes no position regarding the validity or scope of any 297 Intellectual Property Rights or other rights that might be claimed to 298 pertain to the implementation or use of the technology described in 299 this document or the extent to which any license under such rights 300 might or might not be available; nor does it represent that it has 301 made any independent effort to identify any such rights. Information 302 on the procedures with respect to rights in RFC documents can be 303 found in BCP 78 and BCP 79. 305 Copies of IPR disclosures made to the IETF Secretariat and any 306 assurances of licenses to be made available, or the result of an 307 attempt made to obtain a general license or permission for the use of 308 such proprietary rights by implementers or users of this 309 specification can be obtained from the IETF on-line IPR repository at 310 http://www.ietf.org/ipr. 312 The IETF invites any interested party to bring to its attention any 313 copyrights, patents or patent applications, or other proprietary 314 rights that may cover technology that may be required to implement 315 this standard. Please address the information to the IETF at 316 ietf-ipr@ietf.org. 318 Disclaimer of Validity 320 This document and the information contained herein are provided on an 321 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 322 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 323 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 324 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 325 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 326 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 328 Copyright Statement 330 Copyright (C) The Internet Society (2004). This document is subject 331 to the rights, licenses and restrictions contained in BCP 78, and 332 except as set forth therein, the authors retain all their rights. 334 Acknowledgment 336 Funding for the RFC Editor function is currently provided by the 337 Internet Society.