idnits 2.17.1 draft-wkumari-dnsop-extended-error-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2017) is 2613 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2671' is mentioned on line 144, but not defined ** Obsolete undefined reference: RFC 2671 (Obsoleted by RFC 6891) == Missing Reference: 'RFC6891' is mentioned on line 162, but not defined == Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 335, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google 4 Intended status: Informational E. Hunt 5 Expires: August 31, 2017 ISC 6 R. Arends 7 Nominet 8 W. Hardaker 9 USC/ISI 10 February 27, 2017 12 Extended DNS Errors 13 draft-wkumari-dnsop-extended-error-00 15 Abstract 17 This document defines an extensible method to return additional 18 information about the cause of DNS errors. The primary use case is 19 to extend SERVFAIL to provide additional information about the cause 20 of DNS and DNSSEC failures. 22 [ Note: I always have a hard time with EDNS terminology - I'm saying 23 that Extended DNS Errors are carried as EDNS Options, but is this 24 correct? They are optional TLVs in "options" in RDATA in OPTion RR , 25 but that's not readable. ] 27 [ Open question: The document currently defines a registry for 28 errors. It has also been suggested that the option also carry human 29 readable (text) messages, so allow the server admin to provide 30 additional debugging information (e.g: "example.com pointed their NS 31 at us. No idea why...", "We don't provide recursive DNS to 32 192.0.2.0. Please stop asking...", "Have you tried Acme Anvil and 33 DNS? We do DNS right..." (!). Please let us know if you think text 34 is needed, or if a 16bit FCFS registry is expressive enough. ] 36 [ Open question: This document discusses extended *errors*, but it 37 has been suggested that this could be used to also annotate *non- 38 error* messages. The authors do not think that this is a good idea, 39 but could be persuaded otherwise. ] 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on August 31, 2017. 58 Copyright Notice 60 Copyright (c) 2017 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction and background . . . . . . . . . . . . . . . . . 3 76 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 77 2. Extended Error EDNS0 option format . . . . . . . . . . . . . 4 78 3. Use of the Extended DNS Error option . . . . . . . . . . . . 4 79 4. Defined Extended DNS Errors . . . . . . . . . . . . . . . . . 5 80 4.1. Extended DNS Error Code 1 - DNSSEC Bogus . . . . . . . . 5 81 4.2. Extended DNS Error Code 2 - DNSSEC Indeterminite . . . . 5 82 4.3. Extended DNS Error Code 3 - Lame . . . . . . . . . . . . 5 83 4.4. Extended DNS Error Code 4 - Prohibited . . . . . . . . . 5 84 4.5. Extended DNS Error Code 5 - TooBusy . . . . . . . . . . . 6 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 86 6. Open questions . . . . . . . . . . . . . . . . . . . . . . . 7 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 91 9.2. Informative References . . . . . . . . . . . . . . . . . 8 92 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 95 1. Introduction and background 97 There are many reasons that a DNS query may fail, some of them 98 transient, some permanent; some can be resolved by querying another 99 server, some are likely best handled by stopping resolution. 100 Unfortunately, the error signals that a DNS server can return are 101 very limited, and are not very expressive. This means that 102 applications and resolvers often have to "guess" at what the issue is 103 - e.g the answer was marked REFUSED because of a lame delegation, or 104 because there is a lame delegation or because the nameserver is still 105 starting up and loading zones? Is a SERVFAIL a DNSSEC validation 106 issue, or is the nameserver experiencing a bad hair day? 108 A good example of issues that would benefit by additional error 109 information is an error caused by a DNSSEC validation issue. When a 110 stub resolver queries a DNSSEC bogus name (using a validating 111 resolver), their machine receives a SERVFAIL in response. 112 Unfortunately, SERVFAIL is used to signal many sorts of DNS errors, 113 and so the stub resolver simply asks the next configured DNS 114 resolver. The result of trying the next resulver is one of two 115 outcomes: either the next resolver also validates, a SERVFAIL is 116 returned again, and the user gets an (largely) incomprehensible error 117 message, or either the next resolver is not a validating resolver, 118 and the user is returned a potentially harmful result. 120 This document specifies a mechanism to extend (or annotate) DNS 121 errors to provide additional information about the cause of the 122 error. This information can be used by the resolver to make a 123 decision whether to retry or not, or by technical users attempting to 124 debug issues. 126 This document specifies a mechanism to extend (or annotate) DNS 127 errors to provide additional information about the cause of the 128 error. This information can be used by a resolver to make a decision 129 whether or no to retry, or by administrators and technical users 130 attempting to debug issues. 132 Here is a reference to an "external" (non-RFC / draft) thing: 133 ([IANA.AS_Numbers]). And this is a link to an 134 ID:[I-D.ietf-sidr-iana-objects]. 136 1.1. Requirements notation 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2. Extended Error EDNS0 option format 144 This draft uses an EDNS0 ([RFC2671]) option to include extended error 145 (ExtError) information in DNS messages. The option is structured as 146 follows: 148 1 1 1 1 1 1 149 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 150 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 151 0: | OPTION-CODE | 152 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 153 2: | OPTION-LENGTH | 154 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 155 4: | R | FLAGS | 156 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 157 6: | CODE | 158 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 160 o OPTION-CODE, 2 octets (Defined in [RFC6891]), for ExtError is TBD. 162 o OPTION-LENGTH, 2 octets ((Defined in [RFC6891]) contains the 163 length of the payload (everything after OPTION-LENGTH) in octets 164 and should be 4. 166 o FLAGS, 2 octets. 168 o CODE, 2 octets. 170 Currently the only defined flag is the R flag. 172 R - Retry The R (or Retry) flag provides a hint to the receiver if 173 it should retry the query, possibly by querying another server. 174 If the R bit is set (1), the sender believes that retrying the 175 query may provide a successful answer next time; if the R bit is 176 clear (0), the sender believes that it should not ask another 177 server. 179 The remaining bits in the flags field MUST be set to 0 by the sender 180 and SHOULD be ignored by the receiver. 182 Code: A code point into the IANA "Extended DNS Errors" registry. 184 3. Use of the Extended DNS Error option 186 The Extended DNS Error (EDE) is an EDNS option. It can be included 187 in any error response (SERVFAIL, NXDOMAIN, REFUSED, etc) to a query 188 that includes an EDNS option. This document includes a set of 189 initial codepoints (and requests to the IANA to add them to the 190 registry), but is extensible via the IANA registry to allow 191 additional error codes to be defined in the future. 193 The R (Retry) flag provides a hint (or suggestion) as to what the 194 receiver may want to do with this annotated error. The mechanism is 195 specifically designed to be extensible, and so implementations may 196 receive EDE codes that it does not understand. The R flag allows 197 implementations to make a decision as to what to do if it receives a 198 response with an unknown code - retry or drop the query. Note that 199 this flag is only a suggestion or hint. Receivers can choose to 200 ignore this hint. 202 4. Defined Extended DNS Errors 204 This document defines some initial EDE codes. The mechanism is 205 intended to be extensible, and additional codepoints will be 206 registered in the "Extended DNS Errors" registry. This document 207 provides suggestions for the R flag, but the originating server may 208 ignore these recommendations if it knows better. 210 4.1. Extended DNS Error Code 1 - DNSSEC Bogus 212 The resolver attempted to perform DNSSEC validation, but validation 213 ended in the Bogus state. The R flag should be set. 215 4.2. Extended DNS Error Code 2 - DNSSEC Indeterminite 217 The resolver attempted to perform DNSSEC validation, but validation 218 ended in the Indeterminate state. 220 Usually attached to SERVFAIL messages. The R flag should be set. 222 4.3. Extended DNS Error Code 3 - Lame 224 An authoritative resolver that receives a query (with the RD bit 225 clear) for a domain for which it is not authoritative SHOULD include 226 this EDE code in the REFUSED response. 228 Implementations should not set the R flag in this case (another 229 nameserver might not be lame). 231 4.4. Extended DNS Error Code 4 - Prohibited 233 An authoritative or recursive resolver that receives a query from an 234 "unauthorized" client can annotate its REFUSED message with this 235 code. Examples of "unauthorized" clients are recursive queries from 236 IP addresses outside the network, blacklisted IP addresses, etc. 238 Implementations SHOULD allow operators to define what to set the R 239 flag to in this case. 241 4.5. Extended DNS Error Code 5 - TooBusy 243 [ Ed: This might be a bad idea. It is intended to allow servers 244 under a DoS (for example a random subdomain attack) to signal to 245 recursive clients that they are being abusive and should back off. 246 This may be a bad idea -- it may "complete the attack", it may be 247 spoofable (by anyone who could also do a MITM style attack), etc. ] 249 A nameserver which is under excessive load (for example, because it 250 is experiencing a DoS) may annotate any answer with this code. 252 It is RECOMMENDED that implementations set the R flag in this case, 253 but may allow operators to define what to set the R flag to. 255 [ agreed: bad idea -wjh ] 257 5. IANA Considerations 259 [This section under construction ] 261 This document defines a new EDNS(0) option, entitled "Extended DNS 262 Error", assigned a value of TBD1 from the "DNS EDNS0 Option Codes 263 (OPT)" registry [to be removed upon publication: 264 [http://www.iana.org/assignments/dns-parameters/dns- 265 parameters.xhtml#dns-parameters-11] 267 Value Name Status Reference 268 ----- ---------------- ------ ------------------ 269 TBD Extended DNS Error TBD [ This document ] 271 Data Tag Name Length Meaning ---- ---- ------ ------- TBD1 FooBar N 272 FooBar server 274 The IANA is requested to create and maintain the "Extended DNS Error 275 codes" registry. The codepoint space is broken into 3 ranges: 277 o 1 - 16384: Specification required. 279 o 16385 - 65000: First Come First Served 281 o 65000 - 65534: Experimental / Private use 283 The codepoints 0, 65535 are reserved. 285 6. Open questions 287 1 Can this be included in *any* response or only responses to 288 requests that included an EDNS option? Resolvers are supposed to 289 ignore additional. EDNS capable ones are supposed to simply 290 ignore unknown options. I know the spec says you can only include 291 EDNS0 in a response if in a request -- it is time to reevaluate 292 this? 294 2 Can this be applied to *any* response, or only error responses? 296 7. Security Considerations 298 DNSSEC is being deployed - unfortunately a significant number of 299 clients (TODO: Link to Geoff H stats), when receiving a SERVFAIL from 300 a validating resolver because of a DNSSEC validaion issue simply ask 301 the next (non-validating) resolver in their list, and do don't get 302 any of the protections which DNSSEC should provide. This is very 303 similar to a kid asking his mother if he can have another cookie. 304 When the mother says "No, it will ruin your dinner!", going off and 305 asking his (more permissive) father and getting a "Yes, sure, 306 cookie!". 308 8. Acknowledgements 310 The authors wish to thank Geoff Huston. They also vaguely remember 311 discussing this with a number of people over the years, but have 312 forgotten who all they were -- if you were one of them, and are not 313 listed, please let us know and we'll acknowledge you. 315 I also want to thank the band "Infected Mushroom" for providing a 316 good background soundtrack (and to see if I can get away with this!) 318 Another author would like to thank the band "Mushroom Infectors" 320 9. References 322 9.1. Normative References 324 [IANA.AS_Numbers] 325 IANA, "Autonomous System (AS) Numbers", 326 . 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 330 RFC2119, March 1997, 331 . 333 9.2. Informative References 335 [I-D.ietf-sidr-iana-objects] 336 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 337 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 338 progress), May 2011. 340 Appendix A. Changes / Author Notes. 342 [RFC Editor: Please remove this section before publication ] 344 From -00 to -01; 346 o Placeholder to remind me to include changelog. 348 Authors' Addresses 350 Warren Kumari 351 Google 352 1600 Amphitheatre Parkway 353 Mountain View, CA 94043 354 US 356 Email: warren@kumari.net 358 Evan Hunt 359 ISC 360 950 Charter St 361 Redwood City, CA 94063 362 US 364 Email: each@isc.org 366 Roy Arends 367 Nominet 368 UK 370 Email: TBD 371 Wes Hardaker 372 USC/ISI 373 P.O. Box 382 374 Davis, VA 95617 375 US