Tech

Why 1.1.1.1 Now Warns When DNSSEC Is Bypassed

Why 1.1.1.1 Now Warns When DNSSEC Is Bypassed

Terminal showing a 1.1.1.1 DNS query returning EDE 9 and EDE 33 codes for a .al domain

For a few hours on July 3, 2026, an entire country’s corner of the internet went dark for anyone using a security-conscious DNS resolver. Albanian government portals, banks, and news sites hosted under the .al country-code domain became unreachable — not because they were attacked, but because a routine cryptographic housekeeping task went wrong. The incident is a compact lesson in how DNSSEC protects you, how it can take a whole top-level domain down when it breaks, and why Cloudflare has just changed what its 1.1.1.1 resolver tells you when it papers over such a failure.

A key rollover that unravelled a whole TLD

DNSSEC works by building a chain of cryptographic trust from the DNS root down to individual names. The root zone stores a Delegation Signer (DS) record — essentially a fingerprint — for each signed top-level domain, and a validating resolver checks that the signing key a TLD actually serves matches that fingerprint. Break any link and every name beneath it fails validation.

That is precisely what happened to .al, which is operated by Albania’s communications authority AKEP and ranks #191 on Cloudflare Radar’s TLD ranking. According to Cloudflare’s incident writeup, the operator attempted a key rollover and, at around 14:15 UTC, published a brand-new signing key while pulling the old one — yet the DS fingerprint in the root still pointed to the old key (id=26319). Resolvers looked for a matching key, found none, and rejected every .al response. Around 17:00 UTC the operator removed the new key too, leaving the zone with no signing keys at all while the stale root fingerprint remained. Only at roughly 19:15 UTC, when the operator finally deleted the DS record from the root, did resolution recover — at the cost of leaving .al completely unsigned. As of Cloudflare’s publication, the DS record had still not been restored, meaning the whole TLD currently runs without DNSSEC protection.

Because 1.1.1.1, Cloudflare’s public resolver, validates DNSSEC by specification, it was obligated to return errors during the break. Every .al lookup failed with SERVFAIL, and the sites simply vanished for its users.

The blunt instrument: Negative Trust Anchors

Cloudflare’s fix is a tool defined for exactly this situation. A Negative Trust Anchor (NTA), standardized in RFC 7646, tells a resolver to treat a specific zone as unsigned and skip validation for it. Cloudflare had used the same measure just two months earlier when Germany’s .de suffered a comparable failure.

For .al, engineers first tried to reach the operator directly and posted to the DNS-OARC community channel — but got no reply, partly because AKEP’s own contact addresses live under .al and were themselves unreachable during the outage. Cloudflare then applied the NTA and rolled it out to all 1.1.1.1 users by 17:15 UTC, about three hours after the chain broke, and removed it the next day once the DS record was gone from the root.

The tradeoff is real: an NTA restores reachability by suspending the very cryptographic guarantee DNSSEC exists to provide. For the duration, .al answers were no longer protected against spoofing. Cloudflare judged that acceptable because the failure was public, confirmed, and hitting every validating resolver equally — better to serve real answers than a wall of errors.

The transparency gap NTAs leave behind

Here is the subtler problem, and the reason this incident matters beyond Albania. Until now, a response served under an NTA looked byte-for-byte identical to a fully validated one. The client got an answer with no signal that validation had been switched off. RFC 7646 recommends operators publicly disclose active NTAs, but that disclosure is out-of-band — a status page a human has to go find. An application, an uptime monitor, or an automated security check querying the resolver had no way to know, from the response alone, that it was now trusting an unverified answer.

EDE 33: making the bypass visible

Extended DNS Error (EDE) codes, defined in RFC 8914, let a resolver attach machine-readable context to any DNS response, success or failure. Babak Farrokhi at Quad9 proposed an Internet-Draft to signal an active NTA directly in the response via a new code, EDE 33 (Negative Trust Anchor); Cloudflare joined as a co-author and 1.1.1.1 now implements it. The .al incident was the first time it fired in production.

During the outage, a query like kdig @1.1.1.1 google.al returned a normal NOERROR answer — google.al still resolved — but carried two error codes alongside it: EDE 9 (DNSKEY Missing), surfacing the underlying broken chain of trust, and EDE 33 (Negative Trust Anchor), announcing that 1.1.1.1 had applied an NTA and served the answer anyway. Together they tell a client the plain truth: the answer is real, but it was not DNSSEC-validated.

Notably, 1.1.1.1 returns EDE 33 on every response generated while an NTA is active — even for a domain that never used DNSSEC — because the anchor covers the entire zone and transparency should apply uniformly. The change also fixed an earlier .de bug where the resolver returned a misleading EDE 22 instead of the real DNSSEC error.

What it means if you run a resolver or monitor DNS

If you operate services, the practical takeaway is to start reading EDE codes rather than treating a DNS answer as a simple pass/fail. A NOERROR response can now come with a footnote saying “trust suspended,” and tooling that checks for EDE 33 can flag when it is relying on unvalidated data and adjust risk accordingly — refusing to auto-approve a sensitive action, say, or raising an alert. For registry operators, the .al and .de episodes are a reminder that key rollovers are among the most dangerous routine operations in DNS: sequencing the DNSKEY and DS changes incorrectly can take an entire national domain offline in minutes.

Bottom line: DNSSEC’s strictness is a feature, not a bug — it refuses to hand you an answer it cannot verify. The .al outage shows the ugly flip side, where a single mismanaged key blacks out a whole TLD, and the new EDE 33 code is a small but meaningful fix: when a resolver has to choose reachability over verification, it now says so out loud instead of leaving you to guess.

We may earn commission from affiliate links at no extra cost to you. Last updated: Jul 19, 2026.
Jinultimate

Editor of ZBrandCo and the person accountable for what we publish — setting our sourcing standards, fact-checking claims against primary sources, and issuing corrections promptly across AI, open source, and gaming. Reach the desk at editorial@zbrandco.com.