Summary

  • RFC 9567 lets an authoritative server advertise an error-reporting agent in an unsolicited EDNS option. A supporting validating resolver turns its own Extended DNS Error observation into a separate TXT query; the original answer is neither repaired nor overruled.
  • The feedback is intentionally bounded. There is no end-to-end authentication between reporting resolver and monitoring agent, caches suppress repeats, long names may be dropped, and TCP or DNS Cookies improve source-address confidence without proving the diagnosis.

A zone has allowed one RRSIG to expire. Its authoritative server continues answering, but a validating resolver rejects the RRset. The operator sees queries and responses leaving the server; the resolver sees the failure after validation. Neither party has a normal relationship with the other. The most important fact exists precisely where the operator cannot observe it.

RFC 9567 creates a return route for that fact. The authoritative response can carry EDNS option code 18, Report-Channel, containing a fully qualified agent domain. The option is unsolicited: the resolver did not ask for it, and a resolver must never put it in a query. The authority may advertise one destination. It cannot compel a report.

If the resolver implements the mechanism, is configured to use it and assigns an Extended DNS Error, it constructs another DNS transaction. For an A query for broken.test that failed with EDE code 7, the report name can be _er.1.broken.test.7._er.a01.agent-domain.example. The resolver asks for TXT. The monitoring agent learns the failed QTYPE, name and diagnostic code from the QNAME itself.

That second query is the decisive design choice. The error does not travel backwards inside the failed response. It becomes an ordinary resolution event addressed to a separate authority. The response's RDATA is not the report; RFC 9567 assigns the TXT content no meaning. A positive answer mainly proves that the agent name resolved and gives caches a value with a TTL.

Four parties, four powers

The original authoritative operator chooses whether to publish an agent domain and where that domain sits. The reporting resolver owns the observation: it ran validation, selected an EDE code and decided that policy allowed reporting. The monitoring agent owns receipt, source-confidence checks and triage. The zone operator owns the change that might repair the underlying fault.

Those powers do not collapse because they share one wire format. The IANA DNS Parameters registry establishes that 18 means Report-Channel and that _er is reserved for this TXT use. Registration prevents code-point collision. It does not establish that a server advertises the option, a resolver sends reports, an agent is reachable or an operator acts correctly.

EDE is also bounded evidence. RFC 8914 says its extra information does not change RCODE processing. RFC 9567 does not decide what counts as an error and does not require every resolver to support every code. A report therefore means: this resolver says its process assigned this diagnostic to this QNAME and QTYPE. It does not mean every resolver failed, the zone alone caused the condition or the proposed repair is safe.

DNSSEC validation sharpens that distinction. An expired signature or broken DS/DNSKEY chain can be reproduced cryptographically, but a stale local trust anchor can make the reporting resolver itself the source of the problem. RFC 9567 explicitly warns that reporting may expose local resolver mistakes. The agent receives an observation about validation; it still has to reconstruct the chain from an independent vantage point.

A query name is a compact incident envelope

The report QNAME begins with _er, then carries the failed QTYPE as a decimal label, the non-null labels of the failed name, the EDE code, a second _er and the agent domain. Ordinary RCODE and DNS class are omitted. The first marker tells an agent that it has received the complete report rather than a shortened name revealed during minimised resolution. The second marker separates the failed name from the return address.

DNS places a hard boundary on that envelope. If the constructed name exceeds 255 octets, the resolver must not send it. If resolving the agent name causes another reportable failure, the resolver must apply a depth or expense limit. The feedback path is allowed to fail closed rather than convert one broken zone into recursive telemetry.

The agent domain must not sit beneath the domain it monitors. Otherwise the failure being reported can impair the reporting route itself. Keeping the agent domain short preserves room for the original name. These are not naming niceties; they are availability and recursion controls.

Transport can strengthen provenance, not truth

RFC 9567 does not authenticate the reporting resolver to the monitoring agent. A UDP source address can be forged, and the diagnostic can be false even when the address is real. A resolver should therefore use DNS over TCP or another connection-oriented transport, or attach a DNS Cookie. An agent receiving UDP without a Cookie should set TC and require a retry over TCP.

These mechanisms answer a narrow question: was the sender sufficiently reachable at this source address to complete a harder exchange? They do not prove which organization operated the resolver, whether its trust state was current, whether its EDE selection was correct or whether one report represents one user. Well-known resolver addresses can justify a higher confidence tier, but no global identity or remediation authority is created.

This separation matters for automation. A signed ticket from a known resolver, an unauthenticated UDP query, a successful Cookie exchange and ten reports hidden behind one cache entry should not enter the same queue with the same weight. Transport provenance is an input to judgement, not a replacement for it.

Silence can be load control or blindness

The monitoring agent is recommended to return a positive TXT answer. Its TTL dampens repetition: the same resolver may send roughly one report query per cached lifetime for the same encoded problem. This is how reporting remains cheap enough not to interfere with resolution. It also means report volume is not an incident counter.

Negative answers are more dangerous. RFC 8020 lets NXDOMAIN prove that names beneath the denied name do not exist, and RFC 2308 keeps that denial in cache. One mistaken NXDOMAIN from the agent can suppress different future report names. RFC 9567 therefore says the agent must not answer NXDOMAIN for monitored names; a wildcard is one possible positive-answer strategy.

A signed agent zone adds another interaction. RFC 8198 allows a validating resolver to synthesize negative answers from cached NSEC or NSEC3 evidence. Subsequent reports may never reach the agent. RFC 9567 notes that an unsigned agent domain can avoid that specific burden, while the resolver must still perform normal validation of responses so it does not assume that an actually signed victim domain is insecure.

The resulting metric has two clocks. Received queries measure what crossed the feedback path. Independent probes measure whether users can now validate. A fall in reports may mean repair, cache suppression, a dead agent, lost resolver support or a flood control. Only the second clock can show recovery.

The return route carries its own risks

A report reveals the failed name, type and EDE code to the monitoring agent. It may also reveal a stale local trust anchor or another resolver-side mistake. Query-name minimisation reduces disclosure to intermediate authorities, but the agent necessarily receives the complete incident name.

The mechanism also creates traffic that an adversary can steer. A deliberately broken zone can advertise an agent domain delegated to a victim. Open resolvers and distributed monitoring platforms can then emit reports toward that target. A flood of invented reports can hide a real failure. Agents must rate-limit, distinguish transport confidence, reject recursive loops and treat sudden source diversity as possible abuse rather than automatic proof of global impact.

Even TXT response data is hostile. RFC 9567 gives it no operational meaning and warns that logging arbitrary RDATA can expose the agent to string-processing attacks. The report is the query. A safe agent can answer with a fixed positive value and parse only the bounded labels it needs.

Heng Lu's distinctions among running code, minimum shared specification with localized decisions and reality layers fit this mechanism closely. The RFC defines a small return grammar. The authority advertises. The resolver observes. The network delivers or suppresses. The agent assesses. The operator repairs. The user either recovers or does not.

An audit should preserve those verbs separately. Record the original answer and validation state, advertised agent domain, constructed report name, drop reason, transport and Cookie state, agent response and TTL, independent reproduction, operator action and later validation result. Only that chain can turn a new question into accountable feedback.