Cloudflare Blog: .de TLD DNSSEC Outage on May 5, 2026
On May 5, 2026, DENIC published incorrect DNSSEC signatures for the .de TLD, causing validating resolvers like Cloudflare's 1.1.1.1 to return SERVFAIL for millions of domains over three hours.
On May 5, 2026, at roughly 19:30 UTC, DENIC, the registry operator for the .de country-code top-level domain (TLD), began publishing incorrect DNSSEC signatures for the .de zone. Any validating DNS resolver receiving these signatures was required by the DNSSEC specification to reject them and return SERVFAIL to clients, including 1.1.1.1, the public DNS resolver operated by Cloudflare. The .de TLD is one of the largest on the Internet, consistently ranking among the most broadly queried TLDs globally, so an outage at this level had the potential to make millions of domains unreachable.
DNSSEC (Domain Name System Security Extensions) adds cryptographic authentication to DNS. When a zone is signed with DNSSEC, each set of records is accompanied by a digital signature (RRSIG record) that lets a resolver verify the records haven't been tampered with. DNSSEC is built on a chain of trust starting at the root zone, whose trust anchor is hard-coded into resolvers. A break anywhere in that chain causes validation to fail for everything below it, which is why a misconfiguration at a TLD like .de affects every domain under it.
During the incident, freshly requested .de records ended up resolving to SERVFAIL because the DNSSEC signatures were broken and the resolver correctly rejected them. However, many .de records were still sitting in cache from before the incident began. Cloudflare's 1.1.1.1.1 implements RFC 8767, which formalizes serving stale: when upstream resolution fails, a resolver may continue serving expired cached records rather than returning an error. This significantly cushioned the impact of the outage, buying time for operators to respond.
The graph of response codes showed a steady climb in SERVFAILs over the following three hours as cached records slowly started expiring. As each domain's cached records expired and resolvers went back to DENIC for fresh copies, they got back broken signatures and started failing. There was also a large increase in query volume, typical during DNS incidents as clients retry failed queries, often three or more times, inflating the raw numbers.
Cloudflare applied temporary mitigations while DENIC resolved the issue. One key mitigation was the use of Negative Trust Anchors (NTAs), as defined in RFC 7646. In normal DNSSEC operation, a validating resolver maintains a set of trust anchors. By configuring an NTA for the .de zone, Cloudflare could temporarily disable DNSSEC validation for that zone, allowing queries to resolve normally despite the broken signatures. This was a deliberate trade-off: accepting the risk of a forged response in exchange for restoring availability.
The incident highlights the fragility of the DNSSEC chain-of-trust model. A single misconfiguration at the TLD level can cascade into widespread outages, affecting millions of domains and users. While DNSSEC provides important integrity guarantees, the operational complexity of key management and the lack of graceful degradation mechanisms remain significant challenges. The incident also highlighted the value of serving stale and NTA mitigations as practical tools for maintaining availability during upstream failures.
DENIC eventually resolved the misconfiguration, and normal DNSSEC validation resumed. The full post-mortem from Cloudflare provides detailed technical analysis and lessons learned for operators of large-scale DNS infrastructure. The incident serves as a reminder that even well-established security protocols require careful operational oversight and robust fallback mechanisms to prevent cascading failures.