Summary

  • EDE 33 says that a covering negative trust anchor was in effect when a resolver generated a response; it does not say the exception changed that response or that the returned data is authentic.
  • Leaders should preserve six separate receipts—configuration, coverage, disclosure, validation, transport and application outcome—before treating the signal as operational evidence.

The exception has acquired a witness

A DNSSEC validation failure creates an awkward operational choice. Leave the protection intact and users may lose access to a domain whose signatures are merely misconfigured. Suspend validation and access may return, but the resolver has deliberately stopped making one of DNSSEC's central checks. RFC 7646 made that compromise explicit by defining a negative trust anchor, or NTA, as a local and temporary exception for a bounded name.

Until now, the exception could be difficult for the recipient of a response to see. The operator might publish an NTA list on a website, but the DNS message carried no dedicated statement that the resolver had generated it under an active exception. The new DNSOP working-group draft, Disclosure of Negative Trust Anchors in DNS Responses, proposes a narrow answer: Extended DNS Error code 33, “Negative Trust Anchor”. Revision 00 is dated 23 September 2026. It is work in progress, not an RFC or final IETF consensus.

The useful fact is precise. A response containing EDE 33 was generated while a covering NTA was in effect. The signal belongs to a recursive resolver that has an NTA configured; an authoritative-only server, which does not validate, should not manufacture it. An operator applying an NTA should expose the code in affected responses so users and applications can know that the answer may not have been DNSSEC-validated.

That is a real gain in observability. It also stops exactly where the hard questions begin.

Disclosure is not authentication

The draft text calls EDE diagnostic. A client must not change protocol processing merely because the code is present, and the code does not change handling of the Authenticated Data bit. This follows the architecture of RFC 8914: an Extended DNS Error adds context to a DNS response; it does not replace the RCODE or become a new command channel.

More importantly, EDE 33 does not prove causation. A resolver may include it on responses while an NTA is active even when that exception had no material effect on the contents. The code therefore cannot answer the counterfactual question: would this query have failed validation without the NTA? Resolver logs or a controlled validation replay must answer that.

Nor does the code authenticate the DNS data. The NTA exists precisely because ordinary validation has been suspended for a scope. RFC 4035 describes the validator's work and security states; EDE 33 does not recreate a chain of trust that the resolver chose not to require. It merely tells the recipient that the choice was active.

The disclosure itself is not inherently signed. The draft warns that an on-path actor can add, remove or modify an EDE. TSIG, SIG(0), DNS over TLS or DNS over HTTPS can protect a relevant message or hop, but even an intact EDE proves only what the identified resolver reported. It does not prove that the domain operator made an innocent mistake, that the resolver operator investigated competently, or that the returned address leads to the intended service.

Six receipts, not one green light

An audit record should therefore separate six things.

First is the configuration receipt: the exact owner name covered by the NTA, the operator that installed it, the incident evidence, the approver, the creation time and the intended expiry. RFC 7646 requires limited duration and treats broad or indefinite exceptions as a failure of the mechanism.

Second is the coverage receipt: evidence that this QNAME and response were actually under the configured anchor. An NTA on an ancestor may cover a subordinate query, and multiple anchors may apply. Scope cannot be reconstructed safely from the visible answer alone.

Third is the disclosure receipt: the raw response, resolver identity, observation time and every EDE 33 instance. The draft allows multiple instances and requires each to carry EXTRA-TEXT when several appear. Optional structured fields may name the configured domain as d and give an indicative time as t. The time deserves generous flexibility; it is not a guaranteed removal event.

Fourth is the validation receipt: AD and CD flags, validator logs and a controlled result without the exception. The EDE does not change AD processing, and its presence alone says nothing conclusive about what the normal validator would have decided.

Fifth is the transport receipt: whether the client-to-resolver path protected the EDE against stripping or alteration. This establishes message provenance only within the protected context. It does not convert operator judgment into cryptographic fact.

Sixth is the application receipt: what the stub resolver and application actually received, displayed and used. A DNS response can arrive while the application fails, selects another address, refuses the content or connects to the wrong endpoint. Resolution and service outcome remain different events.

Collapsing those receipts creates a dangerous sentence: “the resolver said NTA, therefore the answer is safe.” The correct sentence is smaller: “this resolver reported that an NTA covered the response at this time.” Everything else needs evidence.

Metadata has a privacy boundary

EDE 33 can make an exception more accountable, but it can also disclose incident detail. EXTRA-TEXT may explain the name, reason, reference or expected duration. The draft says it is for humans, should remain readable and should omit private or sensitive information. A helpdesk ticket, customer identifier, internal hostname or unannounced incident plan does not become safe merely because it fits in a DNS option.

The structured d and t fields improve machine visibility without changing that boundary. d identifies where the operator says the NTA is configured; it does not prove ownership of the domain. t records an indicative horizon; it does not remove the configuration or certify that the operator reviewed it. Useful metadata makes drift easier to discover. It does not make drift impossible.

A minimum signal, not a central licence

The governance design should stay narrow. The IETF can define a common code that makes a local exception observable. Resolver operators still bear the decision to install it, because they see the incident, serve the affected users and carry the security consequence. Domain operators retain responsibility for repairing authoritative DNSSEC. Clients decide how to surface diagnostics but must not turn the code into an instruction to trust.

This is the division described by Heng Lu's case for a minimum initial specification and localized future decisions. The common layer should carry the smallest interoperable fact. It should not become a global tribunal for exceptions. His distinction between authority and belief also matters here: a standardized label can identify a speaker and statement without making the statement true. And Running-Code Primacy demands more than publication of revision 00. Deployment claims require packets, versions, forwarding paths, client behavior and removal evidence.

Draft status and limits

The examples in revision 00 show resolvers returning EDE 33. They are useful demonstrations, not a census of support. Forwarders may discard or recreate EDE. UDP size pressure may remove supplemental options. Stub resolvers and applications may never expose them. The text may change before publication, and a later revision may alter code semantics or structured fields.

The proposal nevertheless improves the evidence surface. It gives a hidden weakening of validation a standardized witness. Leadership value comes from refusing to promote that witness into a verdict.

Sources