idnits 2.17.1 draft-ietf-dnsop-extended-error-05.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 (March 11, 2019) is 1867 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 160, but not defined ** Obsolete undefined reference: RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: September 12, 2019 ISC 6 R. Arends 7 ICANN 8 W. Hardaker 9 USC/ISI 10 D. Lawrence 11 Oracle + Dyn 12 March 11, 2019 14 Extended DNS Errors 15 draft-ietf-dnsop-extended-error-05 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 September 12, 2019. 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) . . 6 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 . 7 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 . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 13 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: | R | RESERVED | 172 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 173 6: | RESPONSE-CODE | INFO-CODE | 174 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 175 8: | 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, 15 bits: these bits are reserved for future 189 use, potentially as additional flags. The RESERVED bits MUST be 190 set to 0 by the sender and MUST be ignored by the receiver. 192 o RESPONSE-CODE, 4 bits. 193 o INFO-CODE, 12-bits. 194 o EXTRA-TEXT, a variable length, UTF-8 encoded, text field that may 195 hold additional textual information. 197 3. Use of the Extended DNS Error option 199 The Extended DNS Error (EDE) is an EDNS option. It can be included 200 in any response (SERVFAIL, NXDOMAIN, REFUSED, etc) to a query that 201 includes OPT Pseudo-RR [RFC6891]. This document includes a set of 202 initial codepoints (and requests to the IANA to add them to the 203 registry), but is extensible via the IANA registry to allow 204 additional error and information codes to be defined in the future. 206 The fields of the Extended DNS Error option are defined further in 207 the following sub-sections. 209 3.1. The R (Retry) flag 211 The R (Retry) flag provides a hint as to what the receiver may want 212 to do with this annotated error. Specifically, the R (or Retry) flag 213 provides a hint to the receiver that it should retry the query to 214 another server. If the R bit is set (1), the sender believes that 215 retrying the query may provide a successful answer next time; if the 216 R bit is clear (0), the sender believes that the resolver should not 217 ask another server. 219 The mechanism is specifically designed to be extensible, and so 220 implementations may receive EDE codes that it does not understand. 221 The R flag allows implementations to make a decision as to what to do 222 if it receives a response with an unknown code - retry or drop the 223 query. Note that this flag is only a suggestion. Unless a 224 protective transport mechanism (like TSIG [RFC2845] or (D)TLS xref 225 target="RFC7858"/>, [RFC8094]) is used, the bit's value could have 226 have been altered by a person-in-the-middle. Receivers can choose to 227 ignore this hint. See the security considerations for additional 228 considerations. 230 3.2. The RESPONSE-CODE field 232 This 4-bit value SHOULD be a copy of the RCODE from the primary DNS 233 packet. RESPONSE-CODEs MAY use a different RCODE to provide 234 additional or better information. For example, multiple EDNS0/EDE 235 records may be included in the response and the supplemental EDNS0/ 236 EDE records may wish to include other RESPONSE-CODE values based on 237 communication results with other DNS servers. 239 3.3. The INFO-CODE field 241 This 12-bit value provides the additional context for the RESPONSE- 242 CODE value. This combination of the RESPONSE-CODE and the INFO-CODE 243 serve as a joint-index into the IANA "Extended DNS Errors" registry. 245 Note to implementers: the combination of the RESPONSE-CODE and INFO- 246 CODE fits within a 16-bit field, allowing implementers the choice of 247 treating the combination as either two separate values, as defined in 248 this document, or as a single 16-bit integer as long as the results 249 are deterministic. 251 3.4. The EXTRA-TEXT field 253 The UTF-8-encoded, EXTRA-TEXT field may be zero-length, or may hold 254 additional information useful to network operators. 256 4. Defined Extended DNS Errors 258 This document defines some initial EDE codes. The mechanism is 259 intended to be extensible, and additional code-points can be 260 registered in the "Extended DNS Errors" registry. This document 261 provides suggestions for the R flag, but the originating server may 262 ignore these recommendations if it knows better. 264 The RESPONSE-CODE and the INFO-CODE from the EDE EDNS option is used 265 to serve as a double index into the "Extended DNS Error codes" IANA 266 registry, the initial values for which are defined in the following 267 sub-sections. 269 4.1. INFO-CODEs for use with RESPONSE-CODE: NOERROR(0) 271 4.1.1. NOERROR Extended DNS Error Code 1 - Unsupported DNSKEY Algorithm 273 The resolver attempted to perform DNSSEC validation, but a DNSKEY 274 RRSET contained only unknown algorithms. The R flag should be set. 276 4.1.2. NOERROR Extended DNS Error Code 2 - Unsupported DS Algorithm 278 The resolver attempted to perform DNSSEC validation, but a DS RRSET 279 contained only unknown algorithms. The R flag should be set. 281 4.1.3. INFO-CODEs for use with RESPONSE-CODE: NOERROR(3) 282 4.1.3.1. NOERROR Extended DNS Error Code 3 - Stale Answer 284 The resolver was unable to resolve answer within its time limits and 285 decided to answer with a previously cached data instead of answering 286 with an error. This is typically caused by problems on authoritative 287 side, possibly as result of a DoS attack. The R flag should not be 288 set, since retrying is likely to create additional load without 289 yielding a more fresh answer. 291 4.1.4. NOERROR Extended DNS Error Code 4 - Forged answer 293 For policy reasons (legal obligation, or malware filtering, for 294 instance), an answer was forged. The R flag should not be set. 296 4.1.5. SERVFAIL Extended DNS Error Code 5 - DNSSEC Indeterminate 298 The resolver attempted to perform DNSSEC validation, but validation 299 ended in the Indeterminate state. The R flag should not be set. 301 4.2. INFO-CODEs for use with RESPONSE-CODE: SERVFAIL(2) 303 4.2.1. SERVFAIL Extended DNS Error Code 1 - DNSSEC Bogus 305 The resolver attempted to perform DNSSEC validation, but validation 306 ended in the Bogus state. The R flag should not be set. 308 4.2.2. SERVFAIL Extended DNS Error Code 2 - Signature Expired 310 The resolver attempted to perform DNSSEC validation, a signature in 311 the validation chain was expired. The R flag should not be set. 313 4.2.3. SERVFAIL Extended DNS Error Code 3 - Signature Not Yet Valid 315 The resolver attempted to perform DNSSEC validation, but the 316 signatures received were not yet valid. The R flag should not be 317 set. 319 4.2.4. SERVFAIL Extended DNS Error Code 4 - DNSKEY missing 321 A DS record existed at a parent, but no supported matching DNSKEY 322 record could be found for the child. The R flag should not be set. 324 4.2.5. SERVFAIL Extended DNS Error Code 5 - RRSIGs missing 326 The resolver attempted to perform DNSSEC validation, but no RRSIGs 327 could be found for at least one RRset where RRSIGs were expected. 329 4.2.6. SERVFAIL Extended DNS Error Code 6 - No Zone Key Bit Set 331 The resolver attempted to perform DNSSEC validation, but no Zone Key 332 Bit was set in a DNSKEY. 334 4.2.7. SERVFAIL Extended DNS Error Code 7 - No Reachable Authority 336 The resolver could not reach any of the authoritative name servers 337 (or they refused to reply). The R flag should be set. 339 4.2.8. SERVFAIL Extended DNS Error Code 8 - NSEC Missing 341 The resolver attempted to perform DNSSEC validation, but the 342 requested data was missing and a covering NSEC or NSEC3 was not 343 provided. The R flag should be set. 345 4.2.9. SERVFAIL Extended DNS Error Code 9 - Cached Error 347 The resolver has cached SERVFAIL for this query without additional 348 information. Th R flag should be set. 350 4.2.10. SERVFAIL Extended DNS Error Code 10 - Not Ready 352 The server is unable to answer the query as it is not fully up and 353 functional yet. 355 4.3. INFO-CODEs for use with RESPONSE-CODE: NOTIMP(4) 357 4.3.1. NOTIMP Extended DNS Error Code 1 - Deprecated 359 The requested operation or query is not supported as its use has been 360 deprecated. Implementations should not set the R flag. (Retrying 361 request elsewhere is unlikely to yield any other results.) 363 4.4. INFO-CODEs for use with RESPONSE-CODE: REFUSED(5) 365 4.4.1. REFUSED Extended DNS Error Code 1 - Lame 367 An authoritative server that receives a query (with the RD bit clear) 368 for a domain for which it is not authoritative SHOULD include this 369 EDE code in the SERVFAIL response. A resolver that receives a query 370 (with the RD bit clear) SHOULD include this EDE code in the REFUSED 371 response. Implementations should set the R flag in this case 372 (another nameserver or resolver might not be lame). 374 4.4.2. REFUSED Extended DNS Error Code 2 - Prohibited 376 An authoritative or recursive resolver that receives a query from an 377 "unauthorized" client can annotate its REFUSED message with this 378 code. Examples of "unauthorized" clients are recursive queries from 379 IP addresses outside the network, blacklisted IP addresses, local 380 policy, etc. 382 Implementations SHOULD allow operators to define what to set the R 383 flag to in this case. 385 4.5. INFO-CODEs for use with RESPONSE-CODE: NXDOMAIN(3) 387 4.5.1. NXDOMAIN Extended DNS Error Code 1 - Blocked 389 The resolver attempted to perfom a DNS query but the domain is 390 blacklisted due to a security policy implemented on the server being 391 directly talked to. The R flag should be set. 393 4.6. INFO-CODEs for use with RESPONSE-CODE: NXDOMAIN(3) 395 4.6.1. NXDOMAIN Extended DNS Error Code 2 - Censored 397 The resolver attempted to perfom a DNS query but the domain was 398 blacklisted by a security policy imposed upon the server being talked 399 to. Note that how the imposed policy is applied is irrelevant (in- 400 band DNS somehow, court order, etc). The R flag should be set. 402 4.7. INFO-CODEs for use with RESPONSE-CODE: NXDOMAIN(3) 404 4.7.1. NXDOMAIN Extended DNS Error Code 3 - Stale Answer 406 The resolver was unable to resolve answer within its time limits and 407 decided to answer with a previously cached NXDOMAIN answer instead of 408 answering with an error. This is typically caused by problems on 409 authoritative side, possibly as result of a DoS attack. The R flag 410 should not be set, since retrying is likely to create additional load 411 without yielding a more fresh answer. 413 5. IANA Considerations 415 5.1. A New Extended Error Code EDNS Option 417 This document defines a new EDNS(0) option, entitled "Extended DNS 418 Error", assigned a value of TBD1 from the "DNS EDNS0 Option Codes 419 (OPT)" registry [to be removed upon publication: 420 [http://www.iana.org/assignments/dns-parameters/dns- 421 parameters.xhtml#dns-parameters-11] 422 Value Name Status Reference 423 ----- ---------------- ------ ------------------ 424 TBD Extended DNS Error TBD [ This document ] 426 5.2. New Double-Index Registry Table for Extended Error Codes 428 This document defines a new double-index IANA registry table, where 429 the first index value is the RCODE value and the second index value 430 is the INFO-CODE from the Extended DNS Error EDNS option defined in 431 this document. The IANA is requested to create and maintain this 432 "Extended DNS Error codes" registry. The codepoint space for each 433 INFO-CODE index is to be broken into 3 ranges: 435 o 0 - 3583: Specification required. 436 o 3584 - 3839: First Come First Served. 437 o 3840 - 4095: Experimental / Private use 439 A starting set of entries, based on the contents of this document, is 440 as follows: 442 RESPONSE-CODE: 0 (NOERROR) 443 INFO-CODE: 1 444 Purpose: Unsupported DNSKEY 445 Reference: Section 4.1.1 447 RESPONSE-CODE: 0 (NOERROR) 448 INFO-CODE: 2 449 Purpose: Unsupported DS Algorithm 450 Reference: Section 4.1.2 452 RESPONSE-CODE: 3 (NOERROR) 453 INFO-CODE: 3 454 Purpose: Answering with stale/cached data 455 Reference: Section 4.1.3.1 457 RESPONSE-CODE: 0 (NOERROR) 458 INFO-CODE: 4 459 Purpose: Forged answer 460 Reference: Section 4.1.4 462 RESPONSE-CODE: 0 (NOERROR) 463 INFO-CODE: 5 464 Purpose: DNSSEC Indeterminate 465 Reference: Section 4.1.5 467 RESPONSE-CODE: 2 (SERVFAIL) 468 INFO-CODE: 1 469 Purpose: DNSSEC Bogus 470 Reference: Section 4.2.1 472 RESPONSE-CODE: 2 (SERVFAIL) 473 INFO-CODE: 2 474 Purpose: Signature Expired 475 Reference: Section 4.2.2 477 RESPONSE-CODE: 2 (SERVFAIL) 478 INFO-CODE: 3 479 Purpose: Signature Not Yet Valid 480 Reference: Section 4.2.3 482 RESPONSE-CODE: 2 (SERVFAIL) 483 INFO-CODE: 4 484 Purpose: DNSKEY missing 485 Reference: Section 4.2.4 487 RESPONSE-CODE: 2 (SERVFAIL) 488 INFO-CODE: 5 489 Purpose: RRSIGs missing 490 Reference: Section 4.2.5 492 RESPONSE-CODE: 2 (SERVFAIL) 493 INFO-CODE: 6 494 Purpose: No Zone Key Bit Set 495 Reference: Section 4.2.6 497 RESPONSE-CODE: 2 (SERVFAIL) 498 INFO-CODE: 7 499 Purpose: No NSEC records could be obtained 500 Reference: Section 4.2.8 502 RESPONSE-CODE: 2 (SERVFAIL) 503 INFO-CODE: 9 504 Purpose: The SERVFAIL error comes from the cache 505 Reference: Section 4.2.9 507 RESPONSE-CODE: 2 (SERVFAIL) 508 INFO-CODE: 10 509 Purpose: Not Ready. 510 Reference: Section 4.2.10 512 RESPONSE-CODE: 3 (NXDOMAIN) 513 INFO-CODE: 1 514 Purpose: Blocked 515 Reference: Section 4.5.1 517 RESPONSE-CODE: 3 (NXDOMAIN) 518 INFO-CODE: 2 519 Purpose: Censored 520 Reference: Section 4.6.1 522 RESPONSE-CODE: 3 (NXDOMAIN) 523 INFO-CODE: 3 524 Purpose: Answering with stale/cached NXDOMAIN data 525 Reference: Section 4.7.1 527 RESPONSE-CODE: 4 (NOTIMP) 528 INFO-CODE: 1 529 Purpose: 530 Reference: Section 4.4.2 532 RESPONSE-CODE: 5 (REFUSED) 533 INFO-CODE: 1 534 Purpose: Lame 535 Reference: Section 4.4.1 537 RESPONSE-CODE: 5 (REFUSED) 538 INFO-CODE: 2 539 Purpose: Prohibited 540 Reference: Section 4.4.2 542 6. Security Considerations 544 Though DNSSEC continues to be deployed, unfortunately a significant 545 number of clients (~11% according to [GeoffValidation]) that receive 546 a SERVFAIL from a validating resolver because of a DNSSEC validaion 547 issue will simply ask the next (potentially non-validating) resolver 548 in their list, and thus don't get any of the protections which DNSSEC 549 should provide. This is very similar to a kid asking his mother if 550 he can have another cookie. When the mother says "No, it will ruin 551 your dinner!", going off and asking his (more permissive) father and 552 getting a "Yes, sure, have a cookie!". 554 This information is unauthenticated information, and an attacker (e.g 555 MITM or malicious recursive server) could insert an extended error 556 response into already untrusted data -- ideally clients and resolvers 557 would not trust any unauthenticated information, but until we live in 558 an era where all DNS answers are authenticated via DNSSEC or other 559 mechanisms, there are some tradeoffs. As an example, an attacker who 560 is able to insert the DNSSEC Bogus Extended Error into a packet could 561 instead simply reply with a fictitious address (A or AAAA) record. 562 The R bit hint and extended error information are informational - 563 implementations can choose how much to trust this information and 564 validating resolvers / stubs may choose to put a different weight on 565 it. 567 7. Acknowledgements 569 The authors wish to thank Joe Abley, Mark Andrews, Stephane 570 Bortzmeyer, Vladimir Cunat, Peter DeVries, Peter van Dijk, Donald 571 Eastlake, Bob Harold, Evan Hunt, Geoff Huston, Shane Kerr, Edward 572 Lewis, Carlos M. Martinez, George Michelson, Michael Sheldon, Petr 573 Spacek, Ondrej Sury, Loganaden Velvindron, and Paul Vixie. They also 574 vaguely remember discussing this with a number of people over the 575 years, but have forgotten who all they were -- if you were one of 576 them, and are not listed, please let us know and we'll acknowledge 577 you. 579 I also want to thank the band "Infected Mushroom" for providing a 580 good background soundtrack (and to see if I can get away with this!) 581 Another author would like to thank the band "Mushroom Infectors". 582 This was funny at the time we wrote it, but I cannot remember why... 584 8. References 586 8.1. Normative References 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, 590 DOI 10.17487/RFC2119, March 1997, . 593 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 594 for DNS (EDNS(0))", STD 75, RFC 6891, 595 DOI 10.17487/RFC6891, April 2013, . 598 8.2. Informative References 600 [GeoffValidation] 601 IANA, "A quick review of DNSSEC Validation in today's 602 Internet", June 2016, . 605 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 606 Wellington, "Secret Key Transaction Authentication for DNS 607 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 608 . 610 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 611 Transport Layer Security (DTLS)", RFC 8094, 612 DOI 10.17487/RFC8094, February 2017, . 615 Appendix A. Changes / Author Notes. 617 [RFC Editor: Please remove this section before publication ] 619 From -00 to -01: 621 o Address comments from IETF meeting. 622 o document copying the response code 623 o mention zero length fields are ok 624 o clarify lookup procedure 625 o mention that table isn't done 627 From -03 to -IETF 00: 629 o Renamed to draft-ietf-dnsop-extended-error 631 From -02 to -03: 633 o Added David Lawrence -- I somehow missed that in last version. 635 From -00 to -01; 637 o Fixed up some of the text, minor clarifications. 639 Authors' Addresses 641 Warren Kumari 642 Google 643 1600 Amphitheatre Parkway 644 Mountain View, CA 94043 645 US 647 Email: warren@kumari.net 649 Evan Hunt 650 ISC 651 950 Charter St 652 Redwood City, CA 94063 653 US 655 Email: each@isc.org 657 Roy Arends 658 ICANN 660 Email: roy.arends@icann.org 661 Wes Hardaker 662 USC/ISI 663 P.O. Box 382 664 Davis, CA 95617 665 US 667 Email: ietf@hardakers.net 669 David C Lawrence 670 Oracle + Dyn 671 150 Dow St 672 Manchester, NH 03101 673 US 675 Email: tale@dd.org