After Albania's .al outage from broken DNSSEC rollover, 1.1.1.1 now discloses validation bypasses

In mid-July 2026, a routine security process for Albania's country-code top-level domain, .al, went wrong and knocked the entire domain offline. The cause was a failed DNSSEC rollover, the procedure that replaces the cryptographic keys used to sign .al's DNS records. On July 14, 2026, Cloudflare engineer Sebastiaan Neuteboom published a detailed incident report explaining how the company's public DNS resolver, 1.1.1.1, has now started telling users when it deliberately bypasses DNSSEC validation. The new signal appears as Extended DNS Error code 33, also called EDE 33, and it makes previously invisible "Negative Trust Anchors" visible to everyone affected.

First, a quick reminder of the basics. The Domain Name System, or DNS, is the internet's phone book: it converts human-friendly names like google.al into numeric IP addresses that computers use to connect. DNSSEC, short for Domain Name System Security Extensions, adds a layer of digital signatures to DNS records so that a resolver, the server that performs this lookup, can verify that the answer has not been altered by an attacker. When DNSSEC is working correctly, a resolver follows a chain of trust from the root of the DNS all the way down to the specific domain. If any link in that chain is broken, validation fails and the resolver normally returns an error. However, a Negative Trust Anchor, or NTA, is a manual configuration that tells a resolver to temporarily treat a specific zone, such as .al, as if it were not signed by DNSSEC at all. Resolver operators use NTAs when a zone's DNSSEC setup is misconfigured or broken, to keep the zone's domains reachable for users while the underlying problem is fixed. Until now, this bypass happened silently, leaving users, website owners, and monitoring tools with no idea that their DNS responses had not been fully validated.

Cloudflare's report shows what this looks like in practice using the example domain google.al. When 1.1.1.1 receives a query for google.al during an active NTA for the .al zone, it returns a normal answer with the status code NOERROR, which means the query succeeded. But attached to that answer are two Extended DNS Error codes. The first, EDE 9, is called DNSKEY Missing and reveals the actual DNSSEC failure: the chain of trust was broken, so validation could not succeed. The second is the new EDE 33, which stands for Negative Trust Anchor and tells the client that 1.1.1.1 applied a Negative Trust Anchor and served the answer anyway. Together, these two codes give full transparency: the response is genuine and complete, but it was not validated with DNSSEC. Because the NTA covers the entire .al zone, 1.1.1.1 returns EDE 33 on any response generated while the NTA is active, even for a domain under .al that does not use DNSSEC at all. This is intentional, Cloudflare explains, because the NTA applies to the whole zone and the resolver wants to be equally transparent about every response served under it.

The new code also fixes an earlier reporting problem from a similar incident in Germany's .de top-level domain. In that previous case, 1.1.1.1 incorrectly returned EDE 22, which means No Reachable Authority, instead of surfacing the underlying DNSSEC error. During the .al incident, the resolver correctly returned EDE 9 alongside EDE 33, giving a precise picture of what went wrong. The Internet-Draft that defines EDE 33 was submitted as an individual contribution to the Internet Engineering Task Force (IETF) DNS Operations, or DNSOP, Working Group. The Internet Assigned Numbers Authority, IANA, has already assigned the code number 33. Cloudflare thanks Babak Farrokhi at Quad9, a co-author of the draft, and notes that the kdig command-line tool from the Knot project now recognizes EDE 33 by name. A pull request to add the same support to the Unbound DNS resolver is under review. The draft will be discussed at the IETF meeting in Vienna from July 18 to July 24, 2026.

This development matters because top-level-domain DNSSEC failures, while rare, affect every domain under the broken TLD at the same time and every validating resolver equally. The .al incident, coming soon after .de, demonstrates that Negative Trust Anchors are a necessary operational tool. But until EDE 33, their use was invisible to end users. By adding this code, 1.1.1.1 closes a gap left open by RFC 7646, the standard that originally defined how resolvers should handle DNSSEC validation failures. Now a response served under a Negative Trust Anchor says so directly, giving operators, monitoring tools, and ordinary users the information they need to understand exactly what the resolver did and why. The Internet-Draft is available on the IETF datatracker, and feedback can be sent to the DNSOP mailing list. Cloudflare also points readers to its "How does DNSSEC work?" page for more background and to Cloudflare Radar for real-time DNS trends and TLD data.

For website owners and IT teams, the lesson is clear: DNSSEC misconfigurations can take down an entire top-level domain, so regular monitoring and careful key rollover planning are essential. For everyday internet users, choosing a resolver that reports EDE codes gives you a way to see when your DNS answers have not been fully validated. A privacy-first encrypted DNS service such as AEU DNS adds another protective layer by encrypting your DNS lookups end to end, and its support for DNSSEC and extended error codes means you get similar transparency when something goes wrong. By paying attention to these signals, you can avoid being misled by a network problem or a DNS-level attack.