idnits 2.17.1 draft-ietf-dnsop-extended-error-06.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 (July 08, 2019) is 1755 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) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 9, 2020 ISC 6 R. Arends 7 ICANN 8 W. Hardaker 9 USC/ISI 10 D. Lawrence 11 Oracle + Dyn 12 July 08, 2019 14 Extended DNS Errors 15 draft-ietf-dnsop-extended-error-06 17 Abstract 19 This document defines an extensible method to return additional 20 information about the cause of DNS errors. Though created primarily 21 to extend SERVFAIL to provide additional information about the cause 22 of DNS and DNSSEC failures, the Extended DNS Errors option defined in 23 this document allows all response types to contain extended error 24 information. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 9, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction and background . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 62 2. Extended Error EDNS0 option format . . . . . . . . . . . . . 4 63 3. Use of the Extended DNS Error option . . . . . . . . . . . . 5 64 3.1. The R (Retry) flag . . . . . . . . . . . . . . . . . . . 5 65 3.2. The RESPONSE-CODE field . . . . . . . . . . . . . . . . . 5 66 3.3. The INFO-CODE field . . . . . . . . . . . . . . . . . . . 6 67 3.4. The EXTRA-TEXT field . . . . . . . . . . . . . . . . . . 6 68 4. Defined Extended DNS Errors . . . . . . . . . . . . . . . . . 6 69 4.1. INFO-CODEs for use with RESPONSE-CODE: NOERROR(0) . . . . 6 70 4.1.1. NOERROR Extended DNS Error Code 1 - Unsupported 71 DNSKEY Algorithm . . . . . . . . . . . . . . . . . . 6 72 4.1.2. NOERROR Extended DNS Error Code 2 - Unsupported 73 DS Algorithm . . . . . . . . . . . . . . . . . . . . 6 74 4.1.3. INFO-CODEs for use with RESPONSE-CODE: NOERROR(3) . . 7 75 4.1.4. NOERROR Extended DNS Error Code 4 - Forged answer . . 7 76 4.1.5. SERVFAIL Extended DNS Error Code 5 - DNSSEC 77 Indeterminate . . . . . . . . . . . . . . . . . . . . 7 78 4.2. INFO-CODEs for use with RESPONSE-CODE: SERVFAIL(2) . . . 7 79 4.2.1. SERVFAIL Extended DNS Error Code 1 - DNSSEC Bogus . . 7 80 4.2.2. SERVFAIL Extended DNS Error Code 2 - Signature 81 Expired . . . . . . . . . . . . . . . . . . . . . . . 7 82 4.2.3. SERVFAIL Extended DNS Error Code 3 - Signature Not 83 Yet Valid . . . . . . . . . . . . . . . . . . . . . . 7 84 4.2.4. SERVFAIL Extended DNS Error Code 4 - DNSKEY missing . 7 85 4.2.5. SERVFAIL Extended DNS Error Code 5 - RRSIGs missing . 8 86 4.2.6. SERVFAIL Extended DNS Error Code 6 - No Zone Key Bit 87 Set . . . . . . . . . . . . . . . . . . . . . . . . . 8 88 4.2.7. SERVFAIL Extended DNS Error Code 7 - No 89 Reachable Authority . . . . . . . . . . . . . . . . . 8 90 4.2.8. SERVFAIL Extended DNS Error Code 8 - NSEC Missing . . 8 91 4.2.9. SERVFAIL Extended DNS Error Code 9 - Cached Error . . 8 92 4.2.10. SERVFAIL Extended DNS Error Code 10 - Not Ready . . . 8 93 4.3. INFO-CODEs for use with RESPONSE-CODE: NOTIMP(4) . . . . 8 94 4.3.1. NOTIMP Extended DNS Error Code 1 - Deprecated . . . . 8 95 4.4. INFO-CODEs for use with RESPONSE-CODE: REFUSED(5) . . . . 8 96 4.4.1. REFUSED Extended DNS Error Code 1 - Lame . . . . . . 8 97 4.4.2. REFUSED Extended DNS Error Code 2 - Prohibited . . . 9 98 4.5. INFO-CODEs for use with RESPONSE-CODE: NXDOMAIN(3) . . . 9 99 4.5.1. NXDOMAIN Extended DNS Error Code 1 - Blocked . . . . 9 100 4.6. INFO-CODEs for use with RESPONSE-CODE: NXDOMAIN(3) . . . 9 101 4.6.1. NXDOMAIN Extended DNS Error Code 2 - Censored . . . . 9 102 4.7. INFO-CODEs for use with RESPONSE-CODE: NXDOMAIN(3) . . . 9 103 4.7.1. NXDOMAIN Extended DNS Error Code 3 - Stale Answer . . 9 104 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 105 5.1. A New Extended Error Code EDNS Option . . . . . . . . . . 10 106 5.2. New Double-Index Registry Table for Extended Error Codes 10 107 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 108 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 110 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 111 8.2. Informative References . . . . . . . . . . . . . . . . . 14 112 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 14 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 115 1. Introduction and background 117 There are many reasons that a DNS query may fail, some of them 118 transient, some permanent; some can be resolved by querying another 119 server, some are likely best handled by stopping resolution. 120 Unfortunately, the error signals that a DNS server can return are 121 very limited, and are not very expressive. This means that 122 applications and resolvers often have to "guess" at what the issue is 123 - e.g. was the answer marked REFUSED because of a lame delegation, or 124 because the nameserver is still starting up and loading zones? Is a 125 SERVFAIL a DNSSEC validation issue, or is the nameserver experiencing 126 a bad hair day? 128 A good example of issues that would benefit by additional error 129 information are errors caused by DNSSEC validation issues. When a 130 stub resolver queries a DNSSEC bogus name (using a validating 131 resolver), the stub resolver receives only a SERVFAIL in response. 132 Unfortunately, SERVFAIL is used to signal many sorts of DNS errors, 133 and so the stub resolver simply asks the next configured DNS 134 resolver. The result of trying the next resolver is one of two 135 outcomes: either the next resolver also validates, a SERVFAIL is 136 returned again, and the user gets an (largely) incomprehensible error 137 message; or the next resolver is not a validating resolver, and the 138 user is returned a potentially harmful result. 140 This document specifies a mechanism to extend (or annotate) DNS 141 errors to provide additional information about the cause of the 142 error. When properly authenticated, this information can be used by 143 the resolver to make a decision regarding whether or not to retry or 144 it can be used or by technical users attempting to debug issues. 146 These extended error codes are specially useful when received by 147 resolvers, to return to stub resolvers or to downstream resolvers. 148 Authoritative servers MAY parse and use them, but most error codes 149 would make no sense for them. Authoritative servers may need to 150 generate extended error codes though. 152 1.1. Requirements notation 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 2. Extended Error EDNS0 option format 160 This draft uses an EDNS0 ([RFC2671]) option to include Extended DNS 161 Error (EDE) information in DNS messages. The option is structured as 162 follows: 164 1 1 1 1 1 1 165 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 166 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 167 0: | OPTION-CODE | 168 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 169 2: | OPTION-LENGTH | 170 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 171 4: | RCODE | R | Res | 172 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 173 6: | INFO-CODE | 174 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 175 6: / EXTRA-TEXT ... / 176 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 178 Field definition details: 180 o OPTION-CODE, 2 octets (defined in [RFC6891]), for EDE is TBD. 181 [RFC Editor: change TBD to the proper code once assigned by IANA.] 182 o OPTION-LENGTH, 2 octets ((defined in [RFC6891]) contains the 183 length of the payload (everything after OPTION-LENGTH) in octets 184 and should be 4 plus the length of the EXTRA-TEXT section (which 185 may be a zero-length string). 186 o The RETRY flag, 1 bit; the RETRY bit (R) indicates a flag defined 187 for use in this specification. 188 o The RESERVED bits, 4 bits: these bits are reserved for future use, 189 potentially as additional flags. The RESERVED bits MUST be set to 190 0 by the sender and MUST be ignored by the receiver. 192 o RESPONSE-CODE, 12 bits: the concatenation of the upper 8-bits of 193 the RCODE (stored in the TTL field of the EDNS0 resource record 194 [RFC2671]) and the 4 bits of the RCODE field of the DNS message. 195 o INFO-CODE, 16-bits, which is the principal contribution of this 196 document. 197 o EXTRA-TEXT, a variable length, UTF-8 encoded, text field that may 198 hold additional textual information. Note: EXTRA-TEXT may be zero 199 octets in length, indicating there is no EXTRA-TEXT included. 201 3. Use of the Extended DNS Error option 203 The Extended DNS Error (EDE) is an EDNS option. It can be included 204 in any response (SERVFAIL, NXDOMAIN, REFUSED, etc) to a query that 205 includes OPT Pseudo-RR [RFC6891]. This document includes a set of 206 initial codepoints (and requests to the IANA to add them to the 207 registry), but is extensible via the IANA registry to allow 208 additional error and information codes to be defined in the future. 210 The fields of the Extended DNS Error option are defined further in 211 the following sub-sections. 213 3.1. The R (Retry) flag 215 The R (Retry) flag provides a hint as to what the receiver may want 216 to do with this annotated error. Specifically, the R (or Retry) flag 217 provides a hint to the receiver that it should retry the query to 218 another server. If the R bit is set (1), the sender believes that 219 retrying the query may provide a successful answer next time; if the 220 R bit is clear (0), the sender believes that the resolver should not 221 ask another server. 223 The mechanism is specifically designed to be extensible, and so 224 implementations may receive EDE codes that it does not understand. 225 The R flag allows implementations to make a decision as to what to do 226 if it receives a response with an unknown code - retry or drop the 227 query. Note that this flag is only a suggestion. Unless a 228 protective transport mechanism (like TSIG [RFC2845] or (D)TLS xref 229 target="RFC7858"/>, [RFC8094]) is used, the bit's value could have 230 have been altered by a person-in-the-middle. Receivers can choose to 231 ignore this hint. See the security considerations for additional 232 considerations. 234 3.2. The RESPONSE-CODE field 236 This 12-bit value SHOULD be a copy of the combined RCODE from the 237 extended RCODE field defined in the EDNS0 optional resource record 238 (stored in the TTL field of the EDNS0 resource record [RFC2671]) and 239 the 4 bits of the RCODE field of the DNS message. RESPONSE-CODEs MAY 240 use a different RCODE to provide additional or better information. 241 For example, multiple EDNS0/EDE records may be included in the 242 response and the supplemental EDNS0/EDE records may wish to include 243 other RESPONSE-CODE values based on communication results with other 244 DNS servers. 246 3.3. The INFO-CODE field 248 This 16-bit value provides the additional context for the RESPONSE- 249 CODE value. This combination of the RESPONSE-CODE and the INFO-CODE 250 serve as a joint-index into the IANA "Extended DNS Errors" registry. 252 Note to implementers: the combination of the RESPONSE-CODE and INFO- 253 CODE fits within a 24-bit field, allowing implementers the choice of 254 treating the combination as either two separate values, as defined in 255 this document, or as a single 24-bit integer as long as the results 256 are deterministic. 258 3.4. The EXTRA-TEXT field 260 The UTF-8-encoded, EXTRA-TEXT field may be zero-length, or may hold 261 additional information useful to network operators. 263 4. Defined Extended DNS Errors 265 This document defines some initial EDE codes. The mechanism is 266 intended to be extensible, and additional code-points can be 267 registered in the "Extended DNS Errors" registry. This document 268 provides suggestions for the R flag, but the originating server may 269 ignore these recommendations if it knows better. 271 The RESPONSE-CODE and the INFO-CODE from the EDE EDNS option is used 272 to serve as a double index into the "Extended DNS Error codes" IANA 273 registry, the initial values for which are defined in the following 274 sub-sections. 276 4.1. INFO-CODEs for use with RESPONSE-CODE: NOERROR(0) 278 4.1.1. NOERROR Extended DNS Error Code 1 - Unsupported DNSKEY Algorithm 280 The resolver attempted to perform DNSSEC validation, but a DNSKEY 281 RRSET contained only unknown algorithms. The R flag should be set. 283 4.1.2. NOERROR Extended DNS Error Code 2 - Unsupported DS Algorithm 285 The resolver attempted to perform DNSSEC validation, but a DS RRSET 286 contained only unknown algorithms. The R flag should be set. 288 4.1.3. INFO-CODEs for use with RESPONSE-CODE: NOERROR(3) 290 4.1.3.1. NOERROR Extended DNS Error Code 3 - Stale Answer 292 The resolver was unable to resolve answer within its time limits and 293 decided to answer with a previously cached data instead of answering 294 with an error. This is typically caused by problems on authoritative 295 side, possibly as result of a DoS attack. The R flag should not be 296 set, since retrying is likely to create additional load without 297 yielding a more fresh answer. 299 4.1.4. NOERROR Extended DNS Error Code 4 - Forged answer 301 For policy reasons (legal obligation, or malware filtering, for 302 instance), an answer was forged. The R flag should not be set. 304 4.1.5. SERVFAIL Extended DNS Error Code 5 - DNSSEC Indeterminate 306 The resolver attempted to perform DNSSEC validation, but validation 307 ended in the Indeterminate state. The R flag should not be set. 309 4.2. INFO-CODEs for use with RESPONSE-CODE: SERVFAIL(2) 311 4.2.1. SERVFAIL Extended DNS Error Code 1 - DNSSEC Bogus 313 The resolver attempted to perform DNSSEC validation, but validation 314 ended in the Bogus state. The R flag should not be set. 316 4.2.2. SERVFAIL Extended DNS Error Code 2 - Signature Expired 318 The resolver attempted to perform DNSSEC validation, a signature in 319 the validation chain was expired. The R flag should not be set. 321 4.2.3. SERVFAIL Extended DNS Error Code 3 - Signature Not Yet Valid 323 The resolver attempted to perform DNSSEC validation, but the 324 signatures received were not yet valid. The R flag should not be 325 set. 327 4.2.4. SERVFAIL Extended DNS Error Code 4 - DNSKEY missing 329 A DS record existed at a parent, but no supported matching DNSKEY 330 record could be found for the child. The R flag should not be set. 332 4.2.5. SERVFAIL Extended DNS Error Code 5 - RRSIGs missing 334 The resolver attempted to perform DNSSEC validation, but no RRSIGs 335 could be found for at least one RRset where RRSIGs were expected. 337 4.2.6. SERVFAIL Extended DNS Error Code 6 - No Zone Key Bit Set 339 The resolver attempted to perform DNSSEC validation, but no Zone Key 340 Bit was set in a DNSKEY. 342 4.2.7. SERVFAIL Extended DNS Error Code 7 - No Reachable Authority 344 The resolver could not reach any of the authoritative name servers 345 (or they refused to reply). The R flag should be set. 347 4.2.8. SERVFAIL Extended DNS Error Code 8 - NSEC Missing 349 The resolver attempted to perform DNSSEC validation, but the 350 requested data was missing and a covering NSEC or NSEC3 was not 351 provided. The R flag should be set. 353 4.2.9. SERVFAIL Extended DNS Error Code 9 - Cached Error 355 The resolver has cached SERVFAIL for this query without additional 356 information. Th R flag should be set. 358 4.2.10. SERVFAIL Extended DNS Error Code 10 - Not Ready 360 The server is unable to answer the query as it is not fully up and 361 functional yet. 363 4.3. INFO-CODEs for use with RESPONSE-CODE: NOTIMP(4) 365 4.3.1. NOTIMP Extended DNS Error Code 1 - Deprecated 367 The requested operation or query is not supported as its use has been 368 deprecated. Implementations should not set the R flag. (Retrying 369 request elsewhere is unlikely to yield any other results.) 371 4.4. INFO-CODEs for use with RESPONSE-CODE: REFUSED(5) 373 4.4.1. REFUSED Extended DNS Error Code 1 - Lame 375 An authoritative server that receives a query (with the RD bit clear) 376 for a domain for which it is not authoritative SHOULD include this 377 EDE code in the SERVFAIL response. A resolver that receives a query 378 (with the RD bit clear) SHOULD include this EDE code in the REFUSED 379 response. Implementations should set the R flag in this case 380 (another nameserver or resolver might not be lame). 382 4.4.2. REFUSED Extended DNS Error Code 2 - Prohibited 384 An authoritative or recursive resolver that receives a query from an 385 "unauthorized" client can annotate its REFUSED message with this 386 code. Examples of "unauthorized" clients are recursive queries from 387 IP addresses outside the network, blacklisted IP addresses, local 388 policy, etc. 390 Implementations SHOULD allow operators to define what to set the R 391 flag to in this case. 393 4.5. INFO-CODEs for use with RESPONSE-CODE: NXDOMAIN(3) 395 4.5.1. NXDOMAIN Extended DNS Error Code 1 - Blocked 397 The resolver attempted to perfom a DNS query but the domain is 398 blacklisted due to a security policy implemented on the server being 399 directly talked to. The R flag should be set. 401 4.6. INFO-CODEs for use with RESPONSE-CODE: NXDOMAIN(3) 403 4.6.1. NXDOMAIN Extended DNS Error Code 2 - Censored 405 The resolver attempted to perfom a DNS query but the domain was 406 blacklisted by a security policy imposed upon the server being talked 407 to. Note that how the imposed policy is applied is irrelevant (in- 408 band DNS somehow, court order, etc). The R flag should be set. 410 4.7. INFO-CODEs for use with RESPONSE-CODE: NXDOMAIN(3) 412 4.7.1. NXDOMAIN Extended DNS Error Code 3 - Stale Answer 414 The resolver was unable to resolve answer within its time limits and 415 decided to answer with a previously cached NXDOMAIN answer instead of 416 answering with an error. This is typically caused by problems on 417 authoritative side, possibly as result of a DoS attack. The R flag 418 should not be set, since retrying is likely to create additional load 419 without yielding a more fresh answer. 421 5. IANA Considerations 422 5.1. A New Extended Error Code EDNS Option 424 This document defines a new EDNS(0) option, entitled "Extended DNS 425 Error", assigned a value of TBD1 from the "DNS EDNS0 Option Codes 426 (OPT)" registry [to be removed upon publication: 427 [http://www.iana.org/assignments/dns-parameters/dns- 428 parameters.xhtml#dns-parameters-11] 430 Value Name Status Reference 431 ----- ---------------- ------ ------------------ 432 TBD Extended DNS Error TBD [ This document ] 434 5.2. New Double-Index Registry Table for Extended Error Codes 436 This document defines a new double-index IANA registry table, where 437 the first index value is the combined RCODE value (see the 438 Section 3.2 section) and the second index value is the INFO-CODE from 439 the Extended DNS Error EDNS option defined in this document. The 440 IANA is requested to create and maintain this "Extended DNS Error 441 codes" registry. The codepoint space for each INFO-CODE index is to 442 be broken into 3 ranges: 444 o 0 - 65023: Specification required. 445 o 65023 - 65279: First come, first served. 446 o 65280 - 65536: Experimental / Private use 448 A starting set of entries, based on the contents of this document, is 449 as follows: 451 RESPONSE-CODE: 0 (NOERROR) 452 INFO-CODE: 1 453 Purpose: Unsupported DNSKEY 454 Reference: Section 4.1.1 456 RESPONSE-CODE: 0 (NOERROR) 457 INFO-CODE: 2 458 Purpose: Unsupported DS Algorithm 459 Reference: Section 4.1.2 461 RESPONSE-CODE: 3 (NOERROR) 462 INFO-CODE: 3 463 Purpose: Answering with stale/cached data 464 Reference: Section 4.1.3.1 466 RESPONSE-CODE: 0 (NOERROR) 467 INFO-CODE: 4 468 Purpose: Forged answer 469 Reference: Section 4.1.4 470 RESPONSE-CODE: 0 (NOERROR) 471 INFO-CODE: 5 472 Purpose: DNSSEC Indeterminate 473 Reference: Section 4.1.5 475 RESPONSE-CODE: 2 (SERVFAIL) 476 INFO-CODE: 1 477 Purpose: DNSSEC Bogus 478 Reference: Section 4.2.1 480 RESPONSE-CODE: 2 (SERVFAIL) 481 INFO-CODE: 2 482 Purpose: Signature Expired 483 Reference: Section 4.2.2 485 RESPONSE-CODE: 2 (SERVFAIL) 486 INFO-CODE: 3 487 Purpose: Signature Not Yet Valid 488 Reference: Section 4.2.3 490 RESPONSE-CODE: 2 (SERVFAIL) 491 INFO-CODE: 4 492 Purpose: DNSKEY missing 493 Reference: Section 4.2.4 495 RESPONSE-CODE: 2 (SERVFAIL) 496 INFO-CODE: 5 497 Purpose: RRSIGs missing 498 Reference: Section 4.2.5 500 RESPONSE-CODE: 2 (SERVFAIL) 501 INFO-CODE: 6 502 Purpose: No Zone Key Bit Set 503 Reference: Section 4.2.6 505 RESPONSE-CODE: 2 (SERVFAIL) 506 INFO-CODE: 7 507 Purpose: No NSEC records could be obtained 508 Reference: Section 4.2.8 510 RESPONSE-CODE: 2 (SERVFAIL) 511 INFO-CODE: 9 512 Purpose: The SERVFAIL error comes from the cache 513 Reference: Section 4.2.9 515 RESPONSE-CODE: 2 (SERVFAIL) 516 INFO-CODE: 10 517 Purpose: Not Ready. 519 Reference: Section 4.2.10 521 RESPONSE-CODE: 3 (NXDOMAIN) 522 INFO-CODE: 1 523 Purpose: Blocked 524 Reference: Section 4.5.1 526 RESPONSE-CODE: 3 (NXDOMAIN) 527 INFO-CODE: 2 528 Purpose: Censored 529 Reference: Section 4.6.1 531 RESPONSE-CODE: 3 (NXDOMAIN) 532 INFO-CODE: 3 533 Purpose: Answering with stale/cached NXDOMAIN data 534 Reference: Section 4.7.1 536 RESPONSE-CODE: 4 (NOTIMP) 537 INFO-CODE: 1 538 Purpose: 539 Reference: Section 4.4.2 541 RESPONSE-CODE: 5 (REFUSED) 542 INFO-CODE: 1 543 Purpose: Lame 544 Reference: Section 4.4.1 546 RESPONSE-CODE: 5 (REFUSED) 547 INFO-CODE: 2 548 Purpose: Prohibited 549 Reference: Section 4.4.2 551 6. Security Considerations 553 Though DNSSEC continues to be deployed, unfortunately a significant 554 number of clients (~11% according to [GeoffValidation]) that receive 555 a SERVFAIL from a validating resolver because of a DNSSEC validaion 556 issue will simply ask the next (potentially non-validating) resolver 557 in their list, and thus don't get any of the protections which DNSSEC 558 should provide. This is very similar to a kid asking his mother if 559 he can have another cookie. When the mother says "No, it will ruin 560 your dinner!", going off and asking his (more permissive) father and 561 getting a "Yes, sure, have a cookie!". 563 This information is unauthenticated information, and an attacker (e.g 564 MITM or malicious recursive server) could insert an extended error 565 response into already untrusted data -- ideally clients and resolvers 566 would not trust any unauthenticated information, but until we live in 567 an era where all DNS answers are authenticated via DNSSEC or other 568 mechanisms, there are some tradeoffs. As an example, an attacker who 569 is able to insert the DNSSEC Bogus Extended Error into a packet could 570 instead simply reply with a fictitious address (A or AAAA) record. 571 The R bit hint and extended error information are informational - 572 implementations can choose how much to trust this information and 573 validating resolvers / stubs may choose to put a different weight on 574 it. 576 7. Acknowledgements 578 The authors wish to thank Joe Abley, Mark Andrews, Stephane 579 Bortzmeyer, Vladimir Cunat, Peter DeVries, Peter van Dijk, Donald 580 Eastlake, Bob Harold, Evan Hunt, Geoff Huston, Shane Kerr, Edward 581 Lewis, Carlos M. Martinez, George Michelson, Michael Sheldon, Petr 582 Spacek, Ondrej Sury, Loganaden Velvindron, and Paul Vixie. They also 583 vaguely remember discussing this with a number of people over the 584 years, but have forgotten who all they were -- if you were one of 585 them, and are not listed, please let us know and we'll acknowledge 586 you. 588 I also want to thank the band "Infected Mushroom" for providing a 589 good background soundtrack (and to see if I can get away with this!) 590 Another author would like to thank the band "Mushroom Infectors". 591 This was funny at the time we wrote it, but I cannot remember why... 593 8. References 595 8.1. Normative References 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, 599 DOI 10.17487/RFC2119, March 1997, . 602 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 603 RFC 2671, DOI 10.17487/RFC2671, August 1999, 604 . 606 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 607 for DNS (EDNS(0))", STD 75, RFC 6891, 608 DOI 10.17487/RFC6891, April 2013, . 611 8.2. Informative References 613 [GeoffValidation] 614 IANA, "A quick review of DNSSEC Validation in today's 615 Internet", June 2016, . 618 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 619 Wellington, "Secret Key Transaction Authentication for DNS 620 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 621 . 623 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 624 Transport Layer Security (DTLS)", RFC 8094, 625 DOI 10.17487/RFC8094, February 2017, . 628 Appendix A. Changes / Author Notes. 630 [RFC Editor: Please remove this section before publication ] 632 From -00 to -01: 634 o Address comments from IETF meeting. 635 o document copying the response code 636 o mention zero length fields are ok 637 o clarify lookup procedure 638 o mention that table isn't done 640 From -03 to -IETF 00: 642 o Renamed to draft-ietf-dnsop-extended-error 644 From -02 to -03: 646 o Added David Lawrence -- I somehow missed that in last version. 648 From -00 to -01; 650 o Fixed up some of the text, minor clarifications. 652 Authors' Addresses 653 Warren Kumari 654 Google 655 1600 Amphitheatre Parkway 656 Mountain View, CA 94043 657 US 659 Email: warren@kumari.net 661 Evan Hunt 662 ISC 663 950 Charter St 664 Redwood City, CA 94063 665 US 667 Email: each@isc.org 669 Roy Arends 670 ICANN 672 Email: roy.arends@icann.org 674 Wes Hardaker 675 USC/ISI 676 P.O. Box 382 677 Davis, CA 95617 678 US 680 Email: ietf@hardakers.net 682 David C Lawrence 683 Oracle + Dyn 684 150 Dow St 685 Manchester, NH 03101 686 US 688 Email: tale@dd.org