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