DNS Error Reporting

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. 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.

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 when, and only when, they appear in all capitals, as shown here.

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.

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 ), the label "_er" again, and the agent domain. See the example in . 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 and 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.

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), 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 . 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 could inhibit subsequent queries. One method to avoid NXDOMAIN is to use a wildcard domain name in the zone for the agent domain. When the agent domain is signed, a resolver may use aggressive negative caching (described in ). 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.

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.

EDNS0 Option Specification This method uses an EDNS0 option to indicate the agent domain in DNS messages. The option is structured as follows:

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 in uncompressed DNS wire format.

DNS error reporting specification The various errors that a reporting resolver may encounter are listed in . 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.

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.

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.

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.

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.

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.

IANA Considerations IANA is requested to assign the following DNS EDNS0 option code registry:

IANA is requested to assign the following Underscored and Globally Scoped DNS Node Name registry:

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 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 .

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.