On July 3, 2026, the Albanian communications authority (AKEP), the operator of the . AL country-code top-level domain (TLD) of Albania, 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 , the public DNS resolver operated by Cloudflare. 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) for . DE , temporarily suspending DNSSEC validation in 1. 1.
- 1 to keep domains reachable while the registry resolved the issue. We did the same for .
AL . NTAs restore resolution, but 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 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. The graph below shows the SERVFAIL and NOERROR rates for .
AL queries on 1. 1. 1.
1 throughout July 3. The SERVFAIL rate climbs as cached records expire and resolvers are forced to revalidate. It drops sharply when the NTA is applied at 17:15 UTC, restoring resolution.
What happened to . AL 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.
The root zone holds a Delegation Signer (DS) record for each signed TLD, a fingerprint of that TLD's DNSKEY. A resolver verifying . AL checks that the DNSKEY served by .
AL 's nameservers matches the DS record in the root. If it does, the resolver trusts that DNS responses from . AL 's nameservers are authentic.
The same pattern repeats one level down: . AL holds DS records for its signed child zones, each with a matching DNSKEY. A break anywhere in that chain, such as a DS record pointing to a key that no longer exists, causes validation to fail for everything below it.
Before the incident, the root zone held a DS record matching the DNSKEY served by the . AL nameservers, as illustrated below. At around 14:15 UTC, 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. Why Negative Trust Anchors are used Having a broken DNSSEC configuration can be painful, especially when it impacts an entire TLD at once. As we covered in our .
DE incident blog , recursive DNS operators can install a Negative Trust Anchor (NTA) as defined in RFC 7646 , which tells a resolver to treat a zone as unsigned and bypass validation. Before installing the NTA, we attempted to reach the . AL operator directly and posted on the DNS-OARC Mattermost to alert the community.
We received no response, in part because the operator's contact addresses were themselves under . AL , making them unreachable during the outage. We applied the NTA for .
AL and rolled it out to all 1. 1. 1.
1 users by 17:15 UTC, roughly three hours after the chain broke. The tradeoff is the same as it was for . DE : a Negative Trust Anchor suspends DNSSEC validation, which means .
AL domains were no longer protected against DNS spoofing for the duration. We judged this acceptable for the same reason: the failure was public, confirmed, and affecting every validating resolver equally. The Negative Trust Anchor was removed the following day, once the .
AL operator had removed the DS record from the root zone. With no DS record present, resolvers no longer expected DNSSEC for . AL and the NTA was no longer needed.
The problem with 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. An application, a monitoring tool, or a user querying 1.
- 1 had no way to tell, from the response alone, that DNSSEC validation was bypassed.
Originally published at blog.cloudflare.com
