Internet DRAFT - draft-ietf-dnsop-dns-error-reporting
draft-ietf-dnsop-dns-error-reporting
dnsop R. Arends
Internet-Draft M. Larson
Intended status: Standards Track ICANN
Expires: 6 August 2023 2 February 2023
DNS Error Reporting
draft-ietf-dnsop-dns-error-reporting-04
Abstract
DNS error reporting is a lightweight reporting mechanism that
provides the operator of an authoritative server with reports on DNS
resource records that fail to resolve or validate. A domain owner or
DNS hosting organization can use these reports to improve domain
hosting. The reports are based on extended DNS errors as described
in RFC 8914.
When a domain name fails to resolve or validate due to a
misconfiguration or an attack, the operator of the authoritative
server may be unaware of this. To mitigate this lack of feedback,
this document describes a method for a validating recursive resolver
to automatically signal an error to a monitoring agent specified by
the authoritative server.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 August 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Arends & Larson Expires 6 August 2023 [Page 1]
Internet-Draft DNS-ER February 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Managing Caching Optimizations . . . . . . . . . . . . . 4
4.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. EDNS0 Option Specification . . . . . . . . . . . . . . . . . 6
6. DNS error reporting specification . . . . . . . . . . . . . . 6
6.1. Reporting Resolver Specification . . . . . . . . . . . . 6
6.1.1. Constructing the Report Query . . . . . . . . . . . . 7
6.2. Authoritative server specification . . . . . . . . . . . 7
6.3. Monitoring agent specification . . . . . . . . . . . . . 7
6.4. Choosing an agent domain . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
When an authoritative server serves a stale DNSSEC signed zone, the
cryptographic signatures over the resource record sets (RRsets) may
have lapsed. A validating recursive resolver will fail to validate
these resource records.
Similarly, when there is a mismatch between the DS records at a
parent zone and the key signing key at the child zone, a validating
recursive resolver will fail to authenticate records in the child
zone.
These are two of several failure scenarios that may go unnoticed for
some time by the operator of a zone.
Arends & Larson Expires 6 August 2023 [Page 2]
Internet-Draft DNS-ER February 2023
Today, there is no direct relationship between operators of
validating recursive resolvers and authoritative servers. Outages
are often noticed indirectly by end users, and reported via social
media (if reported at all).
When records fail to validate, there is no facility to report this
failure in an automated way. If there is any indication that an
error or warning has happened, it may be buried in log files of the
validating resolver or not logged at all.
This document describes a method that can be used by validating
recursive resolvers to report DNSSEC validation errors in an
automated way.
It allows an authoritative server to announce a monitoring agent
where validating recursive resolvers can report issues if those
resolvers are configured to do so.
The burden to report a failure falls on the validating recursive
resolver. It is important that the effort needed to report failure
is low, with minimal impact to its main functions. To accomplish
this goal, the DNS itself is utilized to report the error.
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology
Reporting resolver: In the context of this document, "reporting
resolver" is used as a shorthand for a validating recursive
resolver that supports DNS error reporting.
Report query: The DNS query used to report an error is called a
report query. A report query is for a DNS TXT resource record
type. The content of the error report are encoded in the QNAME of
the report query.
Monitoring agent: An authoritative server that receives report
queries. This facility is indicated by a domain name, referred to
as the agent domain.
Agent domain: A domain name which the reporting resolver includes in
the QNAME of the report query.
Arends & Larson Expires 6 August 2023 [Page 3]
Internet-Draft DNS-ER February 2023
4. Overview
An authoritative server indicates support for DNS error reporting by
including an EDNS0 report channel option with OPTION-CODE [TBD] and
the agent domain in the response. The agent domain is a fully
qualified, uncompressed domain name in DNS wireformat. The
authoritative server MUST NOT include this option in the response if
the configured agent domain is empty, or is the null label (which
would indicate the DNS root).
If the authoritative server has indicated support for DNS error
reporting and there is an issue that can be reported via extended DNS
errors, the reporting resolver encodes the error report in the QNAME
of the report query. The reporting resolver builds this QNAME by
concatenating the _er label, the QTYPE, the QNAME that resulted in
failure, the extended error code (as described in [RFC8914]), the
label "_er" again, and the agent domain. See the example in
Section 4.2. Note that a regular RCODE is not included because the
RCODE is not relevant to the extended error code.
The resulting report query is sent as a standard DNS query for a TXT
DNS resource record type by the reporting resolver.
The report query will ultimately arrive at the monitoring agent. A
response is returned by the monitoring agent, which in turn can be
cached by the reporting resolver. This caching is essential. It
dampens the number of report queries sent by a reporting resolver for
the same problem, that is, once per TTL. However, certain
optimizations such as [RFC8020] and [RFC8198] may reduce the number
of error report queries as well.
This document gives no guidance on the content of the TXT resource
record RDATA for this record.
4.1. Managing Caching Optimizations
The reporting resolver may utilize various caching optimizations that
inhibit subsequent error reporting to the same monitoring agent.
If the monitoring agent were to respond with NXDOMAIN (name error),
[RFC8020] says that any name at or below that domain should be
considered unreachable, and negative caching would prohibit
subsequent queries for anything at or below that domain for a period
of time, depending on the negative TTL [RFC2308].
Since the monitoring agent may not know the contents of all the zones
for which it acts as a monitoring agent, the monitoring agent MUST
NOT respond with NXDOMAIN for domains it is monitoring because that
Arends & Larson Expires 6 August 2023 [Page 4]
Internet-Draft DNS-ER February 2023
could inhibit subsequent queries. One method to avoid NXDOMAIN is to
use a wildcard domain name [RFC4592] in the zone for the agent
domain.
When the agent domain is signed, a resolver may use aggressive
negative caching (described in [RFC8198]). This optimization makes
use of NSEC and NSEC3 (without opt-out) records and allows the
resolver to do the wildcard synthesis. When this happens, the
resolver does not send subsequent queries because it will be able to
synthesize a response from previously cached material.
A solution is to avoid DNSSEC for the agent domain. Signing the
agent domain will incur an additional burden on the reporting
resolver, as it has to validate the response. However, this response
has no utility to the reporting resolver other than dampening the
query load for error reports.
4.2. Example
A query for "broken.test.", type A, is sent by a reporting resolver.
The request includes an empty EDNS0 report channel option.
The domain "test." is hosted on a set of authoritative servers. One
of these authoritarive servers serves a stale version of the "test."
zone. This authoritative server has an agent domain configured:
"a01.agent-domain.example.".
The authoritative server with the stale "test." zone receives the
request for "broken.test". As support for DNS error reporting was
indicated by a empty EDNS0 report channel option in the request, the
server includes the EDNS0 report channel option with the domain name
"a01.agent-domain.example.".
The reporting resolver is unable to validate the "broken.test" RRSet
for type 1 (an A record), due to an RRSIG record with an expired
signature.
The reporting resolver constructs the QNAME
"_er.1.broken.test.7._er.a01.agent-domain.example." and resolves it.
This QNAME indicates extended DNS error 7 occurred while trying to
validate "broken.test." type 1 record.
When this query is received at the monitoring agent (the operators of
the authoritative server for a01.agent-domain.example), the agent can
determine that the "test." zone contained an expired signature record
(extended error 7) for type A for the domain name "broken.test.".
The monitoring agent can contact the operators of "test." to fix the
issue.
Arends & Larson Expires 6 August 2023 [Page 5]
Internet-Draft DNS-ER February 2023
5. EDNS0 Option Specification
This method uses an EDNS0 [RFC6891] option to indicate the agent
domain in DNS messages. The option is structured as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION-CODE = TBD | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ AGENT DOMAIN /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Field definition details:
OPTION-CODE: 2 octets; indicates error reporting support is TBD.
The name for the option code is Report-Channel.
OPTION-LENGTH: 2-octets; contains the length of the AGENT DOMAIN
field in octets.
:AGENT DOMAIN: A fully qualified domain name [RFC8499] in
uncompressed DNS wire format.
6. DNS error reporting specification
The various errors that a reporting resolver may encounter are listed
in [RFC8914]. Note that not all listed errors may be supported by
the reporting resolver. This document does not specify what is or is
not an error.
The DNS class is not specified in the error report.
6.1. Reporting Resolver Specification
The reporting resolver MUST NOT use DNS error reporting to report a
failure in resolving the report query.
The EDNS0 report channel option MUST NOT be included in queries.
The reporting resolver MUST NOT use DNS error reporting if the
authoritative server returned an empty agent domain field in the
EDNS0 report channel option.
Arends & Larson Expires 6 August 2023 [Page 6]
Internet-Draft DNS-ER February 2023
6.1.1. Constructing the Report Query
The QNAME for the report query is constructed by concatenating the
following elements, appending each successive element in the list to
the right-hand side of the QNAME:
* A label containing the string "_er".
* The QTYPE that was used in the query that resulted in the extended
DNS error, presented as a decimal value, in a single DNS label.
* The QNAME that was used in the query that resulted in the extended
DNS error. The QNAME may consist of multiple labels and is
concatenated as is, i.e. in DNS wire format.
* The extended DNS error, presented as a decimal value, in a single
DNS label.
* A label containing the string "_er".
* The agent domain. The agent domain as received in the EDNS0
report channel option set by the authoritative server.
If the report query QNAME exceeds 255 octets, it MUST NOT be sent.
The "_er" labels allow the monitoring agent to differentiate between
the agent domain and the faulty query name. When the specified agent
domain is empty, or a null label (despite being not allowed in this
specification), the report query will have "_er" as a top-level
domain as a result and not the original query. The purpose of the
first "_er" label is to indicate that a complete report query has
been received, instead of a shorter report query due to query
minimization.
6.2. Authoritative server specification
The authoritative server SHOULD NOT have multiple agent domains
configured for a single zone. To support multiple monitoring agents,
a single agent can delegate to other agent domains.
6.3. Monitoring agent specification
It is RECOMMENDED that the authoritative server for the agent domain
replies with a positive response (i.e. not NODATA or NXDOMAIN)
containing a TXT record.
Arends & Larson Expires 6 August 2023 [Page 7]
Internet-Draft DNS-ER February 2023
6.4. Choosing an agent domain
It is RECOMMENDED that the agent domain be kept relatively short to
allow for a longer QNAME in the report query.
7. IANA Considerations
IANA is requested to assign the following DNS EDNS0 option code
registry:
Value Name Status Reference
----- ---- -------- ---------------
TBD Agent-Domain Standard [this document]
IANA is requested to assign the following Underscored and Globally
Scoped DNS Node Name registry:
RR Type _NODE NAME Reference
----- ---------- ---------
TXT _er [this document]
8. Security considerations
Use of DNS error reporting may expose local configuration mistakes in
the reporting resolver, such as stale DNSSEC trust anchors to the
reporting agent.
DNS error reporting SHOULD be done using DNS query name minimization
[RFC9156] to improve privacy.
DNS error reporting is done without any authentication between the
reporting resolver and the authoritative server of the agent domain.
Authentication significantly increases the burden on the reporting
resolver without any benefit to the monitoring agent, authoritative
server or reporting resolver.
The method described in this document will cause additional queries
by the reporting resolver to authoritative servers in order to
resolve the report query.
This method can be abused by deploying broken zones with agent
domains that are delegated to servers operated by the intended victim
in combination with open resolvers [RFC8499].
Arends & Larson Expires 6 August 2023 [Page 8]
Internet-Draft DNS-ER February 2023
9. Acknowledgements
This document is based on an idea by Roy Arends and David Conrad.
The authors would like to thank Peter van Dijk, Stephane Bortzmeyer,
Shane Kerr, Vladimir Cunat, Paul Hoffman, Philip Homburg, Mark
Andrews, Libor Peltan, Matthijs Mekking, Willem Toorop, Tom Carpay,
Dick Franks, Benno Overeinder and Petr Spacek for their
contributions.
10. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<https://www.rfc-editor.org/info/rfc4592>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
November 2016, <https://www.rfc-editor.org/info/rfc8020>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
Arends & Larson Expires 6 August 2023 [Page 9]
Internet-Draft DNS-ER February 2023
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020,
<https://www.rfc-editor.org/info/rfc8914>.
[RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
Name Minimisation to Improve Privacy", RFC 9156,
DOI 10.17487/RFC9156, November 2021,
<https://www.rfc-editor.org/info/rfc9156>.
Authors' Addresses
Roy Arends
ICANN
Email: roy.arends@icann.org
Matt Larson
ICANN
Email: matt.larson@icann.org
Arends & Larson Expires 6 August 2023 [Page 10]
