CONCEPT Cited by 1 source
NTA transparency¶
Definition¶
NTA transparency is the property that a DNS client receiving a response served under a Negative Trust Anchor can determine, from the response alone, that DNSSEC validation was bypassed.
RFC 7646 (the NTA specification) acknowledged this gap explicitly and recommended only out-of-band disclosure (status pages, operator mailing lists). Until July 2026, a response served under an NTA was indistinguishable from a fully validated one — leaving clients, monitoring tools, and users unable to tell whether the answer was cryptographically verified or not.
The gap¶
From the Cloudflare 2026-07-14 .AL incident post (Source: sources/2026-07-14-cloudflare-dnssec-nta-ede-33):
"What makes this harder is that, up until now, nothing in the DNS response signalled this to the client; a response served under an NTA looked identical to a fully validated one."
The gap is structurally problematic because: - Applications cannot differentiate a legitimate answer from a potentially spoofed one - Monitoring tools cannot alert on reduced security posture - Users must go looking for an out-of-band status page they may not know exists
Solution: EDE 33¶
The solution is in-band signalling via Extended DNS Errors (RFC 8914) code 33 — see patterns/ede-33-nta-disclosure. First deployed by Cloudflare's systems/cloudflare-1-1-1-1-resolver|1.1.1.1 during the July 3, 2026 .AL TLD outage.
Seen in¶
- sources/2026-07-14-cloudflare-dnssec-nta-ede-33 — first production deployment of EDE 33 to close the NTA transparency gap during the
.ALincident