ICANN

roy.arends@icann.org

ICANN

matt.larson@icann.org

dnsop Internet-Draft DNS Error Reporting is a lightweight error reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate, that a Domain Owner or DNS Hosting organization can use to improve domain hosting. The reports are based on Extended DNS Errors . 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 an agent specified by the authoritative server. DNS Error Reporting uses the DNS to report errors. Another lack of feedback occurs when validation was successful, or when there is no error to report. This positive feedback may be helpful to show that a deployment was successful. This document introcudes an extended DNS error “NO ERROR”.

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. 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 is buried in log files of the validating resolver, if these errors are logged at all. This document describes a facility that can be used by validating recursive resolvers to report errors in an automated way. In addition, successful validation, or a lack of errors can also be reported in an automated way. It allows an authoritative server to signal a reporting agent where the validating recursive resolver can report issues if it is configured to do so. The signal also indicates that the reporting agent is interested in successful validation, or lack of errors. The burden of reporting 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.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in .

Reporting Resolver: In the context of this document, the term reporting resolver is used as a shorthand for a validating recursive resolver that supports DNS Error Reporting. Reporting Query: The DNS query used to report an error is called a reporting query. A reporting query is for DNS resource record type NULL. The details of the error report are encoded in the QNAME of the reporting query. Reporting Agent: A facility responsible for receiving error reports on behalf of authoritative servers. This facility is indicated by a domain name. Reporting Agent Domain: a domain name which the reporting resolver includes in the QNAME of the reporting query. Positive Feedback: A report that indicates that no error occurred.

An authoritative server indicates support for DNS Error Reporting by including an EDNS0 option with OPTION-CODE [TBD] [RFC Editor: change TBD to the proper code when assigned by IANA.], a flag to indicate a request for positive feedback and the REPORTING AGENT DOMAIN in DNS wireformat in the option’s payload. The authoritative server MUST NOT include this option in the response if the configured reporting agent domain is empty or the null label (the root). The positive feedback flag indicates that the reporting agent wants to receive extended DNS error [TBD] that indicates that no error occurred. This extended DNS error is defined in this document. When a reporting resolver sends a reporting query to report an error, it MUST NOT include the EDNS0 Error Reporting option in the reporting query. This avoids additional compounding error reporting when there is an issue with the reporting agent domain. To report an error, the reporting resolver encodes the error report in the QNAME of the reporting query. The reporting resolver builds this QNAME by concatenating the _er label, the extended error code , the QTYPE and the QNAME that resulted in failure, the label “_er” again, and the reporting agent domain. See the example in section 4.2. The resulting concatenated domain name is sent as a standard DNS query for DNS resource record type NULL by the reporting resolver. This query MUST NOT have the EDNS0 option code [TBD] set to avoid compounding error notifications. The query will ultimately arrive at the authoritative server for the reporting agent domain. A NODATA negative response is returned by the authoritative server of the reporting agent domain, which in turn can be cached by the reporting resolver. This caching is essential. It ensures that the number of reports sent by a reporting resolver for the same problem is dampened, i.e. once per TTL, however, certain optimizations such as and may reduce the number of error reporting queries as well.

The reporting resolver may utilize various caching optimizations that inhibit subsequent error reporting to the same reporting agent domain. If the authoritative server for the reporting agent domain were to respond with NXDOMAIN (name error), rules state 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 authoritative server for an agent domain may not know the contents of all the zones it acts as an agent for, it is essential that the authoritative server does not respond with NXDOMAIN, as that may inhibit subsequent queries. The use of a wildcard domain name in the zone for the agent domain will ensure the RCODE is consistently NOERROR. Considering the Resource Record type for this wildcard record, type NULL is prohibited in master zone files . However, any type that is not special according to section 4 will do, such as a TXT record with an email address for the reporting agent in the RDATA. Wildcard expansion occurs, even if the QTYPE is not for the type owned by the wildcard domain name. The response is a “no error, but no data” response (, section 2.2.1.) that contains a NOERROR RCODE and empty answer section. Note that reporting resolvers are not expected to query for this TXT record, since reporting queries use type NULL. This record is solely present to ensure a NODATA response is returned in response to reporting queries. When the zone for the reporting agent domain is signed, a resolver may utilize aggressive negative caching, discussed 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 may not send subsequent queries as it will be able to synthesize a response from previously cached material. A solution is to avoid DNSSEC for the reporting 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.

The domain broken.test is hosted on a set of authoritative servers. One of these serves a stale version. This authoritative server has a severity level of 1 and a reporting agent configured: a01.reporting-agent.example. The reporting resolver is unable to validate the broken.test RRSet for type A, due to an RRSIG record with an expired signature. The reporting resolver constructs the QNAME _er.7.1.broken.test._er.a01.reporting-agent.example and resolves it. This QNAME indicates extended DNS error 7 occurred while trying to validate broken.test type 1 (A) record. After this query is received at one of the authoritative servers for the reporting agent domain (a01.reporting-agent.example), the reporting agent (the operators of the authoritative server for a01.reporting-agent.example) determines that the authoritative server for the broken.test zone suffers from an expired signature record (extended error 7) for type A for the domain name broken.test. The reporting agent can contact the operators of broken.test to fix the issue.

This method uses an EDNS0 option to indicate support for sending DNS error reports and responding with the Reporting Agent Domain in DNS messages. The option is structured as follows:

Field definition details: OPTION-CODE, 2-octets/16-bits (defined in ), for indicating error reporting support is TBD. [RFC Editor: change TBD to the proper code when assigned by IANA.] OPTION-LENGTH, 2-octets/16-bits ((defined in ) contains the length of the REPORTING AGENT DOMAIN field in octets. F, A flag to request positive feedback (i.e. to include the “No Error” extended DNS error defined in this document when reporting). REPORTING AGENT DOMAIN, a Domain name in the DNS wire format prescribed by .

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 an error and what is not. The DNS class is not specified in the error report.

Reporting Resolvers may have a configuration that allows the following: The reporting resolver MUST NOT use DNS error reporting to report a failure in resolving the reporting query. The reporting resolver MUST NOT use DNS error reporting if the authoritative server has an empty Reporting Agent Domain field in the EDNS Error Reporting option. The reporting resolver should limit the amount of positive feedback send.

The QNAME for the reporting 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 Extended DNS error, presented as a decimal value, in a single DNS label. 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. A label containing the string “_er”. The reporting agent domain. The reporting agent domain consists of multiple labels and is concatenated exactly as received in the EDNS option sent by the authoritative server. If the resulting reporting query QNAME would exceed 255 octets, it MUST NOT be sent. The “_er” labels allow the reporting agent to quickly 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 reporting query will have “_er” as a top-level domain as a result and not the original query. Lastly, the purpose of the first “_er” label is to indicate that a complete reporting query has been received, instead of a shorter reporting query due to query minimization.

The Authoritative Server SHOULD NOT have multiple reporting agent domains configured for a single zone. To support multiple reporting agents, a single agent can act as a syndicate to subsequently inform additional agents. An authoritative server for a zone with DNS error reporting enabled SHOULD NOT also be authoritative for that zone’s reporting agent domain’s zone.

It is RECOMMENDED that the reporting agent zone uses a wildcard DNS record of type TXT with an arbitrary string in the RDATA and a TTL of at least one hour.

It is RECOMMENDED that the reporting agent domain be kept relatively short to allow for a longer QNAME in the reporting query.

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

[RFC Editor: change TBD to the proper code when assigned by IANA.] IANA is requested to assign the following Underscored and Globally Scoped DNS Node Name registry:

IANA is requested to assign the following value the “Extended DNS Error Codes” registry: INFO-CODE: [TBD] Purpose: No Error Reference: This document

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

This document is based on an idea by Roy Arends and David Conrad. The authors would like to thank Peter van Dijk, Vladimir Cunat, Paul Hoffman, Libor Peltan, Matthijs Mekking, Willem Toorop, Tom Carpay, Dick Franks, Benno Overeinder and Petr Spacek for their contributions.

This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist.This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them. The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances.This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards. RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK] This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-TRACK] This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.This document obsoletes RFC 7719 and updates RFC 2308. This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server.