## Understanding Recent DNSSEC Challenges with .AL and the Path to Transparency
On July 3, 2026, the Albanian communications authority (AKEP), operator of the .AL country-code top-level domain (TLD), attempted a DNSSEC key rollover. Something went wrong, resulting in DNSSEC validation failures. Any validating DNS resolver receiving these signatures was required by the DNSSEC specification to reject them and return errors to clients. That includes 1.1.1.1, the public DNS resolver operated by Cloudflare.
### What Happened with .AL
The .AL TLD is the online home of Albanian government services, banks, and media; it ranks #191 on Cloudflare Radar’s TLD ranking. Anyone trying to visit those sites, using a validating resolver, found them unreachable during the incident. The failure had the potential to affect every .AL domain, regardless of where it was hosted or which authoritative nameservers served it.
Just two months earlier, a similar incident struck .DE, the TLD of Germany. As we described in our blog post on the incident, our response was to install a Negative Trust Anchor (NTA), temporarily suspending DNSSEC validation in 1.1.1.1 to keep domains reachable while the registry resolved the issue. We did the same for .AL.
### The Problem with Negative Trust Anchors
While NTAs restore resolution, they do so silently. A client receiving a response served under an NTA has no way to tell, from the response alone, that DNSSEC validation was bypassed, leaving it unable to distinguish a legitimate answer from a spoofed one. For the .AL incident, 1.1.1.1 addressed that gap for the first time, returning a new Extended DNS Error (EDE) code alongside every affected response to signal that the answer was not DNSSEC-validated due to the presence of an NTA.
We discussed how DNSSEC works in more detail in our prior blog post. A brief recap: DNSSEC builds a chain of trust from the root zone down to individual domain names. A break anywhere in that chain causes validation to fail for everything below it.
During the incident, the .AL operator published a new DNSKEY and stopped serving the old one. The DS record in the root zone still pointed to the old DNSKEY (id=26319), so any resolver attempting to validate .AL responses found no matching key and failed. At roughly 17:00 UTC, the .AL operator removed the new DNSKEY without restoring the old one. The zone now had no DNSKEY records at all, while the DS record in the root still pointed to id=26319, and resolution continued to fail.
At roughly 19:15 UTC, the .AL operator removed the DS record from the root zone. Without a DS record, resolvers no longer expected DNSSEC validation for .AL, and resolution was restored, though the entire TLD was now unsigned. As of publishing, .AL remains unsigned. The DS record has not been restored to the root zone by the .AL operators. Without a DS record, every .AL domain is unable to use DNSSEC protections.
### Bringing Transparency to Negative Trust Anchors
Installing a Negative Trust Anchor is an aggressive measure. We suspend DNSSEC validation to keep domains reachable, accepting that responses are no longer cryptographically verified for the duration. Users get answers instead of SERVFAIL, but those answers carry no DNSSEC guarantee.
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. RFC 7646 acknowledges this gap and recommends that operators publicly disclose which NTAs they have in place, but that disclosure is out-of-band. For both the .DE and .AL incidents we published status pages, but a status page requires the user to go looking.
Extended DNS Error (EDE) codes, defined in RFC 8914, allow resolvers to include additional context alongside any DNS response, whether that is an error or a successful answer. Babak Farrokhi at Quad9 proposed an Internet-Draft to signal the presence of a Negative Trust Anchor directly in the DNS response, using a new EDE code: Disclosure of Negative Trust Anchors in DNS Responses. We joined as co-authors, and 1.1.1.1 now implements it.
During the .AL incident, any query for a .AL name returned both the answer and the new EDE code while the Negative Trust Anchor was installed. Here is what that looked like:
“`
$ 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.196
```The response is a NOERROR with a valid answer: google.al resolves, but two EDE codes accompany it. EDE 9 (DNSKEY Missing) surfaces the underlying DNSSEC failure: the chain of trust was broken and validation failed. EDE 33 (Negative Trust Anchor) signals that 1.1.1.1 applied a Negative Trust Anchor and served the answer anyway. Together they give clients and operators full visibility into what happened: the answer is real, but it was not DNSSEC-validated.1.1.1.1 returns EDE 33 on any response generated while an NTA is active, regardless of whether the query itself would have failed DNSSEC validation. A query for a domain that does not use DNSSEC at all will still carry EDE 33 if it falls under an active NTA. This is intentional: the NTA covers the entire zone, and transparency applies equally to every response served under it.This also resolves an issue we flagged in our .DE blog, where 1.1.1.1 incorrectly returned EDE 22 (No Reachable Authority) instead of surfacing the underlying DNSSEC error. During the .AL incident, 1.1.1.1 correctly returned EDE 9 (DNSKEY Missing) alongside EDE 33.The Internet-Draft is an individual submission and EDE 33 has been assigned by the Internet Assigned Numbers Authority (IANA). Thanks to our co-author, Babak Farrokhi at Quad9, the kdig tool from the Knot project now recognizes EDE 33 by name, and a pull request for Unbound is under review. We hope other resolver implementations follow. The Internet-Draft has been submitted to the Internet Engineering Task Force (IETF) DNSOP Working Group, and will be discussed at the IETF meeting taking place in Vienna from July 18 to July 24.### Frequently Asked Questions (FAQ)**What is DNSSEC and why is it important?**
DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS records, ensuring that responses come from the legitimate owner and haven’t been tampered with. It creates a chain of trust from the root zone down to individual domains.**What is a Negative Trust Anchor (NTA)?**
An NTA is a mechanism used by DNS resolvers to tell the system to treat a specific zone as unsigned, bypassing DNSSEC validation. It’s used as an emergency measure when a DNSSEC failure makes a domain unreachable.**Why was an NTA necessary for .AL?**
After a botched DNSSEC key rollover, .AL lacked valid DNSKEY records or had a broken chain of trust. Without an NTA, all .AL domains would have remained unreachable for validating resolvers.**How does 1.1.1.1 signal that an NTA has been applied?**
1.1.1.1 now includes an Extended DNS Error (EDE) code 33 in DNS responses served under an NTA, explicitly informing clients that validation was bypassed.**What is EDE 9 (DNSKEY Missing)?**
EDE 9 indicates that the resolver could not find the expected DNSKEY matching the DS record in the parent zone. It helps pinpoint the specific DNSSEC validation failure.**Will my applications notice when an NTA is applied?**
Yes, with the new EDE codes, applications and monitoring tools can detect when DNSSEC validation has been bypassed, improving transparency and trust.**What can I do to prepare for DNSSEC incidents?**
Operators should monitor DNSSEC status, plan for key rollovers, and have communication channels ready. Recursive resolvers can implement EDE signaling to improve visibility.**Where can I learn more about DNSSEC?**
You can visit Cloudflare’s documentation on How DNSSEC Works, and follow real-time DNS trends on Cloudflare Radar.## ConclusionThe .AL DNSSEC incident underscores the fragility of DNSSEC when things go wrong and the critical role that operational tools like Negative Trust Anchors play in keeping the internet accessible. While NTAs are necessary in emergencies, they come with a tradeoff: suspending DNSSEC protection across an entire zone.Thanks to the implementation of Extended DNS Error code 33, there is now a way to signal when an NTA is in use directly within DNS responses, bringing transparency to an otherwise silent mechanism. This marks an important step forward in operational resilience and user awareness.As TLD-level DNSSEC failures remain rare, the industry must continue improving communication, tooling, and standards. The collaboration between Cloudflare, Quad9, and the IETF demonstrates how coordinated efforts can lead to practical solutions that benefit the entire ecosystem. Moving forward, EDE 33 will help ensure that both operators and users know exactly when DNSSEC protections are paused—and why.
