Summary

  • DNSOP opened a Working Group adoption call for draft-farrokhi-dnsop-ede-nta-01 on 2 September. It closes on 16 September; the draft is not yet adopted or published as an RFC.
  • EDE 33 reports that a covering Negative Trust Anchor was active when a response was generated. The draft permits the signal even when the NTA did not materially affect the response.
  • A narrow effect receipt should preserve the EDE source, protected-hop state and a contemporaneous no-NTA validation observation—or say that no counterfactual was measured—without duplicating the operator’s separate authorization and expiry record.

The code exists before the adoption result

The DNSOP call asks whether the Working Group should take responsibility for a document about disclosing Negative Trust Anchors in DNS responses. It began on 2 September and ends on 16 September. At this research cutoff, the Datatracker still says Call For Adoption By WG Issued. Revision 01 is an active individual Internet-Draft with Informational intended status, not an RFC or a completed IETF decision.

One part is already operationally concrete. The IANA DNS Parameters registry lists Extended DNS Error code 33 as Negative Trust Anchor. That registration gives implementations a common number. It does not settle the Working Group call, freeze revision 01 or show which resolvers emit the code.

That separation is normal in protocol work and easy to lose in a headline. An assigned value prevents implementations from guessing incompatible numbers. A Working Group decision determines document custody. An RFC would record a later publication state. Deployment is yet another fact. None can stand in for the others.

What an NTA changes

RFC 7646 defines a Negative Trust Anchor as local resolver behaviour. At a selected name, a validating recursive resolver stops following the ordinary DNSSEC authentication chain and treats covered responses as though the zone were unsigned. It does not repair the zone, change the parent delegation or make the resolver authoritative for the name.

The exception is deliberately constrained. Use must not be automatic. Trained personnel should distinguish likely misconfiguration from possible attack, avoid intentionally broken test domains and make a reasonable attempt to contact the zone operator. The NTA should stay within the affected branch. The RFC recommends repeated validation attempts, automatic expiry, a lifetime no longer than one week, prompt removal after validation succeeds and cache clearing beneath the NTA node.

Those are operator-lifecycle duties. Earlier BTW coverage already examined who authorizes the exception, what evidence supports it, when it expires and what proves removal. The present question begins one layer later: what can a recipient infer from a particular answer carrying the new diagnostic?

What EDE 33 actually says

The current draft says that one or more instances of EDE 33 mean the response was generated while a covering NTA was in effect. It remains diagnostic. It does not change AD-bit processing, and an authoritative-only server should not send it merely because it can encode an EDNS option.

An operator applying an NTA should return the code in affected responses. The important sentence follows: a resolver may include EDE 33 on any response while an NTA is active, regardless of whether the NTA had a material effect on the response contents.

Suppose a resolver has an NTA at example. One queried name would fail ordinary DNSSEC validation and becomes reachable only because the exception is active. A second queried name beneath the same point validates successfully even without the NTA. Both answers may carry EDE 33. The first signal accompanies a changed outcome; the second reports environmental state. The wire code alone cannot distinguish them.

That is not a defect hidden in small print. It avoids requiring a resolver to run and compare two validation paths for every answer merely to emit a transparency signal. It also prevents recipients from treating the code as a causal verdict.

Optional context remains optional

EDE has an EXTRA-TEXT field. Revision 01 says an operator may use it for the configured name, a reason, a reference or expected duration. With the structured-error convention, d identifies the domain where an NTA was configured and t supplies an indicative time until which it might remain in place.

Neither field completes the missing proof. d can identify the covering exception without showing that it changed this response. t is an expectation, not a signed removal event. A reason written for people is not an authorization record. Multiple NTAs may yield multiple EDE 33 instances; if they do, each instance needs text, but a list of candidates still does not identify the causal one.

RFC 8914 adds two more limits. EDE is supplemental and must not alter DNS processing. Its contents are unauthenticated unless protected by a suitable DNS transaction or transport mechanism. A forwarder may suppress an EDE, pass it onward or create another one; attribution should identify the source, but the last hop can still look like the speaker to the client.

The correct reading is therefore modest: “the responding system says an NTA covered this response at generation time.” It is not “the zone was broken,” “the NTA was justified,” “this answer would otherwise have failed” or “the exception is still active now.” Absence is not the opposite proof either, because emission is recommended rather than compulsory and intermediaries can remove the option.

The example changed while the draft stayed still

The adoption thread supplied an unusually useful demonstration of this boundary. Revision 01 contains an example built around an NTA and an intentionally bogus child delegation. In a 2 September reply, co-author Joe Abley warned reviewers that Cloudflare’s default machinery kept repairing the delegation or removing the zone cut. The example therefore no longer matched the intended live condition at that moment, and he said the authors would fix it.

This is not evidence of an outage or a failed production control. It is evidence that an explanatory environment has its own state. A stable draft can point to a moving DNS configuration; an automated repair can make the example’s original counterfactual disappear. A reviewer who sees EDE 33 still needs to know what ordinary validation would have done at the observation time.

Earlier implementation discussion made the same point from the wire. A live response showed EDE 33 but did not identify whether the NTA sat at the queried name or an ancestor, whether several NTAs existed or whether the response would have validated anyway. The diagnostic was truthful within its scope and incomplete outside it.

Add an effect receipt, not more meaning to the code

The protocol should not carry an incident file. Client addresses, query histories, subscriber identifiers, internal tickets and security-sensitive diagnostics do not belong in public EXTRA-TEXT. The missing evidence can live in a narrow NTA effect receipt. This is my editorial proposal, not an IETF, IANA or operator requirement.

For a sampled response or incident observation, the receipt can bind a time and response fingerprint; the resolver or forwarder role that emitted the EDE; the protected-hop state; the EDE 33 instance and any disclosed d or t; the AD state; a contemporaneous validation result with the NTA disabled in an isolated test path, or an explicit not measured reason; whether the returned data or outcome differed; and a reference to the operator’s separate authorization-and-expiry record.

The receipt must not require a second live answer for every user query. Operators can sample, reproduce safely or record that a counterfactual was unavailable. “Not measured” is better than converting presence into causality. Public reporting can aggregate effect classes while keeping names and incident evidence protected where disclosure would create risk.

Heng Lu’s Policy Mirror asks which actor, rule and evidence support a claimed state. Here IANA controls the code registry, the IETF process controls the document state, the resolver operator controls the NTA and the client sees a diagnostic from a particular path. Running Code Primary adds the necessary discipline: the actual comparison belongs to an observed resolver state, not to the aspiration carried by a draft.

EDE 33 makes a consequential exception less invisible. Its credibility improves when it refuses to say more than was observed. The code can disclose presence. Only a separate, bounded comparison can show effect.

Sources

  1. DNSOP Working Group adoption call
  2. Current IETF Datatracker record
  3. Disclosure of Negative Trust Anchors in DNS Responses, revision 01
  4. Datatracker document history
  5. Joe Abley’s example-state disclosure
  6. Implementation-boundary discussion
  7. RFC 7646 — Definition and Use of DNSSEC Negative Trust Anchors
  8. RFC 8914 — Extended DNS Errors
  9. IANA DNS Parameters
  10. DNSOP Working Group record
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Running Code Primary