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