idnits 2.17.1 draft-ietf-dnsop-extended-error-01.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 60 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 02, 2018) is 2126 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) == Missing Reference: 'RFC2671' is mentioned on line 147, but not defined ** Obsolete undefined reference: RFC 2671 (Obsoleted by RFC 6891) == Missing Reference: 'RFC6891' is mentioned on line 169, but not defined == Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 415, but no explicit reference was found in the text Summary: 2 errors (**), 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: Standards Track E. Hunt 5 Expires: January 3, 2019 ISC 6 R. Arends 7 ICANN 8 W. Hardaker 9 USC/ISI 10 D. Lawrence 11 Akamai Technologies 12 July 02, 2018 14 Extended DNS Errors 15 draft-ietf-dnsop-extended-error-01 17 Abstract 19 This document defines an extensible method to return additional 20 information about the cause of DNS errors. The primary use case is 21 to extend SERVFAIL to provide additional information about the cause 22 of DNS and DNSSEC failures. 24 [ Open question: The document currently defines a registry for 25 errors. It has also been suggested that the option also carry human 26 readable (text) messages, to allow the server admin to provide 27 additional debugging information (e.g: "example.com pointed their NS 28 at us. No idea why...", "We don't provide recursive DNS to 29 192.0.2.0. Please stop asking...", "Have you tried Acme Anvil and 30 DNS? We do DNS right..." (!). Please let us know if you think text 31 is needed, or if a 16bit FCFS registry is expressive enough. ] 33 [ Open question: This document discusses extended *errors*, but it 34 has been suggested that this could be used to also annotate *non- 35 error* messages. The authors do not think that this is a good idea, 36 but could be persuaded otherwise. ] 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 3, 2019. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction and background . . . . . . . . . . . . . . . . . 3 73 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 74 2. Extended Error EDNS0 option format . . . . . . . . . . . . . 4 75 3. Use of the Extended DNS Error option . . . . . . . . . . . . 5 76 4. Defined Extended DNS Errors . . . . . . . . . . . . . . . . . 5 77 4.1. SERVFAIL(3) extended information codes . . . . . . . . . 6 78 4.1.1. Extended DNS Error Code 1 - DNSSEC Bogus . . . . . . 6 79 4.1.2. Extended DNS Error Code 2 - DNSSEC Indeterminate . . 6 80 4.1.3. Extended DNS Error Code 3 - Signature Expired . . . . 6 81 4.1.4. Extended DNS Error Code 4 - Signature Not Yet Valid . 6 82 4.1.5. Extended DNS Error Code 5 - Unsupported 83 DNSKEY Algorithm . . . . . . . . . . . . . . . . . . 6 84 4.1.6. Extended DNS Error Code 6 - Unsupported 85 DS Algorithm . . . . . . . . . . . . . . . . . . . . 6 86 4.1.7. Extended DNS Error Code 7 - DNSKEY missing . . . . . 6 87 4.1.8. Extended DNS Error Code 8 - RRSIGs missing . . . . . 6 88 4.1.9. Extended DNS Error Code 9 - No Zone Key Bit Set . . . 7 89 4.2. REFUSED(5) extended information codes . . . . . . . . . . 7 90 4.2.1. Extended DNS Error Code 1 - Lame . . . . . . . . . . 7 91 4.2.2. Extended DNS Error Code 2 - Prohibited . . . . . . . 7 92 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 93 5.1. new Extended Error Code EDNS Option . . . . . . . . . . . 7 94 5.2. new Extended Error Code EDNS Option . . . . . . . . . . . 7 95 6. Open questions . . . . . . . . . . . . . . . . . . . . . . . 8 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 97 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 99 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 100 9.2. Informative References . . . . . . . . . . . . . . . . . 9 101 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 10 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 104 1. Introduction and background 106 There are many reasons that a DNS query may fail, some of them 107 transient, some permanent; some can be resolved by querying another 108 server, some are likely best handled by stopping resolution. 109 Unfortunately, the error signals that a DNS server can return are 110 very limited, and are not very expressive. This means that 111 applications and resolvers often have to "guess" at what the issue is 112 - e.g the answer was marked REFUSED because of a lame delegation, or 113 because of a lame delegation or because the nameserver is still 114 starting up and loading zones? Is a SERVFAIL a DNSSEC validation 115 issue, or is the nameserver experiencing a bad hair day? 117 A good example of issues that would benefit by additional error 118 information is an error caused by a DNSSEC validation issue. When a 119 stub resolver queries a DNSSEC bogus name (using a validating 120 resolver), the stub resolver receives only a SERVFAIL in response. 121 Unfortunately, SERVFAIL is used to signal many sorts of DNS errors, 122 and so the stub resolver simply asks the next configured DNS 123 resolver. The result of trying the next resolver is one of two 124 outcomes: either the next resolver also validates, a SERVFAIL is 125 returned again, and the user gets an (largely) incomprehensible error 126 message; or the next resolver is not a validating resolver, and the 127 user is returned a potentially harmful result. 129 This document specifies a mechanism to extend (or annotate) DNS 130 errors to provide additional information about the cause of the 131 error. This information can be used by the resolver to make a 132 decision regarding whether or not to retry, or by technical users 133 attempting to debug issues. 135 Here is a reference to an "external" (non-RFC / draft) thing: 136 ([IANA.AS_Numbers]). And this is a link to an 137 ID:[I-D.ietf-sidr-iana-objects]. 139 1.1. Requirements notation 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 2. Extended Error EDNS0 option format 147 This draft uses an EDNS0 ([RFC2671]) option to include extended error 148 (ExtError) information in DNS messages. The option is structured as 149 follows: 151 1 1 1 1 1 1 152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 153 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 154 0: | OPTION-CODE | 155 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 156 2: | OPTION-LENGTH | 157 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 158 4: | R | RESERVED | 159 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 160 6: | RESPONSE-CODE | 161 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 162 8: | INFO-CODE | 163 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 164 A: | EXTRA-TEXT | 165 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 167 o OPTION-CODE, 2 octets (defined in [RFC6891]), for ExtError is TBD. 169 o OPTION-LENGTH, 2 octets ((defined in [RFC6891]) contains the 170 length of the payload (everything after OPTION-LENGTH) in octets 171 and should be 4. 173 o RESERVED, 2 octets; the first bit (R) indicates a flag defined in 174 this specification. The remaining bits are reserved for future 175 use, potentially as additional flags. 177 o RESPONSE-CODE, 2 octets: this SHOULD be a copy of the RCODE from 178 the primary DNS packet. When including multiple extended error 179 EDNS0 records in a response in order to provide additional error 180 information, the RESPONSE-CODE MAY be a different RCODE. 182 o INFO-CODE, 2 octets. 184 o A variable length EXTRA-TEXT field holding additional textual 185 information. It may be zero length when no additional textual 186 information is included. 188 Currently the only defined flag is the R flag. 190 R - Retry The R (or Retry) flag provides a hint to the receiver that 191 it should retry the query, probably by querying another server. 192 If the R bit is set (1), the sender believes that retrying the 193 query may provide a successful answer next time; if the R bit is 194 clear (0), the sender believes that it should not ask another 195 server. 197 The remaining bits in the RESERVED field are reserved for future use 198 and MUST be set to 0 by the sender and SHOULD be ignored by the 199 receiver. 201 INFO-CODE: A code point that, when combined with the RCODE from the 202 DNS packet, serve as a joint-index into the IANA "Extended DNS 203 Errors" registry. 205 3. Use of the Extended DNS Error option 207 The Extended DNS Error (EDE) is an EDNS option. It can be included 208 in any error response (SERVFAIL, NXDOMAIN, REFUSED, etc) to a query 209 that includes an EDNS option. This document includes a set of 210 initial codepoints (and requests to the IANA to add them to the 211 registry), but is extensible via the IANA registry to allow 212 additional error and information codes to be defined in the future. 214 The R (Retry) flag provides a hint (or suggestion) as to what the 215 receiver may want to do with this annotated error. The mechanism is 216 specifically designed to be extensible, and so implementations may 217 receive EDE codes that it does not understand. The R flag allows 218 implementations to make a decision as to what to do if it receives a 219 response with an unknown code - retry or drop the query. Note that 220 this flag is only a suggestion or hint. Receivers can choose to 221 ignore this hint. 223 The EXTRA-INFO textual field may be zero-length, or may hold 224 additional information useful to network operators. 226 4. Defined Extended DNS Errors 228 This document defines some initial EDE codes. The mechanism is 229 intended to be extensible, and additional codepoints will be 230 registered in the "Extended DNS Errors" registry. This document 231 provides suggestions for the R flag, but the originating server may 232 ignore these recommendations if it knows better. 234 The RESPONSE-CODE and the INFO-CODE from the EDE EDNS option is used 235 to serve as a double index into the "Extended DNS Error codes" IANA 236 registry, the initial values for which are defined in the following 237 sub-sections. 239 4.1. SERVFAIL(3) extended information codes 241 4.1.1. Extended DNS Error Code 1 - DNSSEC Bogus 243 The resolver attempted to perform DNSSEC validation, but validation 244 ended in the Bogus state. The R flag should not be set. 246 4.1.2. Extended DNS Error Code 2 - DNSSEC Indeterminate 248 The resolver attempted to perform DNSSEC validation, but validation 249 ended in the Indeterminate state. The R flag should not be set. 251 4.1.3. Extended DNS Error Code 3 - Signature Expired 253 The resolver attempted to perform DNSSEC validation, but the 254 signature was expired. The R flag should not be set. 256 4.1.4. Extended DNS Error Code 4 - Signature Not Yet Valid 258 The resolver attempted to perform DNSSEC validation, but the 259 signatures received were not yet valid. The R flag should not be 260 set. 262 4.1.5. Extended DNS Error Code 5 - Unsupported DNSKEY Algorithm 264 The resolver attempted to perform DNSSEC validation, but a DNSKEY 265 RRSET contained only unknown algorithms. The R flag should not be 266 set. 268 4.1.6. Extended DNS Error Code 6 - Unsupported DS Algorithm 270 The resolver attempted to perform DNSSEC validation, but a DS RRSET 271 contained only unknown algorithms. The R flag should not be set. 273 4.1.7. Extended DNS Error Code 7 - DNSKEY missing 275 A DS record existed at a parent, but no DNSKEY record could be found 276 for the child. The R flag should not be set. 278 4.1.8. Extended DNS Error Code 8 - RRSIGs missing 280 The resolver attempted to perform DNSSEC validation, but no RRSIGs 281 could be found for at least one RRset where RRSIGs were expected. 283 4.1.9. Extended DNS Error Code 9 - No Zone Key Bit Set 285 The resolver attempted to perform DNSSEC validation, but no Zone Key 286 Bit was set in a DNSKEY. 288 4.2. REFUSED(5) extended information codes 290 4.2.1. Extended DNS Error Code 1 - Lame 292 An authoritative resolver that receives a query (with the RD bit 293 clear) for a domain for which it is not authoritative SHOULD include 294 this EDE code in the REFUSED response. Implementations should set 295 the R flag in this case (another nameserver might not be lame). 297 4.2.2. Extended DNS Error Code 2 - Prohibited 299 An authoritative or recursive resolver that receives a query from an 300 "unauthorized" client can annotate its REFUSED message with this 301 code. Examples of "unauthorized" clients are recursive queries from 302 IP addresses outside the network, blacklisted IP addresses, local 303 policy, etc. 305 Implementations SHOULD allow operators to define what to set the R 306 flag to in this case. 308 5. IANA Considerations 310 [This section under construction, beware. ] 312 5.1. new Extended Error Code EDNS Option 314 This document defines a new EDNS(0) option, entitled "Extended DNS 315 Error", assigned a value of TBD1 from the "DNS EDNS0 Option Codes 316 (OPT)" registry [to be removed upon publication: 317 [http://www.iana.org/assignments/dns-parameters/dns- 318 parameters.xhtml#dns-parameters-11] 320 Value Name Status Reference 321 ----- ---------------- ------ ------------------ 322 TBD Extended DNS Error TBD [ This document ] 324 5.2. new Extended Error Code EDNS Option 326 This document defines a new double-index IANA registry table, where 327 the first index value is the RCODE value and the second index value 328 is the INFO-CODE from the Extended DNS Error EDNS option defined in 329 this document. The IANA is requested to create and maintain this 330 "Extended DNS Error codes" registry. The codepoint space for each 331 RCODE index is to be broken into 3 ranges: 333 o 1 - 16384: Specification required. 335 o 16385 - 65000: First Come First Served 337 o 65000 - 65534: Experimental / Private use 339 The codepoints 0, 65535 are reserved. 341 A starting table, based on the contents of this document, is as 342 follows: 344 | RCODE | EDE-INFO-CODE | Meaning | Ref | 345 |-------------+-------------------------+---------------------------------------------+------------------------------------------| 346 | SERVFAIL(2) | DNSSEC_BOGUS(1) | DNSSEC Validation resulted in Bogus | section | 347 | SERVFAIL(2) | DNSSEC_INDETERMINATE(2) | DNSSEC Validation resulted in Indeterminate | section | 349 [incomplete] 351 6. Open questions 353 1 Can this be included in *any* response or only responses to 354 requests that included an EDNS option? Resolvers are supposed to 355 ignore additional. EDNS capable ones are supposed to simply 356 ignore unknown options. I know the spec says you can only include 357 EDNS0 in a response if in a request -- it is time to reevaluate 358 this? 360 2 Can this be applied to *any* response, or only error responses? 362 3 Should textual information be allowed as well? What if the only 363 thing allowed is a domain name, e.g to point at where validation 364 began failing? 366 7. Security Considerations 368 DNSSEC is being deployed - unfortunately a significant number of 369 clients (~11% according to [GeoffValidation]), when receiving a 370 SERVFAIL from a validating resolver because of a DNSSEC validaion 371 issue simply ask the next (non-validating) resolver in their list, 372 and don't get any of the protections which DNSSEC should provide. 373 This is very similar to a kid asking his mother if he can have 374 another cookie. When the mother says "No, it will ruin your 375 dinner!", going off and asking his (more permissive) father and 376 getting a "Yes, sure, cookie!". 378 8. Acknowledgements 380 The authors wish to thank Geoff Huston and Bob Harold, Carlos M. 381 Martinez, Peter DeVries, George Michelson, Mark Andrews, Ondrej Sury, 382 Edward Lewis, Paul Vixie, Shane Kerr. They also vaguely remember 383 discussing this with a number of people over the years, but have 384 forgotten who all they were -- if you were one of them, and are not 385 listed, please let us know and we'll acknowledge you. 387 I also want to thank the band "Infected Mushroom" for providing a 388 good background soundtrack (and to see if I can get away with this!) 389 Another author would like to thank the band "Mushroom Infectors". 390 This was funny at the time we wrote it, but I cannot remember why... 392 We would like to especially thank Peter van Dijk, who sent GitHub 393 pull requests. 395 9. References 397 9.1. Normative References 399 [IANA.AS_Numbers] 400 IANA, "Autonomous System (AS) Numbers", 401 . 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, 405 DOI 10.17487/RFC2119, March 1997, 406 . 408 9.2. Informative References 410 [GeoffValidation] 411 IANA, "A quick review of DNSSEC Validation in today's 412 Internet", June 2016, . 415 [I-D.ietf-sidr-iana-objects] 416 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 417 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 418 progress), May 2011. 420 Appendix A. Changes / Author Notes. 422 [RFC Editor: Please remove this section before publication ] 424 From -00 to -01: 426 o Address comments from IETF meeting. 428 o document copying the response code 430 o mention zero length fields are ok 432 o clarify lookup procedure 434 o mention that table isn't done 436 From -03 to -IETF 00: 438 o Renamed to draft-ietf-dnsop-extended-error 440 From -02 to -03: 442 o Added David Lawrence -- I somehow missed that in last version. 444 From -00 to -01; 446 o Fixed up some of the text, minor clarifications. 448 Authors' Addresses 450 Warren Kumari 451 Google 452 1600 Amphitheatre Parkway 453 Mountain View, CA 94043 454 US 456 Email: warren@kumari.net 458 Evan Hunt 459 ISC 460 950 Charter St 461 Redwood City, CA 94063 462 US 464 Email: each@isc.org 465 Roy Arends 466 ICANN 468 Email: roy.arends@icann.org 470 Wes Hardaker 471 USC/ISI 472 P.O. Box 382 473 Davis, VA 95617 474 US 476 Email: ietf@hardakers.net 478 David C Lawrence 479 Akamai Technologies 480 150 Broadway 481 Cambridge, MA 02142-1054 482 US 484 Email: tale@akamai.com