On May 5, 2026, at 19:30 UTC, DENIC pushed a ZSK rollover for the .de zone. A bug in HSM coordination generated three signing keys instead of one, and roughly two-thirds of the RRSIGs that went out were unsigned by any key the published DNSKEY set could validate. Every validating resolver - Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 - returned SERVFAIL for millions of .de domains for about three hours, until Cloudflare deployed a Negative Trust Anchor at 22:17 UTC to bypass the broken chain. DENIC's post-mortem was published three days later.
This was not a German outage. It was a global outage of every .de name, because the validating resolvers that hundreds of millions of users depend on now reject answers when the cryptographic chain breaks. The .de outage is the first public proof that resolver enforcement is real at scale.
DNSSEC has been quiet for thirty years. The protocol just got loud, because four things are now true at once: validation is widespread by default, the attack surface DNSSEC covers is under active attack, the privacy layer needs the integrity layer, and the root trust anchor is about to roll.
The "nobody validates" critique is now historically false. The default resolvers for hundreds of millions of users validate by default. The protocol has teeth.
The attack surface DNSSEC actually covers is under active attack. On June 20, 2025, AS35168 (TNS-Plus, Kazakhstan) hijacked eight DNS root prefixes for 90 minutes, with the routes propagated upstream through Uzbektelekom. The root operators' joint statement called out DNSSEC by name as the integrity defense. This is the same shape as the KLAYswap BGP-to-cert attack ($2M stolen) and the 2018 MyEtherWallet hijack via Route 53 (~$152K stolen, ~215 ETH). No other protocol-level control fills this gap.
The privacy layer needs the integrity layer. RFC 9849 finalized Encrypted Client Hello in March 2026. ECH encrypts the TLS ClientHello so a network observer cannot see which HTTPS host a client is connecting to, but it has to bootstrap the encryption key from somewhere, and that somewhere is a DNS HTTPS or SVCB record. DNSSEC was originally designed to authenticate DNS data: to give a resolver a cryptographic guarantee that the answer it got is the one the zone operator published. ECH inherits that guarantee or it has none. The RFC's Security Considerations section names DNSSEC as the defense against ECH key substitution. Cloudflare is already deploying ECH at scale. If you ship encrypted TLS without DNSSEC underneath, the encryption is no stronger than the DNS answer that delivered the key.
And there is a hard deadline, but it is not the one most operators think it is. On October 11, 2026, KSK-2024 begins signing the root zone. If you run an authoritative zone, you do not need to do anything for this rollover - the root operators handle their own key. The action item is on the resolver side. As of March 2025, 91.3% of resolvers had accepted the new trust anchor. The 8.7% that have not will start returning SERVFAIL for every DNSSEC-signed zone the moment KSK-2017 is revoked in January 2027. If you run a recursive resolver - in a corporate network, in a home lab, embedded in a CPE - you need a build with the KSK-2024 trust anchor before October.
The argument I cannot make is that cyber insurance now requires DNSSEC, or that NIS2 explicitly mandates zone signing. Neither is true. The argument I can make is that the cost of not having it on is no longer hypothetical. Resolver enforcement is real, the BGP-to-cert attack is documented, the privacy layer needs the integrity layer, and there is a hard date.
For my own infrastructure, the work was a short checklist:
- Verify every authoritative zone I run is signed (and that the signatures are current, not expired).
- Verify the DS record at the parent zone matches the active KSK and the chain validates end-to-end (dnsviz.net is the fastest way).
- Verify the recursive resolver in my home stack has the KSK-2024 trust anchor loaded.
Most of this matters more for the public-facing zones than for the internal split-horizon ones, and it took less than an afternoon. The cost of doing this last fall would have been the same as the cost of doing it now. The cost of doing it after October 11 will not be.
The quiet infrastructure just got loud.
See also
- Putting Cloud Run Behind Cloudflare Pro: The Non-Obvious Parts - the edge layer
- Cloudflare and honeypots - in the queue, undated
- Using IAP on Cloud Run for Single-User Apps - the quiet infrastructure DNSSEC sits underneath