draft-ietf-dnsop-extended-error-01.txt   draft-ietf-dnsop-extended-error-02.txt 
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track E. Hunt Intended status: Standards Track E. Hunt
Expires: January 3, 2019 ISC Expires: March 25, 2019 ISC
R. Arends R. Arends
ICANN ICANN
W. Hardaker W. Hardaker
USC/ISI USC/ISI
D. Lawrence D. Lawrence
Akamai Technologies Oracle + Dyn
July 02, 2018 September 21, 2018
Extended DNS Errors Extended DNS Errors
draft-ietf-dnsop-extended-error-01 draft-ietf-dnsop-extended-error-02
Abstract Abstract
This document defines an extensible method to return additional This document defines an extensible method to return additional
information about the cause of DNS errors. The primary use case is information about the cause of DNS errors. The primary use case is
to extend SERVFAIL to provide additional information about the cause to extend SERVFAIL to provide additional information about the cause
of DNS and DNSSEC failures. of DNS and DNSSEC failures.
[ Open question: The document currently defines a registry for
errors. It has also been suggested that the option also carry human
readable (text) messages, to allow the server admin to provide
additional debugging information (e.g: "example.com pointed their NS
at us. No idea why...", "We don't provide recursive DNS to
192.0.2.0. Please stop asking...", "Have you tried Acme Anvil and
DNS? We do DNS right..." (!). Please let us know if you think text
is needed, or if a 16bit FCFS registry is expressive enough. ]
[ Open question: This document discusses extended *errors*, but it
has been suggested that this could be used to also annotate *non-
error* messages. The authors do not think that this is a good idea,
but could be persuaded otherwise. ]
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019. This Internet-Draft will expire on March 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and background . . . . . . . . . . . . . . . . . 3 1. Introduction and background . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Extended Error EDNS0 option format . . . . . . . . . . . . . 4 2. Extended Error EDNS0 option format . . . . . . . . . . . . . 3
3. Use of the Extended DNS Error option . . . . . . . . . . . . 5 3. Use of the Extended DNS Error option . . . . . . . . . . . . 5
4. Defined Extended DNS Errors . . . . . . . . . . . . . . . . . 5 4. Defined Extended DNS Errors . . . . . . . . . . . . . . . . . 5
4.1. SERVFAIL(3) extended information codes . . . . . . . . . 6 4.1. SERVFAIL(2) extended information codes . . . . . . . . . 5
4.1.1. Extended DNS Error Code 1 - DNSSEC Bogus . . . . . . 6 4.1.1. Extended DNS Error Code 1 - DNSSEC Bogus . . . . . . 6
4.1.2. Extended DNS Error Code 2 - DNSSEC Indeterminate . . 6 4.1.2. Extended DNS Error Code 2 - DNSSEC Indeterminate . . 6
4.1.3. Extended DNS Error Code 3 - Signature Expired . . . . 6 4.1.3. Extended DNS Error Code 3 - Signature Expired . . . . 6
4.1.4. Extended DNS Error Code 4 - Signature Not Yet Valid . 6 4.1.4. Extended DNS Error Code 4 - Signature Not Yet Valid . 6
4.1.5. Extended DNS Error Code 5 - Unsupported 4.1.5. Extended DNS Error Code 5 - Unsupported
DNSKEY Algorithm . . . . . . . . . . . . . . . . . . 6 DNSKEY Algorithm . . . . . . . . . . . . . . . . . . 6
4.1.6. Extended DNS Error Code 6 - Unsupported 4.1.6. Extended DNS Error Code 6 - Unsupported
DS Algorithm . . . . . . . . . . . . . . . . . . . . 6 DS Algorithm . . . . . . . . . . . . . . . . . . . . 6
4.1.7. Extended DNS Error Code 7 - DNSKEY missing . . . . . 6 4.1.7. Extended DNS Error Code 7 - DNSKEY missing . . . . . 6
4.1.8. Extended DNS Error Code 8 - RRSIGs missing . . . . . 6 4.1.8. Extended DNS Error Code 8 - RRSIGs missing . . . . . 6
4.1.9. Extended DNS Error Code 9 - No Zone Key Bit Set . . . 7 4.1.9. Extended DNS Error Code 9 - No Zone Key Bit Set . . . 6
4.2. REFUSED(5) extended information codes . . . . . . . . . . 7 4.2. REFUSED(5) extended information codes . . . . . . . . . . 7
4.2.1. Extended DNS Error Code 1 - Lame . . . . . . . . . . 7 4.2.1. Extended DNS Error Code 1 - Lame . . . . . . . . . . 7
4.2.2. Extended DNS Error Code 2 - Prohibited . . . . . . . 7 4.2.2. Extended DNS Error Code 2 - Prohibited . . . . . . . 7
4.3. NXDOMAIN(3) extended information codes . . . . . . . . . 7
4.3.1. Extended DNS Error Code 1 - Blocked . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. new Extended Error Code EDNS Option . . . . . . . . . . . 7 5.1. new Extended Error Code EDNS Option . . . . . . . . . . . 7
5.2. new Extended Error Code EDNS Option . . . . . . . . . . . 7 5.2. new Extended Error Code EDNS Option . . . . . . . . . . . 7
6. Open questions . . . . . . . . . . . . . . . . . . . . . . . 8 6. Open questions . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 10 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction and background 1. Introduction and background
There are many reasons that a DNS query may fail, some of them There are many reasons that a DNS query may fail, some of them
transient, some permanent; some can be resolved by querying another transient, some permanent; some can be resolved by querying another
server, some are likely best handled by stopping resolution. server, some are likely best handled by stopping resolution.
Unfortunately, the error signals that a DNS server can return are Unfortunately, the error signals that a DNS server can return are
very limited, and are not very expressive. This means that very limited, and are not very expressive. This means that
applications and resolvers often have to "guess" at what the issue is applications and resolvers often have to "guess" at what the issue is
- e.g the answer was marked REFUSED because of a lame delegation, or - e.g the answer was marked REFUSED because of a lame delegation, or
because of a lame delegation or because the nameserver is still because of a lame delegation or because the nameserver is still
starting up and loading zones? Is a SERVFAIL a DNSSEC validation starting up and loading zones? Is a SERVFAIL a DNSSEC validation
issue, or is the nameserver experiencing a bad hair day? issue, or is the nameserver experiencing a bad hair day?
A good example of issues that would benefit by additional error A good example of issues that would benefit by additional error
information is an error caused by a DNSSEC validation issue. When a information is an error caused by a DNSSEC validation issue. When a
skipping to change at page 6, line 5 skipping to change at page 5, line 47
intended to be extensible, and additional codepoints will be intended to be extensible, and additional codepoints will be
registered in the "Extended DNS Errors" registry. This document registered in the "Extended DNS Errors" registry. This document
provides suggestions for the R flag, but the originating server may provides suggestions for the R flag, but the originating server may
ignore these recommendations if it knows better. ignore these recommendations if it knows better.
The RESPONSE-CODE and the INFO-CODE from the EDE EDNS option is used The RESPONSE-CODE and the INFO-CODE from the EDE EDNS option is used
to serve as a double index into the "Extended DNS Error codes" IANA to serve as a double index into the "Extended DNS Error codes" IANA
registry, the initial values for which are defined in the following registry, the initial values for which are defined in the following
sub-sections. sub-sections.
4.1. SERVFAIL(3) extended information codes 4.1. SERVFAIL(2) extended information codes
4.1.1. Extended DNS Error Code 1 - DNSSEC Bogus 4.1.1. Extended DNS Error Code 1 - DNSSEC Bogus
The resolver attempted to perform DNSSEC validation, but validation The resolver attempted to perform DNSSEC validation, but validation
ended in the Bogus state. The R flag should not be set. ended in the Bogus state. The R flag should not be set.
4.1.2. Extended DNS Error Code 2 - DNSSEC Indeterminate 4.1.2. Extended DNS Error Code 2 - DNSSEC Indeterminate
The resolver attempted to perform DNSSEC validation, but validation The resolver attempted to perform DNSSEC validation, but validation
ended in the Indeterminate state. The R flag should not be set. ended in the Indeterminate state. The R flag should not be set.
skipping to change at page 7, line 30 skipping to change at page 7, line 25
An authoritative or recursive resolver that receives a query from an An authoritative or recursive resolver that receives a query from an
"unauthorized" client can annotate its REFUSED message with this "unauthorized" client can annotate its REFUSED message with this
code. Examples of "unauthorized" clients are recursive queries from code. Examples of "unauthorized" clients are recursive queries from
IP addresses outside the network, blacklisted IP addresses, local IP addresses outside the network, blacklisted IP addresses, local
policy, etc. policy, etc.
Implementations SHOULD allow operators to define what to set the R Implementations SHOULD allow operators to define what to set the R
flag to in this case. flag to in this case.
4.3. NXDOMAIN(3) extended information codes
4.3.1. Extended DNS Error Code 1 - Blocked
The resolver attempted to perfom a DNS query but the domain is
blacklisted due to a security policy. The R flag should not be set.
5. IANA Considerations 5. IANA Considerations
[This section under construction, beware. ] [This section under construction, beware. ]
5.1. new Extended Error Code EDNS Option 5.1. new Extended Error Code EDNS Option
This document defines a new EDNS(0) option, entitled "Extended DNS This document defines a new EDNS(0) option, entitled "Extended DNS
Error", assigned a value of TBD1 from the "DNS EDNS0 Option Codes Error", assigned a value of TBD1 from the "DNS EDNS0 Option Codes
(OPT)" registry [to be removed upon publication: (OPT)" registry [to be removed upon publication:
[http://www.iana.org/assignments/dns-parameters/dns- [http://www.iana.org/assignments/dns-parameters/dns-
skipping to change at page 8, line 34 skipping to change at page 8, line 35
6. Open questions 6. Open questions
1 Can this be included in *any* response or only responses to 1 Can this be included in *any* response or only responses to
requests that included an EDNS option? Resolvers are supposed to requests that included an EDNS option? Resolvers are supposed to
ignore additional. EDNS capable ones are supposed to simply ignore additional. EDNS capable ones are supposed to simply
ignore unknown options. I know the spec says you can only include ignore unknown options. I know the spec says you can only include
EDNS0 in a response if in a request -- it is time to reevaluate EDNS0 in a response if in a request -- it is time to reevaluate
this? this?
2 Can this be applied to *any* response, or only error responses?
3 Should textual information be allowed as well? What if the only
thing allowed is a domain name, e.g to point at where validation
began failing?
7. Security Considerations 7. Security Considerations
DNSSEC is being deployed - unfortunately a significant number of DNSSEC is being deployed - unfortunately a significant number of
clients (~11% according to [GeoffValidation]), when receiving a clients (~11% according to [GeoffValidation]), when receiving a
SERVFAIL from a validating resolver because of a DNSSEC validaion SERVFAIL from a validating resolver because of a DNSSEC validaion
issue simply ask the next (non-validating) resolver in their list, issue simply ask the next (non-validating) resolver in their list,
and don't get any of the protections which DNSSEC should provide. and don't get any of the protections which DNSSEC should provide.
This is very similar to a kid asking his mother if he can have This is very similar to a kid asking his mother if he can have
another cookie. When the mother says "No, it will ruin your another cookie. When the mother says "No, it will ruin your
dinner!", going off and asking his (more permissive) father and dinner!", going off and asking his (more permissive) father and
getting a "Yes, sure, cookie!". getting a "Yes, sure, cookie!".
8. Acknowledgements 8. Acknowledgements
The authors wish to thank Geoff Huston and Bob Harold, Carlos M. The authors wish to thank Geoff Huston and Bob Harold, Carlos M.
Martinez, Peter DeVries, George Michelson, Mark Andrews, Ondrej Sury, Martinez, Peter DeVries, George Michelson, Mark Andrews, Ondrej Sury,
Edward Lewis, Paul Vixie, Shane Kerr. They also vaguely remember Edward Lewis, Paul Vixie, Shane Kerr, Loganaden Velvindron. They
discussing this with a number of people over the years, but have also vaguely remember discussing this with a number of people over
forgotten who all they were -- if you were one of them, and are not the years, but have forgotten who all they were -- if you were one of
listed, please let us know and we'll acknowledge you. them, and are not listed, please let us know and we'll acknowledge
you.
I also want to thank the band "Infected Mushroom" for providing a I also want to thank the band "Infected Mushroom" for providing a
good background soundtrack (and to see if I can get away with this!) good background soundtrack (and to see if I can get away with this!)
Another author would like to thank the band "Mushroom Infectors". Another author would like to thank the band "Mushroom Infectors".
This was funny at the time we wrote it, but I cannot remember why... This was funny at the time we wrote it, but I cannot remember why...
We would like to especially thank Peter van Dijk, who sent GitHub We would like to especially thank Peter van Dijk, who sent GitHub
pull requests. pull requests.
9. References 9. References
skipping to change at page 11, line 4 skipping to change at page 10, line 44
Email: warren@kumari.net Email: warren@kumari.net
Evan Hunt Evan Hunt
ISC ISC
950 Charter St 950 Charter St
Redwood City, CA 94063 Redwood City, CA 94063
US US
Email: each@isc.org Email: each@isc.org
Roy Arends Roy Arends
ICANN ICANN
Email: roy.arends@icann.org Email: roy.arends@icann.org
Wes Hardaker Wes Hardaker
USC/ISI USC/ISI
P.O. Box 382 P.O. Box 382
Davis, VA 95617 Davis, CA 95617
US US
Email: ietf@hardakers.net Email: ietf@hardakers.net
David C Lawrence David C Lawrence
Akamai Technologies Oracle + Dyn
150 Broadway 150 Dow St
Cambridge, MA 02142-1054 Manchester, NH 03101
US US
Email: tale@akamai.com Email: tale@dd.org
 End of changes. 21 change blocks. 
41 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/