DNS Root KSK Rollover October 11: Check Your Resolver Now or Face Outages This Week

The internet’s root signing key rotates tomorrow, October 11. For most developers, it’s a non-event — cloud resolvers like Cloudflare 1.1.1.1 and Google 8.8.8.8 handle this automatically. But if you self-manage a BIND, Unbound, Pi-hole, or any validating DNS resolver, spend two minutes today checking it. Miss it, and you won’t know anything is broken until DNS silently fails on your network sometime on October 12 or 13.

What’s Changing

DNSSEC secures DNS by signing responses with cryptographic keys. At the top of that chain is the Root Zone Key Signing Key (KSK) — the master key that validates everything below it. Since 2018, that key has been KSK-2017 (key tag 20326). On October 11, it retires.

Its replacement, KSK-2024 (key tag 38696), was published in the root zone on January 11, 2025 — nearly two years ago. ICANN gave the internet ample runway. Most resolvers learned the new key automatically through RFC 5011’s self-update mechanism. Some didn’t.

The 48-Hour Trap

Here’s why this is more dangerous than it looks: failures don’t happen on October 11. They happen on October 12 or 13.

The root DNSKEY record has a 48-hour TTL. A resolver that cached it just before the switch continues serving from cache. When that cache expires, it fetches a fresh copy signed only by KSK-2024. If your resolver doesn’t trust KSK-2024, it can’t validate the signature. The result is SERVFAIL — for every domain, not just DNSSEC-signed ones. Complete DNS failure.

You flip no switch on October 11. You wake up to an outage on October 12.

Who’s Actually at Risk

RFC 5011 automated updates work — but only if a few conditions hold: the resolver ran continuously during early 2025, and it could write its updated trust anchor state to disk. That rules out a surprising number of setups:

• Docker containers running BIND or Unbound — containers that start fresh don’t persist RFC 5011 state between restarts
• VMs or golden images rebuilt from pre-2025 snapshots — they only know the keys baked in at build time
• Pi-hole + Unbound on recently reinstalled hardware — a fresh install resets the Unbound trust anchor to defaults
• pfSense and OPNsense firewalls with DNSSEC validation enabled — many ship a hardcoded trust anchor list
• Windows Server DNS with custom trust anchor configuration
• Any BIND/Unbound version too old to include KSK-2024 in its bundled root hints

If you’re running any of these, check now.

How to Check in 60 Seconds

Option A — Online sentinel test: Visit dnstest.dev/ksk-2024. It runs RFC 8509 sentinel queries against your browser’s resolver and tells you plainly whether it trusts KSK-2024.

Option B — Unbound (check trust anchor file):

grep 38696 /var/lib/unbound/root.key

If that returns nothing, your Unbound instance doesn’t have KSK-2024.

Option C — BIND 9 (check managed-keys status):

rndc managed-keys status

Look for keyid 38696 with a “trusted since” date. If it’s missing, you need to act.

How to Fix It

For Unbound — including Pi-hole setups — the unbound-anchor utility pulls the current root trust anchors directly from IANA:

sudo unbound-anchor -a /var/lib/unbound/root.key
sudo systemctl restart unbound
grep 38696 /var/lib/unbound/root.key

For BIND, update the managed-keys configuration with the KSK-2024 DNSKEY from ICANN’s root-anchors file at data.iana.org and reload named.

For containers and ephemeral environments, the fix is architectural: bake the current root.key into your image, or mount it from a persistent volume that stays updated. A one-time fix isn’t enough if your container resets state on every deploy.

Who Can Skip This

If your infrastructure uses Cloudflare 1.1.1.1, Google 8.8.8.8, or your ISP’s DNS resolvers, you’re fine. Those operators maintain their own trust anchors. Same goes for AWS Route 53 Resolver, Azure DNS, and similar managed services.

If you’re not running DNSSEC validation at all — which is the default in many basic setups — you’re also unaffected. The rollover only matters to resolvers that validate DNSSEC signatures.

The question is whether you know which category you’re in. Check the dnstest.dev link. It takes 15 seconds. The alternative is explaining to your team why DNS died on a Thursday morning.