idnits 2.17.1 draft-ietf-dnsop-extended-error-03.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 (December 20, 2018) is 1953 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 140, but not defined ** Obsolete undefined reference: RFC 2671 (Obsoleted by RFC 6891) == Missing Reference: 'RFC6891' is mentioned on line 162, but not defined -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 1 error (**), 0 flaws (~~), 3 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: June 23, 2019 ISC 6 R. Arends 7 ICANN 8 W. Hardaker 9 USC/ISI 10 D. Lawrence 11 Oracle + Dyn 12 December 20, 2018 14 Extended DNS Errors 15 draft-ietf-dnsop-extended-error-03 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 June 23, 2019. 43 Copyright Notice 45 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . 3 62 2. Extended Error EDNS0 option format . . . . . . . . . . . . . 3 63 3. Use of the Extended DNS Error option . . . . . . . . . . . . 4 64 3.1. The R (Retry) flag . . . . . . . . . . . . . . . . . . . 5 65 3.2. The RESPONSE-CODE field . . . . . . . . . . . . . . . . . 5 66 3.3. The INFO-CODE field . . . . . . . . . . . . . . . . . . . 5 67 3.4. The EXTRA-TEXT field . . . . . . . . . . . . . . . . . . 5 68 4. Defined Extended DNS Errors . . . . . . . . . . . . . . . . . 5 69 4.1. INFO-CODEs for use with RESPONSE-CODE: SERVFAIL(2) . . . 6 70 4.1.1. SERVFAIL Extended DNS Error Code 1 - DNSSEC Bogus . . 6 71 4.1.2. SERVFAIL Extended DNS Error Code 2 - DNSSEC 72 Indeterminate . . . . . . . . . . . . . . . . . . . . 6 73 4.1.3. SERVFAIL Extended DNS Error Code 3 - Signature 74 Expired . . . . . . . . . . . . . . . . . . . . . . . 6 75 4.1.4. SERVFAIL Extended DNS Error Code 4 - Signature Not 76 Yet Valid . . . . . . . . . . . . . . . . . . . . . . 6 77 4.1.5. SERVFAIL Extended DNS Error Code 5 - Unsupported 78 DNSKEY Algorithm . . . . . . . . . . . . . . . . . . 6 79 4.1.6. SERVFAIL Extended DNS Error Code 6 - Unsupported 80 DS Algorithm . . . . . . . . . . . . . . . . . . . . 6 81 4.1.7. SERVFAIL Extended DNS Error Code 7 - DNSKEY missing . 6 82 4.1.8. SERVFAIL Extended DNS Error Code 8 - RRSIGs missing . 7 83 4.1.9. SERVFAIL Extended DNS Error Code 9 - No Zone Key Bit 84 Set . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 4.2. INFO-CODEs for use with RESPONSE-CODE: REFUSED(5) . . . . 7 86 4.2.1. REFUSED Extended DNS Error Code 1 - Lame . . . . . . 7 87 4.2.2. REFUSED Extended DNS Error Code 2 - Prohibited . . . 7 88 4.3. INFO-CODEs for use with RESPONSE-CODE: NXDOMAIN(3) . . . 7 89 4.3.1. NXDOMAIN Extended DNS Error Code 1 - Blocked . . . . 7 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 91 5.1. new Extended Error Code EDNS Option . . . . . . . . . . . 7 92 5.2. New Extended Error Code EDNS Option . . . . . . . . . . . 8 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 94 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 96 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 97 8.2. Informative References . . . . . . . . . . . . . . . . . 10 98 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 11 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 101 1. Introduction and background 103 There are many reasons that a DNS query may fail, some of them 104 transient, some permanent; some can be resolved by querying another 105 server, some are likely best handled by stopping resolution. 106 Unfortunately, the error signals that a DNS server can return are 107 very limited, and are not very expressive. This means that 108 applications and resolvers often have to "guess" at what the issue is 109 - e.g. was the answer marked REFUSED because of a lame delegation, or 110 because the nameserver is still starting up and loading zones? Is a 111 SERVFAIL a DNSSEC validation issue, or is the nameserver experiencing 112 a bad hair day? 114 A good example of issues that would benefit by additional error 115 information are errors caused by DNSSEC validation issues. When a 116 stub resolver queries a DNSSEC bogus name (using a validating 117 resolver), the stub resolver receives only a SERVFAIL in response. 118 Unfortunately, SERVFAIL is used to signal many sorts of DNS errors, 119 and so the stub resolver simply asks the next configured DNS 120 resolver. The result of trying the next resolver is one of two 121 outcomes: either the next resolver also validates, a SERVFAIL is 122 returned again, and the user gets an (largely) incomprehensible error 123 message; or the next resolver is not a validating resolver, and the 124 user is returned a potentially harmful result. 126 This document specifies a mechanism to extend (or annotate) DNS 127 errors to provide additional information about the cause of the 128 error. When properly authenticated, this information can be used by 129 the resolver to make a decision regarding whether or not to retry or 130 it can be used or by technical users attempting to debug issues. 132 1.1. Requirements notation 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2. Extended Error EDNS0 option format 140 This draft uses an EDNS0 ([RFC2671]) option to include Extended DNS 141 Error (EDE) information in DNS messages. The option is structured as 142 follows: 144 1 1 1 1 1 1 145 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 146 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 147 0: | OPTION-CODE | 148 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 149 2: | OPTION-LENGTH | 150 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 151 4: | R | RESERVED | 152 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 153 6: | RESPONSE-CODE | INFO-CODE | 154 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 155 8: | EXTRA-TEXT | 156 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 158 Field definition details: 160 o OPTION-CODE, 2 octets (defined in [RFC6891]), for EDE is TBD. 161 [RFC Editor: change TBD to the proper code once assigned by IANA.] 162 o OPTION-LENGTH, 2 octets ((defined in [RFC6891]) contains the 163 length of the payload (everything after OPTION-LENGTH) in octets 164 and should be 4 plus the length of the EXTRA-TEXT section (which 165 may be a zero-length string). 166 o The RETRY flag, 1 bit; the RETRY bit (R) indicates a flag defined 167 for use in this specification. 168 o The RESERVED bits, 15 bits: these bits are reserved for future 169 use, potentially as additional flags. The RESERVED bits MUST be 170 set to 0 by the sender and SHOULD be ignored by the receiver. 171 o RESPONSE-CODE, 4 bits. 172 o INFO-CODE, 12-bits. 173 o EXTRA-TEXT, a variable length, ASCII encoded, text field that may 174 hold additional textual information. 176 3. Use of the Extended DNS Error option 178 The Extended DNS Error (EDE) is an EDNS option. It can be included 179 in any response (SERVFAIL, NXDOMAIN, REFUSED, etc) to a query that 180 includes an EDNS option. This document includes a set of initial 181 codepoints (and requests to the IANA to add them to the registry), 182 but is extensible via the IANA registry to allow additional error and 183 information codes to be defined in the future. 185 The fields of the Extended DNS Error option are defined further in 186 the following sub-sections. 188 3.1. The R (Retry) flag 190 The R (Retry) flag provides a hint as to what the receiver may want 191 to do with this annotated error. Specifically, the R (or Retry) flag 192 provides a hint to the receiver that it should retry the query to 193 another server. If the R bit is set (1), the sender believes that 194 retrying the query may provide a successful answer next time; if the 195 R bit is clear (0), the sender believes that the resolver should not 196 ask another server. 198 The mechanism is specifically designed to be extensible, and so 199 implementations may receive EDE codes that it does not understand. 200 The R flag allows implementations to make a decision as to what to do 201 if it receives a response with an unknown code - retry or drop the 202 query. Note that this flag is only a suggestion. Unless a 203 protective transport mechanism (like TSIG [RFC2845] or TLS [RFC8094]) 204 is used, the bit's value could have have been altered by a person-in- 205 the-middle. Receivers can choose to ignore this hint. See the 206 security considerations for additional considerations. 208 3.2. The RESPONSE-CODE field 210 This 4-bit value SHOULD be a copy of the RCODE from the primary DNS 211 packet. Multiple EDNS0/EDE records may be included in the response. 212 When including multiple EDNS0/EDE records in a response in order to 213 provide additional error information, other RESPONSE-CODEs MAY use a 214 different RCODE. 216 3.3. The INFO-CODE field 218 This 12-bit value provides the additional context for the RESPONSE- 219 CODE value. This combination of the RESPONSE-CODE and the INFO-CODE 220 serve as a joint-index into the IANA "Extended DNS Errors" registry. 222 3.4. The EXTRA-TEXT field 224 The ASCII-encoded, EXTRA-TEXT field may be zero-length, or may hold 225 additional information useful to network operators. 227 4. Defined Extended DNS Errors 229 This document defines some initial EDE codes. The mechanism is 230 intended to be extensible, and additional code-points can be 231 registered in the "Extended DNS Errors" registry. This document 232 provides suggestions for the R flag, but the originating server may 233 ignore these recommendations if it knows better. 235 The RESPONSE-CODE and the INFO-CODE from the EDE EDNS option is used 236 to serve as a double index into the "Extended DNS Error codes" IANA 237 registry, the initial values for which are defined in the following 238 sub-sections. 240 4.1. INFO-CODEs for use with RESPONSE-CODE: SERVFAIL(2) 242 4.1.1. SERVFAIL Extended DNS Error Code 1 - DNSSEC Bogus 244 The resolver attempted to perform DNSSEC validation, but validation 245 ended in the Bogus state. The R flag should not be set. 247 4.1.2. SERVFAIL Extended DNS Error Code 2 - DNSSEC Indeterminate 249 The resolver attempted to perform DNSSEC validation, but validation 250 ended in the Indeterminate state. The R flag should not be set. 252 4.1.3. SERVFAIL Extended DNS Error Code 3 - Signature Expired 254 The resolver attempted to perform DNSSEC validation, but the 255 signature was expired. The R flag should not be set. 257 4.1.4. SERVFAIL Extended DNS Error Code 4 - Signature Not Yet Valid 259 The resolver attempted to perform DNSSEC validation, but the 260 signatures received were not yet valid. The R flag should not be 261 set. 263 4.1.5. SERVFAIL Extended DNS Error Code 5 - Unsupported DNSKEY 264 Algorithm 266 The resolver attempted to perform DNSSEC validation, but a DNSKEY 267 RRSET contained only unknown algorithms. The R flag should be set. 269 4.1.6. SERVFAIL Extended DNS Error Code 6 - Unsupported DS Algorithm 271 The resolver attempted to perform DNSSEC validation, but a DS RRSET 272 contained only unknown algorithms. The R flag should be set. 274 4.1.7. SERVFAIL Extended DNS Error Code 7 - DNSKEY missing 276 A DS record existed at a parent, but no DNSKEY record could be found 277 for the child. The R flag should not be set. 279 4.1.8. SERVFAIL Extended DNS Error Code 8 - RRSIGs missing 281 The resolver attempted to perform DNSSEC validation, but no RRSIGs 282 could be found for at least one RRset where RRSIGs were expected. 284 4.1.9. SERVFAIL Extended DNS Error Code 9 - No Zone Key Bit Set 286 The resolver attempted to perform DNSSEC validation, but no Zone Key 287 Bit was set in a DNSKEY. 289 4.2. INFO-CODEs for use with RESPONSE-CODE: REFUSED(5) 291 4.2.1. REFUSED Extended DNS Error Code 1 - Lame 293 An authoritative resolver that receives a query (with the RD bit 294 clear) for a domain for which it is not authoritative SHOULD include 295 this EDE code in the REFUSED response. Implementations should set 296 the R flag in this case (another nameserver might not be lame). 298 4.2.2. REFUSED Extended DNS Error Code 2 - Prohibited 300 An authoritative or recursive resolver that receives a query from an 301 "unauthorized" client can annotate its REFUSED message with this 302 code. Examples of "unauthorized" clients are recursive queries from 303 IP addresses outside the network, blacklisted IP addresses, local 304 policy, etc. 306 Implementations SHOULD allow operators to define what to set the R 307 flag to in this case. 309 4.3. INFO-CODEs for use with RESPONSE-CODE: NXDOMAIN(3) 311 4.3.1. NXDOMAIN Extended DNS Error Code 1 - Blocked 313 The resolver attempted to perfom a DNS query but the domain is 314 blacklisted due to a security policy. The R flag should not be set. 316 5. IANA Considerations 318 5.1. new Extended Error Code EDNS Option 320 This document defines a new EDNS(0) option, entitled "Extended DNS 321 Error", assigned a value of TBD1 from the "DNS EDNS0 Option Codes 322 (OPT)" registry [to be removed upon publication: 323 [http://www.iana.org/assignments/dns-parameters/dns- 324 parameters.xhtml#dns-parameters-11] 325 Value Name Status Reference 326 ----- ---------------- ------ ------------------ 327 TBD Extended DNS Error TBD [ This document ] 329 5.2. New Extended Error Code EDNS Option 331 This document defines a new double-index IANA registry table, where 332 the first index value is the RCODE value and the second index value 333 is the INFO-CODE from the Extended DNS Error EDNS option defined in 334 this document. The IANA is requested to create and maintain this 335 "Extended DNS Error codes" registry. The codepoint space for each 336 INFO-CODE index is to be broken into 3 ranges: 338 o 0 - 3583: Specification required. 339 o 3584 - 3839: First Come First Served. 340 o 3840 - 4095: Experimental / Private use 342 A starting set of entries, based on the contents of this document, is 343 as follows: 345 RESPONSE-CODE: 2 (SERVFAIL) 346 INFO-CODE: 1 347 Purpose: DNSSEC Bogus 348 Reference: Section 4.1.1 350 RESPONSE-CODE: 2 (SERVFAIL) 351 INFO-CODE: 2 352 Purpose: DNSSEC Indeterminate 353 Reference: Section 4.1.2 355 RESPONSE-CODE: 2 (SERVFAIL) 356 INFO-CODE: 3 357 Purpose: Signature Expired 358 Reference: Section 4.1.3 360 RESPONSE-CODE: 2 (SERVFAIL) 361 INFO-CODE: 4 362 Purpose: Signature Not Yet Valid 363 Reference: Section 4.1.4 365 RESPONSE-CODE: 2 (SERVFAIL) 366 INFO-CODE: 5 367 Purpose: Unsupported DNSKEY 368 Reference: Section 4.1.5 370 RESPONSE-CODE: 2 (SERVFAIL) 371 INFO-CODE: 6 372 Purpose: Unsupported DS Algorithm 373 Reference: Section 4.1.6 375 RESPONSE-CODE: 2 (SERVFAIL) 376 INFO-CODE: 7 377 Purpose: DNSKEY missing 378 Reference: Section 4.1.7 380 RESPONSE-CODE: 2 (SERVFAIL) 381 INFO-CODE: 8 382 Purpose: RRSIGs missing 383 Reference: Section 4.1.8 385 RESPONSE-CODE: 2 (SERVFAIL) 386 INFO-CODE: 9 387 Purpose: No Zone Key Bit Set 388 Reference: Section 4.1.9 390 RESPONSE-CODE: 3 (NXDOMAIN) 391 INFO-CODE: 1 392 Purpose: Blocked 393 Reference: Section 4.3.1 395 RESPONSE-CODE: 5 (REFUSED) 396 INFO-CODE: 1 397 Purpose: Lame 398 Reference: Section 4.2.1 400 RESPONSE-CODE: 5 (REFUSED) 401 INFO-CODE: 2 402 Purpose: Prohibited 403 Reference: Section 4.2.2 405 6. Security Considerations 407 Though DNSSEC continues to be deployed, unfortunately a significant 408 number of clients (~11% according to [GeoffValidation]) that receive 409 a SERVFAIL from a validating resolver because of a DNSSEC validaion 410 issue will simply ask the next (potentially non-validating) resolver 411 in their list, and thus don't get any of the protections which DNSSEC 412 should provide. This is very similar to a kid asking his mother if 413 he can have another cookie. When the mother says "No, it will ruin 414 your dinner!", going off and asking his (more permissive) father and 415 getting a "Yes, sure, have a cookie!". 417 This information is unauthenticated information, and an attacker (e.g 418 MITM or malicious recursive server) could insert an extended error 419 response into already untrusted data -- ideally clients and resolvers 420 would not trust any unauthenticated information, but until we live in 421 an era where all DNS answers are authenticated via DNSSEC or other 422 mechanisms, there are some tradeoffs. As an example, an attacker who 423 is able to insert the DNSSEC Bogus Extended Error into a packet could 424 instead simply reply with a fictitious address (A or AAAA) record. 425 The R bit hint and extended error information are informational - 426 implementations can choose how much to trust this information and 427 validating resolvers / stubs may choose to put a different weight on 428 it. 430 7. Acknowledgements 432 The authors wish to thank Joe Abley, Mark Andrews, Peter DeVries, 433 Peter van Dijk, Donald Eastlake, Bob Harold, Evan Hunt, Geoff Huston, 434 Shane Kerr, Edward Lewis, Carlos M. Martinez, George Michelson, Petr 435 Spacek, Ondrej Sury, Loganaden Velvindron, and Paul Vixie. They also 436 vaguely remember discussing this with a number of people over the 437 years, but have forgotten who all they were -- if you were one of 438 them, and are not listed, please let us know and we'll acknowledge 439 you. 441 I also want to thank the band "Infected Mushroom" for providing a 442 good background soundtrack (and to see if I can get away with this!) 443 Another author would like to thank the band "Mushroom Infectors". 444 This was funny at the time we wrote it, but I cannot remember why... 446 8. References 448 8.1. Normative References 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, 452 DOI 10.17487/RFC2119, March 1997, . 455 8.2. Informative References 457 [GeoffValidation] 458 IANA, "A quick review of DNSSEC Validation in today's 459 Internet", June 2016, . 462 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 463 Wellington, "Secret Key Transaction Authentication for DNS 464 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 465 . 467 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 468 Transport Layer Security (DTLS)", RFC 8094, 469 DOI 10.17487/RFC8094, February 2017, . 472 Appendix A. Changes / Author Notes. 474 [RFC Editor: Please remove this section before publication ] 476 From -00 to -01: 478 o Address comments from IETF meeting. 479 o document copying the response code 480 o mention zero length fields are ok 481 o clarify lookup procedure 482 o mention that table isn't done 484 From -03 to -IETF 00: 486 o Renamed to draft-ietf-dnsop-extended-error 488 From -02 to -03: 490 o Added David Lawrence -- I somehow missed that in last version. 492 From -00 to -01; 494 o Fixed up some of the text, minor clarifications. 496 Authors' Addresses 498 Warren Kumari 499 Google 500 1600 Amphitheatre Parkway 501 Mountain View, CA 94043 502 US 504 Email: warren@kumari.net 506 Evan Hunt 507 ISC 508 950 Charter St 509 Redwood City, CA 94063 510 US 512 Email: each@isc.org 513 Roy Arends 514 ICANN 516 Email: roy.arends@icann.org 518 Wes Hardaker 519 USC/ISI 520 P.O. Box 382 521 Davis, CA 95617 522 US 524 Email: ietf@hardakers.net 526 David C Lawrence 527 Oracle + Dyn 528 150 Dow St 529 Manchester, NH 03101 530 US 532 Email: tale@dd.org