On 5 May 2026, DENIC carried out a scheduled key rollover for the .de zone and published signatures that did not validate. Resolvers that perform DNSSEC validation rejected the zone, as the protocol requires. Over the following three hours, as cached records expired, a growing share of .de domains became unreachable for users behind those resolvers, including large retail, transport, banking, and government sites. Cloudflare eventually [disabled validation for .de](https://blog.cloudflare.com/de-tld-outage-dnssec/) on its public resolver to restore service, and DENIC distributed a corrected zone shortly after midnight local time. The registry later [attributed the fault to a code change](https://blog.denic.de/en/denic-reports-resolved-dnssec-disruption-affecting-de-domains/) that its test scenarios had not covered.

This was not an isolated case. On 30 January 2024, the .ru zone [was unavailable for several hours](https://pulse.internetsociety.org/en/news/2024/01/dnssec-failure-causes-massive-website-outages-on-russian-internet/) after a problem in the software used to generate its keys. In May 2023, [.nz had a validation failure lasting about thirteen hours](https://internetnz.nz/assets/Archives/External-report-on-nz-DNSSEC-chain-validation-incident-on-May-2023.pdf) when a key rollover ran on the old timing after the TTL on DS records had changed from one hour to one day. In 2021, [Slack’s third attempt to sign slack.com](https://slack.engineering/what-happened-during-slacks-dnssec-rollout/) caused a 24-hour outage for a portion of its users. In 2012, [NASA.gov became unreachable for Comcast customers](https://www.internetsociety.org/blog/2012/01/comcast-releases-detailed-analysis-of-nasa-gov-dnssec-validation-failure/) after a key rollover went wrong. A [list of DNSSEC outages](https://ianix.com/pub/dnssec-outages.html) maintained by volunteers goes back to 2009 and has several hundred entries.

In each of these cases, the problem was diagnosed after the fact, by the people affected, by examining the zone as it stood at the time. That is generally how DNSSEC problems are examined today. There are good tools for inspecting one domain at one moment. There is very little that records how the signed part of the namespace changes from week to week. That is likely part of the reason the same few failure types recur.

How DNSSEC Problems Are Diagnosed Today

A validating resolver that encounters a broken chain returns SERVFAIL. Extended DNS Errors ([RFC 8914](https://www.rfc-editor.org/rfc/rfc8914)) add a reason code to that response, which is useful, though a [study presented at IMC 2023](https://blog.apnic.net/2023/09/28/extended-dns-errors-unlocking-the-full-potential-of-dns-troubleshooting/) found that the major resolver implementations disagreed on which code to return in 94 percent of the test cases. Diagnostic tools such as [DNSViz](https://dnsviz.net/) and Zonemaster go much further. Given a domain, they walk the chain from the root down, show every key and signature, and identify the link that failed.

What these tools do not provide is a time dimension. A snapshot shows what is broken. It does not show when the breakage started, whether it has happened before, whether last month’s fix held, or whether the same failure affected many other zones at the same time. Those are the questions an operator, a registrar, or a registry needs answered, and a single snapshot cannot answer them.

The clearest example of what a longer record reveals is the [2017 USENIX Security paper by Chung and colleagues](https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-chung.pdf). Using 21 months of daily measurements from [OpenINTEL](https://www.openintel.nl/), the authors found that only about one percent of .com, .net, and .org domains were signed, and that 28 to 32 percent of the signed domains had no DS record in the parent zone, so they could not be validated. The missing DS records were concentrated at a small number of operators. One hosting provider was publishing DNSKEY records for more than 131,000 domains and had a DS record for one of them. That pattern is invisible when domains are checked individually. It appears only when the whole population is observed over a period of months.

What a Longitudinal Record Adds

Treated as a time series, DNSSEC data answers several questions that a snapshot cannot.

Distinguishing a transient failure from a persistent one. A [paper at IMC 2025](https://dl.acm.org/doi/10.1145/3730567.3764428) analyzed 1.1 million DNSViz snapshots of 319,000 domains collected between 2020 and 2024. NSEC3 misconfigurations, delegation failures, and missing or expired signatures accounted for more than 70 percent of bogus states, and 18 percent of the affected domains were never repaired. These categories usually have different owners. An expired signature typically means the signing process stopped. A DS record that matches no current key typically means the DNS operator rolled a key, or the domain moved to a new provider, and the registrar was not updated. The first is a monitoring problem inside one organization. The second is a coordination problem between two. A single scan reports both as bogus. The history shows which one applies.

Observing rollovers. The .nz incident was a timing problem rather than a cryptographic one. InternetNZ’s new registry system, in production since November 2022, could not set an explicit TTL on DS records, so they took the zone default of one day rather than the one hour the rollover procedure assumed. A daily record of the .nz DS records would have shown the TTL change about six months before the rollover. The same applies at the root. On [11 October 2026](https://www.icann.org/resources/press-material/release-2026-08-11-en), KSK-2024 will begin signing the root zone key set in place of KSK-2017. The root DNSKEY set has a 48-hour TTL, so resolvers that still trust only the old key will start failing at different times over the following two days. Continuous measurement during that window is the practical way to assess how the rollover went.

Attributing a failure to the right party. A signed delegation involves at least three organizations: the DNS operator that holds the keys, the registrar that submits the DS record, and the registry that publishes it. When many domains on the same nameservers go bogus in the same hour, the operator is the likely cause. When DS records disappear across domains that share a registrar, the registrar is. Failures at the TLD level, as with .de, .ru, and .nz, are noticed within minutes. The smaller patterns are usually not noticed at all, because each domain owner sees a single broken domain rather than a group of them.

Evaluating policy. The evidence on what drives DNSSEC adoption comes from longitudinal data. [SIDN reports](https://www.sidn.nl/en/news-and-blogs/dnssec-adoption-heavily-dependent-on-incentives-and-active-promotion) that .nl, .se, .cz, and .no each passed 50 percent signed after their registries offered registrars a discount for signed domains, and observes that adoption changes little where no such scheme exists. About [62 percent of .nl domains](https://www.sidn.nl/en/news-and-blogs/majority-of-dutch-domains-and-internet-users-have-dnssec-security) are signed today, with growth of one or two percentage points a year. Globally, [APNIC’s measurements](https://blog.apnic.net/2026/02/25/towards-an-industry-best-practice-for-dnssec-automation/) put validation at 36 percent of users and secure delegation at 7 percent of domains in 2025. The IETF has recently published [RFC 10026](https://www.rfc-editor.org/info/rfc10026/), a best-practice document for automating DS provisioning through CDS and CDNSKEY records, with the aim of removing the manual registrar step. Whether that changes adoption in the large gTLDs will only be known by tracking the signed share of each TLD over the years that follow.

Limitations

A historical record of DNSSEC state has limits that should be stated.

It is not real-time. A crawl that revisits the namespace daily or every two weeks will record that .de was broken on 5 May. It will not capture how resolver failures built up over three hours as caches expired. Resolver-side telemetry, such as the data Cloudflare published, is the only source for that, and the two views complement each other.

The measurement itself can fail. Authoritative servers time out, the crawler’s own network has problems, a resolver misbehaves. If those events are recorded as validation failures, the archive becomes misleading. A useful record has to keep the raw chain it observed and hold unreachable zones in a separate category from bogus ones.

Coverage depends on zone files. For gTLDs, ICANN’s Centralized Zone Data Service provides a daily list of every delegated name, which is the natural seed for a crawl. Country-code TLDs have no equivalent obligation, and most publish no zone data. That is a real gap, since the largest DNSSEC outages of the past three years were all in ccTLDs.

A broken chain in the record is also not proof of user impact. With validation at roughly a third of users, most visitors to a bogus domain in 2026 will not notice. That is a reason to repair such domains before validation grows further, not a reason to disregard them.

What a Continuous Record Requires

The components of a continuous DNSSEC record already exist in separate places. OpenINTEL has queried every name in the gTLD zone files daily since 2015, more than 216 million domains a day, but it records responses without validating them. DNSViz validates and keeps an archive going back to 2011, but only for the roughly 100,000 names that users have asked it to monitor. The ianix outage list is thorough and maintained by hand.

Combining these into something operators can use requires a few things: a seed list refreshed from zone files; an independent chain walk from the root trust anchor to each domain, using non-validating resolvers so the raw responses are retained; failure classification with standard codes rather than free text; per-crawl snapshots kept long enough to cover a year of rollovers; and a query interface for one domain’s timeline or one TLD’s trend that does not require downloading the whole archive. Registries are well placed to do this for their own zones. Academic groups have done it for limited periods. Our team is working on it through [AUDNSXplore](https://audnsxplore.com), an ICANN Grant Program project whose purpose is exactly this: a free, continuously updated archive of DNSSEC validation results across the gTLD namespace.

Wrapping Up

The root zone has been signed since 2010, and for most of that time each DNSSEC outage has been handled as a one-off event. The published record suggests otherwise. Expired signatures, mismatched DS records, and rollovers run on the wrong timing account for most of the failures documented since 2009, and they continue to recur because nothing is watching for them between incidents.

A single scan of a domain shows its state at one moment. What the ecosystem lacks is a continuous record of every signed delegation, kept long enough that a key rollover, a provider migration, or a registry software change can be seen in context. The data is available, the validation logic is well understood, and storage is inexpensive. The .de outage will not be the last of its kind. How quickly the next one is understood depends on whether anyone was keeping the record.