The domains were still delegated. The nameservers still answered. But once DENIC published invalid DNSSEC signatures for .de, validating resolvers had to treat the answers as bogus and return SERVFAIL.
The domains were still delegated. The nameservers still answered. What broke was trust: once DENIC published invalid DNSSEC signatures for .de, validating resolvers had to treat those answers as bogus. For users behind resolvers that enforced DNSSEC, a working German domain could suddenly look indistinguishable from a forged one.
That is the uncomfortable bargain DNSSEC makes. It protects DNS by making resolvers prove that an answer follows the chain of trust from the root down through each parent zone. For .de domains, the .de registry sits directly in that chain. If the top-level domain publishes signatures that cannot be validated, the resolver cannot safely accept answers for names below it. The correct response is SERVFAIL.
The failure started around 19:30 UTC on May 5, 2026, according to Cloudflare. The first spike was immediate, but the outage spread in stages. Many .de answers were already cached inside recursive resolvers, and those continued working until their TTLs expired. As each cached answer aged out and the resolver fetched fresh data, it received broken signatures from the .de zone and began failing validation. Retries then inflated query volume, which made the graphs look worse than the number of distinct affected users.
Cloudflare's first cushion was serve stale. When upstream resolution failed, 1.1.1.1 could keep returning expired cached answers instead of immediately returning SERVFAIL. That preserved availability for names already in cache, but it could not help every lookup. New names, missing cache entries, and records without usable stale data still failed.
The stronger mitigation required a security tradeoff. Cloudflare's resolver did not have a native Negative Trust Anchor mechanism, so engineers used an existing override rule to mark .de as insecure. In practice, that told 1.1.1.1 to resolve .de as if DNSSEC were not enabled. Cloudflare rolled out the mitigation at 22:17 UTC, ending impact for 1.1.1.1 users while DENIC continued repairing the zone.
The hard part of this incident was not deciding whether DNSSEC mattered. It was deciding when a known-broken trust chain was providing no useful protection. Returning SERVFAIL preserved the strict security model. Temporarily bypassing validation restored access while accepting unvalidated answers. DNSSEC did not fail because validation rejected bad signatures; the operational gap was needing an exception path when a parent zone made every child domain look invalid.
There is no user of 1.1.1.1 resolving a .de name right now who would prefer a SERVFAIL over an unvalidated response.// Cloudflare internal incident room, quoted in Cloudflare's post
Cloudflare reports that DENIC, the .de registry operator, began publishing incorrect DNSSEC signatures for the .de zone. Validating resolvers that received those signatures had to reject the answers and return SERVFAIL.
After 19:30 UTC
Failures grow as caches expire
SERVFAIL responses spike immediately, then keep climbing for about three hours. Cached .de records continue working until their TTLs expire; fresh lookups get broken signatures and fail validation.
During the outage
Serve stale cushions the impact
1.1.1.1 continues serving expired cached .de records when upstream resolution fails. Those stale responses keep some users receiving valid answers even while fresh DNSSEC validation is broken.
During mitigation
Cloudflare chooses a DNSSEC exception
Cloudflare's resolver did not have a native Negative Trust Anchor mechanism, so engineers used an existing override rule to mark .de as an insecure zone.
22:17 UTC
1.1.1.1 impact ends
Cloudflare rolls out the .de override for 1.1.1.1, causing .de queries to resolve as if DNSSEC were not enabled. Cloudflare says this marked the end of impact for 1.1.1.1.
May 6
DENIC restores the zone
DENIC says it initiated distribution of a correct DNS zone at 00:08 on May 6 and restored the pre-outage operational state by 01:15. DENIC later linked the outage to a routine scheduled key rollover.
A parent-zone signature failure broke validation below it.
DNSSEC makes DNS answers fail closed. A resolver checks more than whether a nameserver returned an answer; it also checks whether the signatures prove that answer belongs in the DNS chain of trust. For a .de domain, that chain runs through the .de top-level domain. When the parent zone's signatures became invalid, validating resolvers had to reject answers for domains below .de even when those individual domains had done nothing wrong.
DENIC later said the outage was linked to a routine scheduled key rollover. During that process, non-validatable signatures were generated and distributed. Cloudflare reports that at about 19:30 UTC on May 5, 2026, validating resolvers began receiving incorrect DNSSEC signatures for the .de zone. 1.1.1.1 followed the DNSSEC specification and returned SERVFAIL for records it could not validate.
Cloudflare had two layers of response. First, serve stale kept some cached .de answers working after their TTLs expired, which slowed the spread of visible failures. Then Cloudflare used an override rule to treat .de as an insecure zone, functionally similar to a Negative Trust Anchor. That restored resolution for 1.1.1.1 users, but only by temporarily accepting unvalidated .de answers while DENIC repaired the zone.
What turned a signing problem into a TLD-wide failure.
01
The failure sat high in the DNS hierarchy
The broken signatures were in the .de zone, not in one customer domain. A validation failure at that level affects everything below it, so the blast radius follows the DNS tree rather than the hosting provider, registrar, or individual application.
02
DNSSEC correctly failed closed
Validating resolvers were not malfunctioning when they returned SERVFAIL. Once the signatures could not be validated, the DNSSEC specification required them to reject the answers. The protection worked as designed, but the invalid data came from a place every .de answer depended on.
03
Cache expiry made impact grow over time
The outage did not hit every user at the same moment. Cached records continued to work until their TTLs expired. As resolvers went back to DENIC for fresh copies, they received invalid signatures and began returning SERVFAIL.
04
Serve stale bought time, but could not fix fresh misses
1.1.1.1 served expired cached records when upstream validation failed, which kept some queries returning good answers. That helped users whose records were already in cache. It could not help names that were not cached or cases where no usable stale answer existed.
05
The resolver lacked a native NTA path
Cloudflare says Big Pineapple, the resolver behind 1.1.1.1 and related products, did not have a native Negative Trust Anchor mechanism at the time. Engineers used an existing override rule to mark .de as insecure, which achieved the same practical result but was not the standard RFC-defined mechanism.
06
Error details pointed at the wrong class of problem
Before mitigation, 1.1.1.1 returned Extended DNS Error 22, No Reachable Authority, instead of DNSSEC Bogus. Cloudflare traced this to a bug in how DNSSEC error codes propagated from its trust-chain verifier. That made the resolver's response less useful for users diagnosing the incident.
Design explicit emergency paths for fail-closed security systems.DNSSEC should fail closed when validation breaks, but operators still need a controlled way to handle known, public, upstream signing failures. Negative Trust Anchors exist for this reason. The emergency path should be built, documented, logged, and easy to remove when the upstream zone is healthy again.
02
Treat parent-zone operations as high-blast-radius changes.A key rollover for a top-level domain is not a local maintenance task. If it produces invalid signatures, the failure propagates to every validating resolver and every child domain. Changes at the top of a hierarchy need rollout checks that reflect the number of systems beneath them.
03
Use stale data deliberately when freshness is less valuable than availability.Serve stale did not solve the .de DNSSEC failure, but it reduced the immediate impact by keeping known-good cached answers available during upstream failure. For read-heavy infrastructure, expired but previously valid data can be a useful safety valve when fresh reads fail.
04
Make diagnostic errors preserve the real failure cause.A DNSSEC validation failure and an unreachable authority point responders in different directions. If internal layers collapse specific errors into generic ones, users and operators lose time. Error propagation should keep the cause visible across subsystem boundaries.
05
Coordinate across organizational boundaries before users need the workaround.Cloudflare communicated its mitigation with other DNS operators through DNS-OARC. Incidents in decentralized infrastructure cross company boundaries immediately, so the response channel matters as much as the local fix. Operators need trusted places to compare signals, mitigations, and rollback conditions.