Handling DNSSEC Failures with Negative Trust Anchors and EDE for DNS Transparency
This article discusses the operational challenges and architectural responses to DNSSEC validation failures, specifically focusing on the .AL TLD incident. Cloudflare's 1.1.1.1 DNS resolver employed Negative Trust Anchors (NTAs) to restore connectivity and introduced Extended DNS Error (EDE) codes to transparently signal when DNSSEC validation was bypassed, enhancing client visibility into DNS resolution outcomes.
Read original on Cloudflare BlogThe Challenge of DNSSEC Validation Failures
DNSSEC (Domain Name System Security Extensions) provides a chain of trust to ensure the authenticity of DNS responses. A misconfiguration, such as a mismatched Delegation Signer (DS) record in the parent zone (e.g., the root zone for a TLD) and the DNSKEY in the child zone (e.g., the .AL TLD), can break this chain. When this happens, validating DNS resolvers are mandated to reject responses, leading to service outages for affected domains. This was the case for the .AL TLD, rendering Albanian government services, banks, and media sites unreachable for users relying on validating resolvers like Cloudflare's 1.1.1.1.
Mitigation Strategy: Negative Trust Anchors (NTAs)
To restore service quickly during TLD-wide DNSSEC failures, recursive DNS operators can deploy a Negative Trust Anchor (NTA) as defined in RFC 7646. An NTA instructs the resolver to temporarily treat a specific zone as unsigned, bypassing DNSSEC validation and allowing queries for that zone to resolve. This is a crucial operational tool to maintain availability, but it comes with a security trade-off: responses under an NTA are no longer cryptographically verified, making them susceptible to DNS spoofing during the NTA's active period.
NTA Trade-offs: Availability vs. Security
NTAs are an aggressive measure. They prioritize availability over security during critical DNSSEC outages, suspending validation but exposing users to potential spoofing if the outage source is malicious. Operators typically apply them only after confirming a public, widespread failure.
Enhancing Transparency with Extended DNS Error (EDE) Codes
A significant limitation of NTAs was their silent operation: clients had no indication that DNSSEC validation had been bypassed. To address this, Cloudflare, in collaboration with Quad9, implemented a new Extended DNS Error (EDE) code (EDE 33: Negative Trust Anchor) as per RFC 8914. This EDE code is now included in DNS responses when an NTA is active, providing explicit signaling to clients, applications, and monitoring tools that the answer was served without DNSSEC validation. This transparency helps users understand the security posture of their DNS resolutions.
$ kdig @1.1.1.1 google.al
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 32848
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; EDE: 9 (DNSKEY Missing): 'no SEP matching the DS found for al.'
;; EDE: 33 (Negative Trust Anchor): 'a Negative Trust Anchor has been applied for this query (see RFC 7646)'
;; ANSWER SECTION:
google.al. 300 IN A 142.251.142.196The example above shows a DNS response for `google.al` under an active NTA. It returns `NOERROR` with the A record, but critically includes two EDE codes: EDE 9 (DNSKEY Missing) indicating the original DNSSEC failure, and EDE 33 (Negative Trust Anchor) explicitly stating that validation was bypassed. This level of detail is crucial for debugging and maintaining awareness of potential security implications.