DNS Error Reporting
Extracted elements (30)
Caching of the monitoring agent's response is essential to dampen the number of report queries sent for the same problem; with caching in place, only one report query per TTL is sent per unique error condition, rather than one per failing query.
The agent domain is recommended to remain unsigned (no DNSSEC) to avoid triggering aggressive negative caching (RFC 8198), which would use NSEC/NSEC3 records to synthesize negative answers from cache and suppress subsequent error-report queries to the monitoring agent.
The error is encoded entirely in the QNAME of the report query so that the very act of sending the DNS query constitutes the error report. This keeps reporting lightweight, with minimal impact on the resolver's main functions, and requires no new protocol beyond standard DNS.
If the monitoring agent responds with NXDOMAIN, RFC 8020 specifies that any name at or below that domain is considered unreachable; negative caching would then block all subsequent error-report queries for that subtree for the negative TTL duration. Implementations must avoid NXDOMAIN responses from monitoring agents for this reason.
When the agent domain is DNSSEC-signed, resolvers employing aggressive use of DNSSEC-validated cache (RFC 8198) can synthesize responses using NSEC/NSEC3 records, preventing report queries from reaching the monitoring agent even without an explicit cached answer.
A reporting resolver MUST NOT use DNS error reporting if the authoritative server returned an empty AGENT DOMAIN field in the EDNS0 Report-Channel option.
A reporting resolver MUST use a maximum expense or depth limit when performing additional DNS resolution to resolve the report query QNAME, in order to prevent cascading errors from triggering further error reports.
A reporting resolver MUST validate responses received from the monitoring agent; there is no special treatment for responses to error-reporting queries, and standard DNSSEC validation applies.
DNS error reporting SHOULD be performed using DNS query name minimization (RFC 9156) to improve privacy of the reporting resolver.
For the monitoring agent to gain more confidence that the report is not spoofed, the reporting resolver SHOULD send error reports over TCP (RFC 7766) or other connection-oriented protocols, or SHOULD use DNS Cookies (RFC 7873), making it harder to falsify the source address.
If the constructed QNAME of the report query exceeds 255 octets, the report query MUST NOT be sent.
If the RDATA content of a TXT record response is logged by the monitoring agent, the agent MUST assume the content can be malicious and take appropriate measures such as logging in hexadecimal to avoid exploitation (e.g., log4shell-style attacks).
The agent domain MUST NOT be a subdomain of the domain it is reporting on; for example, if the authoritative server hosts foo.example, its agent domain MUST NOT end in foo.example.
The authoritative server MUST NOT include more than one EDNS0 Report-Channel option in a single response.
The authoritative server MUST NOT include the EDNS0 Report-Channel option in a response if the configured agent domain is empty or is the null label (which would indicate the DNS root).
The EDNS0 Report-Channel option MUST NOT be included in queries; it is only sent unsolicited in responses by the authoritative server.
The monitoring agent MUST NOT respond with NXDOMAIN for domains it is monitoring, because an NXDOMAIN response would inhibit subsequent error-report queries via negative caching per RFC 8020. A wildcard domain name in the agent zone is one method to avoid this.
The monitoring agent SHOULD respond to queries received over UDP that have no DNS Cookie set with a response having the TC (truncation) bit set, challenging the resolver to requery over TCP.
DNS error reporting is performed without any authentication between the reporting resolver and the authoritative server of the agent domain. Query name minimization (RFC 9156) SHOULD be applied to error report queries to limit disclosure of the full QNAME to intermediate nameservers.
A monitoring agent is an authoritative server that receives and responds to report queries; it is identified by the agent domain returned in the EDNS0 Report-Channel option. Responses from the monitoring agent can be cached by the reporting resolver to dampen repeated queries for the same problem.
A report query is a DNS TXT record query sent by a reporting resolver to the monitoring agent; the error information is entirely encoded in the QNAME, so the act of sending the query constitutes the error report. No RCODE is included because the RCODE is not relevant to the extended DNS error code.
The EDNS0 Report-Channel option (OPTION-CODE 18) is included unsolicited by the authoritative server in responses to indicate the agent domain to which validating resolvers should send error reports. Its presence in a response signals that the authoritative server supports DNS error reporting.
IANA has assigned the entry '_er' for RR type TXT in the 'Underscored and Globally Scoped DNS Node Names' registry, referencing RFC 9567.
IANA has assigned value 18 with name 'Report-Channel' and status 'Standard' in the 'DNS EDNS0 Option Codes (OPT)' registry, referencing RFC 9567.
An adversary may create massive error report flooding to camouflage an attack. Monitoring agents that receive error reports over UDP should consider that the source addresses and report contents may be falsified.
DNSSEC validation of responses from the monitoring agent is mandated even when the agent domain is recommended to remain unsigned, to prevent downgrade attacks where a legitimately signed domain is deceptively advertised as an agent domain by a malicious actor, which would otherwise expose the resolver to cache poisoning.
This mechanism can be abused by intentionally deploying broken zones with agent domains delegated to victim nameservers, effectively using the reporting mechanism to generate a DNS query flood against victims. This is especially effective when used with open resolvers or globally distributed monitoring systems.
Use of DNS error reporting may expose local configuration mistakes in the reporting resolver—such as stale DNSSEC trust anchors—to the monitoring agent, since the error codes are derived from local resolver state.
The EDNS0 Report-Channel option (OPTION-CODE 18) carries a 2-octet OPTION-CODE, a 2-octet OPTION-LENGTH, and a variable-length AGENT DOMAIN field encoded as a fully qualified, uncompressed DNS wire-format domain name.
The report query QNAME is constructed by concatenating: the label '_er', the QTYPE as a decimal label, the non-null labels of the failed query name, the extended DNS error code as a decimal label, the label '_er' again, and finally the agent domain. If multiple QTYPEs are present they are represented as ordered decimal values separated by a hyphen in a single label (e.g., '1-28').