idnits 2.17.1
draft-ietf-dnsop-extended-error-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 4 instances of too long lines in the document, the longest one
being 60 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 02, 2018) is 2126 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 147, but not defined
** Obsolete undefined reference: RFC 2671 (Obsoleted by RFC 6891)
== Missing Reference: 'RFC6891' is mentioned on line 169, but not defined
== Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 415,
but no explicit reference was found in the text
Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group W. Kumari
3 Internet-Draft Google
4 Intended status: Standards Track E. Hunt
5 Expires: January 3, 2019 ISC
6 R. Arends
7 ICANN
8 W. Hardaker
9 USC/ISI
10 D. Lawrence
11 Akamai Technologies
12 July 02, 2018
14 Extended DNS Errors
15 draft-ietf-dnsop-extended-error-01
17 Abstract
19 This document defines an extensible method to return additional
20 information about the cause of DNS errors. The primary use case is
21 to extend SERVFAIL to provide additional information about the cause
22 of DNS and DNSSEC failures.
24 [ Open question: The document currently defines a registry for
25 errors. It has also been suggested that the option also carry human
26 readable (text) messages, to allow the server admin to provide
27 additional debugging information (e.g: "example.com pointed their NS
28 at us. No idea why...", "We don't provide recursive DNS to
29 192.0.2.0. Please stop asking...", "Have you tried Acme Anvil and
30 DNS? We do DNS right..." (!). Please let us know if you think text
31 is needed, or if a 16bit FCFS registry is expressive enough. ]
33 [ Open question: This document discusses extended *errors*, but it
34 has been suggested that this could be used to also annotate *non-
35 error* messages. The authors do not think that this is a good idea,
36 but could be persuaded otherwise. ]
38 Status of This Memo
40 This Internet-Draft is submitted in full conformance with the
41 provisions of BCP 78 and BCP 79.
43 Internet-Drafts are working documents of the Internet Engineering
44 Task Force (IETF). Note that other groups may also distribute
45 working documents as Internet-Drafts. The list of current Internet-
46 Drafts is at https://datatracker.ietf.org/drafts/current/.
48 Internet-Drafts are draft documents valid for a maximum of six months
49 and may be updated, replaced, or obsoleted by other documents at any
50 time. It is inappropriate to use Internet-Drafts as reference
51 material or to cite them other than as "work in progress."
53 This Internet-Draft will expire on January 3, 2019.
55 Copyright Notice
57 Copyright (c) 2018 IETF Trust and the persons identified as the
58 document authors. All rights reserved.
60 This document is subject to BCP 78 and the IETF Trust's Legal
61 Provisions Relating to IETF Documents
62 (https://trustee.ietf.org/license-info) in effect on the date of
63 publication of this document. Please review these documents
64 carefully, as they describe your rights and restrictions with respect
65 to this document. Code Components extracted from this document must
66 include Simplified BSD License text as described in Section 4.e of
67 the Trust Legal Provisions and are provided without warranty as
68 described in the Simplified BSD License.
70 Table of Contents
72 1. Introduction and background . . . . . . . . . . . . . . . . . 3
73 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
74 2. Extended Error EDNS0 option format . . . . . . . . . . . . . 4
75 3. Use of the Extended DNS Error option . . . . . . . . . . . . 5
76 4. Defined Extended DNS Errors . . . . . . . . . . . . . . . . . 5
77 4.1. SERVFAIL(3) extended information codes . . . . . . . . . 6
78 4.1.1. Extended DNS Error Code 1 - DNSSEC Bogus . . . . . . 6
79 4.1.2. Extended DNS Error Code 2 - DNSSEC Indeterminate . . 6
80 4.1.3. Extended DNS Error Code 3 - Signature Expired . . . . 6
81 4.1.4. Extended DNS Error Code 4 - Signature Not Yet Valid . 6
82 4.1.5. Extended DNS Error Code 5 - Unsupported
83 DNSKEY Algorithm . . . . . . . . . . . . . . . . . . 6
84 4.1.6. Extended DNS Error Code 6 - Unsupported
85 DS Algorithm . . . . . . . . . . . . . . . . . . . . 6
86 4.1.7. Extended DNS Error Code 7 - DNSKEY missing . . . . . 6
87 4.1.8. Extended DNS Error Code 8 - RRSIGs missing . . . . . 6
88 4.1.9. Extended DNS Error Code 9 - No Zone Key Bit Set . . . 7
89 4.2. REFUSED(5) extended information codes . . . . . . . . . . 7
90 4.2.1. Extended DNS Error Code 1 - Lame . . . . . . . . . . 7
91 4.2.2. Extended DNS Error Code 2 - Prohibited . . . . . . . 7
92 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
93 5.1. new Extended Error Code EDNS Option . . . . . . . . . . . 7
94 5.2. new Extended Error Code EDNS Option . . . . . . . . . . . 7
95 6. Open questions . . . . . . . . . . . . . . . . . . . . . . . 8
96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
97 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
99 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
100 9.2. Informative References . . . . . . . . . . . . . . . . . 9
101 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 10
102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
104 1. Introduction and background
106 There are many reasons that a DNS query may fail, some of them
107 transient, some permanent; some can be resolved by querying another
108 server, some are likely best handled by stopping resolution.
109 Unfortunately, the error signals that a DNS server can return are
110 very limited, and are not very expressive. This means that
111 applications and resolvers often have to "guess" at what the issue is
112 - e.g the answer was marked REFUSED because of a lame delegation, or
113 because of a lame delegation or because the nameserver is still
114 starting up and loading zones? Is a SERVFAIL a DNSSEC validation
115 issue, or is the nameserver experiencing a bad hair day?
117 A good example of issues that would benefit by additional error
118 information is an error caused by a DNSSEC validation issue. When a
119 stub resolver queries a DNSSEC bogus name (using a validating
120 resolver), the stub resolver receives only a SERVFAIL in response.
121 Unfortunately, SERVFAIL is used to signal many sorts of DNS errors,
122 and so the stub resolver simply asks the next configured DNS
123 resolver. The result of trying the next resolver is one of two
124 outcomes: either the next resolver also validates, a SERVFAIL is
125 returned again, and the user gets an (largely) incomprehensible error
126 message; or the next resolver is not a validating resolver, and the
127 user is returned a potentially harmful result.
129 This document specifies a mechanism to extend (or annotate) DNS
130 errors to provide additional information about the cause of the
131 error. This information can be used by the resolver to make a
132 decision regarding whether or not to retry, or by technical users
133 attempting to debug issues.
135 Here is a reference to an "external" (non-RFC / draft) thing:
136 ([IANA.AS_Numbers]). And this is a link to an
137 ID:[I-D.ietf-sidr-iana-objects].
139 1.1. Requirements notation
141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
143 document are to be interpreted as described in [RFC2119].
145 2. Extended Error EDNS0 option format
147 This draft uses an EDNS0 ([RFC2671]) option to include extended error
148 (ExtError) information in DNS messages. The option is structured as
149 follows:
151 1 1 1 1 1 1
152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
153 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
154 0: | OPTION-CODE |
155 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
156 2: | OPTION-LENGTH |
157 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
158 4: | R | RESERVED |
159 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
160 6: | RESPONSE-CODE |
161 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
162 8: | INFO-CODE |
163 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
164 A: | EXTRA-TEXT |
165 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
167 o OPTION-CODE, 2 octets (defined in [RFC6891]), for ExtError is TBD.
169 o OPTION-LENGTH, 2 octets ((defined in [RFC6891]) contains the
170 length of the payload (everything after OPTION-LENGTH) in octets
171 and should be 4.
173 o RESERVED, 2 octets; the first bit (R) indicates a flag defined in
174 this specification. The remaining bits are reserved for future
175 use, potentially as additional flags.
177 o RESPONSE-CODE, 2 octets: this SHOULD be a copy of the RCODE from
178 the primary DNS packet. When including multiple extended error
179 EDNS0 records in a response in order to provide additional error
180 information, the RESPONSE-CODE MAY be a different RCODE.
182 o INFO-CODE, 2 octets.
184 o A variable length EXTRA-TEXT field holding additional textual
185 information. It may be zero length when no additional textual
186 information is included.
188 Currently the only defined flag is the R flag.
190 R - Retry The R (or Retry) flag provides a hint to the receiver that
191 it should retry the query, probably by querying another server.
192 If the R bit is set (1), the sender believes that retrying the
193 query may provide a successful answer next time; if the R bit is
194 clear (0), the sender believes that it should not ask another
195 server.
197 The remaining bits in the RESERVED field are reserved for future use
198 and MUST be set to 0 by the sender and SHOULD be ignored by the
199 receiver.
201 INFO-CODE: A code point that, when combined with the RCODE from the
202 DNS packet, serve as a joint-index into the IANA "Extended DNS
203 Errors" registry.
205 3. Use of the Extended DNS Error option
207 The Extended DNS Error (EDE) is an EDNS option. It can be included
208 in any error response (SERVFAIL, NXDOMAIN, REFUSED, etc) to a query
209 that includes an EDNS option. This document includes a set of
210 initial codepoints (and requests to the IANA to add them to the
211 registry), but is extensible via the IANA registry to allow
212 additional error and information codes to be defined in the future.
214 The R (Retry) flag provides a hint (or suggestion) as to what the
215 receiver may want to do with this annotated error. The mechanism is
216 specifically designed to be extensible, and so implementations may
217 receive EDE codes that it does not understand. The R flag allows
218 implementations to make a decision as to what to do if it receives a
219 response with an unknown code - retry or drop the query. Note that
220 this flag is only a suggestion or hint. Receivers can choose to
221 ignore this hint.
223 The EXTRA-INFO textual field may be zero-length, or may hold
224 additional information useful to network operators.
226 4. Defined Extended DNS Errors
228 This document defines some initial EDE codes. The mechanism is
229 intended to be extensible, and additional codepoints will be
230 registered in the "Extended DNS Errors" registry. This document
231 provides suggestions for the R flag, but the originating server may
232 ignore these recommendations if it knows better.
234 The RESPONSE-CODE and the INFO-CODE from the EDE EDNS option is used
235 to serve as a double index into the "Extended DNS Error codes" IANA
236 registry, the initial values for which are defined in the following
237 sub-sections.
239 4.1. SERVFAIL(3) extended information codes
241 4.1.1. Extended DNS Error Code 1 - DNSSEC Bogus
243 The resolver attempted to perform DNSSEC validation, but validation
244 ended in the Bogus state. The R flag should not be set.
246 4.1.2. Extended DNS Error Code 2 - DNSSEC Indeterminate
248 The resolver attempted to perform DNSSEC validation, but validation
249 ended in the Indeterminate state. The R flag should not be set.
251 4.1.3. Extended DNS Error Code 3 - Signature Expired
253 The resolver attempted to perform DNSSEC validation, but the
254 signature was expired. The R flag should not be set.
256 4.1.4. Extended DNS Error Code 4 - Signature Not Yet Valid
258 The resolver attempted to perform DNSSEC validation, but the
259 signatures received were not yet valid. The R flag should not be
260 set.
262 4.1.5. Extended DNS Error Code 5 - Unsupported DNSKEY Algorithm
264 The resolver attempted to perform DNSSEC validation, but a DNSKEY
265 RRSET contained only unknown algorithms. The R flag should not be
266 set.
268 4.1.6. Extended DNS Error Code 6 - Unsupported DS Algorithm
270 The resolver attempted to perform DNSSEC validation, but a DS RRSET
271 contained only unknown algorithms. The R flag should not be set.
273 4.1.7. Extended DNS Error Code 7 - DNSKEY missing
275 A DS record existed at a parent, but no DNSKEY record could be found
276 for the child. The R flag should not be set.
278 4.1.8. Extended DNS Error Code 8 - RRSIGs missing
280 The resolver attempted to perform DNSSEC validation, but no RRSIGs
281 could be found for at least one RRset where RRSIGs were expected.
283 4.1.9. Extended DNS Error Code 9 - No Zone Key Bit Set
285 The resolver attempted to perform DNSSEC validation, but no Zone Key
286 Bit was set in a DNSKEY.
288 4.2. REFUSED(5) extended information codes
290 4.2.1. Extended DNS Error Code 1 - Lame
292 An authoritative resolver that receives a query (with the RD bit
293 clear) for a domain for which it is not authoritative SHOULD include
294 this EDE code in the REFUSED response. Implementations should set
295 the R flag in this case (another nameserver might not be lame).
297 4.2.2. Extended DNS Error Code 2 - Prohibited
299 An authoritative or recursive resolver that receives a query from an
300 "unauthorized" client can annotate its REFUSED message with this
301 code. Examples of "unauthorized" clients are recursive queries from
302 IP addresses outside the network, blacklisted IP addresses, local
303 policy, etc.
305 Implementations SHOULD allow operators to define what to set the R
306 flag to in this case.
308 5. IANA Considerations
310 [This section under construction, beware. ]
312 5.1. new Extended Error Code EDNS Option
314 This document defines a new EDNS(0) option, entitled "Extended DNS
315 Error", assigned a value of TBD1 from the "DNS EDNS0 Option Codes
316 (OPT)" registry [to be removed upon publication:
317 [http://www.iana.org/assignments/dns-parameters/dns-
318 parameters.xhtml#dns-parameters-11]
320 Value Name Status Reference
321 ----- ---------------- ------ ------------------
322 TBD Extended DNS Error TBD [ This document ]
324 5.2. new Extended Error Code EDNS Option
326 This document defines a new double-index IANA registry table, where
327 the first index value is the RCODE value and the second index value
328 is the INFO-CODE from the Extended DNS Error EDNS option defined in
329 this document. The IANA is requested to create and maintain this
330 "Extended DNS Error codes" registry. The codepoint space for each
331 RCODE index is to be broken into 3 ranges:
333 o 1 - 16384: Specification required.
335 o 16385 - 65000: First Come First Served
337 o 65000 - 65534: Experimental / Private use
339 The codepoints 0, 65535 are reserved.
341 A starting table, based on the contents of this document, is as
342 follows:
344 | RCODE | EDE-INFO-CODE | Meaning | Ref |
345 |-------------+-------------------------+---------------------------------------------+------------------------------------------|
346 | SERVFAIL(2) | DNSSEC_BOGUS(1) | DNSSEC Validation resulted in Bogus | section |
347 | SERVFAIL(2) | DNSSEC_INDETERMINATE(2) | DNSSEC Validation resulted in Indeterminate | section |
349 [incomplete]
351 6. Open questions
353 1 Can this be included in *any* response or only responses to
354 requests that included an EDNS option? Resolvers are supposed to
355 ignore additional. EDNS capable ones are supposed to simply
356 ignore unknown options. I know the spec says you can only include
357 EDNS0 in a response if in a request -- it is time to reevaluate
358 this?
360 2 Can this be applied to *any* response, or only error responses?
362 3 Should textual information be allowed as well? What if the only
363 thing allowed is a domain name, e.g to point at where validation
364 began failing?
366 7. Security Considerations
368 DNSSEC is being deployed - unfortunately a significant number of
369 clients (~11% according to [GeoffValidation]), when receiving a
370 SERVFAIL from a validating resolver because of a DNSSEC validaion
371 issue simply ask the next (non-validating) resolver in their list,
372 and don't get any of the protections which DNSSEC should provide.
373 This is very similar to a kid asking his mother if he can have
374 another cookie. When the mother says "No, it will ruin your
375 dinner!", going off and asking his (more permissive) father and
376 getting a "Yes, sure, cookie!".
378 8. Acknowledgements
380 The authors wish to thank Geoff Huston and Bob Harold, Carlos M.
381 Martinez, Peter DeVries, George Michelson, Mark Andrews, Ondrej Sury,
382 Edward Lewis, Paul Vixie, Shane Kerr. They also vaguely remember
383 discussing this with a number of people over the years, but have
384 forgotten who all they were -- if you were one of them, and are not
385 listed, please let us know and we'll acknowledge you.
387 I also want to thank the band "Infected Mushroom" for providing a
388 good background soundtrack (and to see if I can get away with this!)
389 Another author would like to thank the band "Mushroom Infectors".
390 This was funny at the time we wrote it, but I cannot remember why...
392 We would like to especially thank Peter van Dijk, who sent GitHub
393 pull requests.
395 9. References
397 9.1. Normative References
399 [IANA.AS_Numbers]
400 IANA, "Autonomous System (AS) Numbers",
401 .
403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
404 Requirement Levels", BCP 14, RFC 2119,
405 DOI 10.17487/RFC2119, March 1997,
406 .
408 9.2. Informative References
410 [GeoffValidation]
411 IANA, "A quick review of DNSSEC Validation in today's
412 Internet", June 2016, .
415 [I-D.ietf-sidr-iana-objects]
416 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects
417 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in
418 progress), May 2011.
420 Appendix A. Changes / Author Notes.
422 [RFC Editor: Please remove this section before publication ]
424 From -00 to -01:
426 o Address comments from IETF meeting.
428 o document copying the response code
430 o mention zero length fields are ok
432 o clarify lookup procedure
434 o mention that table isn't done
436 From -03 to -IETF 00:
438 o Renamed to draft-ietf-dnsop-extended-error
440 From -02 to -03:
442 o Added David Lawrence -- I somehow missed that in last version.
444 From -00 to -01;
446 o Fixed up some of the text, minor clarifications.
448 Authors' Addresses
450 Warren Kumari
451 Google
452 1600 Amphitheatre Parkway
453 Mountain View, CA 94043
454 US
456 Email: warren@kumari.net
458 Evan Hunt
459 ISC
460 950 Charter St
461 Redwood City, CA 94063
462 US
464 Email: each@isc.org
465 Roy Arends
466 ICANN
468 Email: roy.arends@icann.org
470 Wes Hardaker
471 USC/ISI
472 P.O. Box 382
473 Davis, VA 95617
474 US
476 Email: ietf@hardakers.net
478 David C Lawrence
479 Akamai Technologies
480 150 Broadway
481 Cambridge, MA 02142-1054
482 US
484 Email: tale@akamai.com