A practical guide to the October DNSSEC rollover

On October 11, the DNS root will switch to a new cryptographic key. It sounds like the kind of event that should come with a countdown clock: years of planning, a globally coordinated key ceremony, and, if everything goes well, a reward of absolutely nothing happening. No banner, no outage, and no one noticing. That means the system is working as designed.

For most people with domains, you shouldn’t expect anything to change. Domains will continue to work normally, websites will stay online, and you won’t need to change anything in your Namecheap account.

However, one group does need to act: anyone responsible for a recursive DNS resolver that validates DNSSEC.

In simpler terms, that means a DNS server that looks up domain names and checks that the answers are authentic. For these administrators, October 11 is a real deadline with a specific check attached. If they overlook it, websites and other online services could appear unreachable.

This guide explains whether the change affects you, what is changing, and what you need to verify before October 11.

What is actually changing at the root

Every DNSSEC answer your resolver accepts traces back to one starting point. Signed zones form a chain: com vouches for example.com, the root vouches for com, and nothing vouches for the root. That’s why a validating resolver keeps its own local copy of the root’s public key, called a trust anchor. It’s the one fact the resolver takes on faith rather than verifies.

October 11 changes that fact. The root has been signed since 2017 by a key with tag 20326, which nearly every trust anchor in the world currently holds. Its successor, KSK-2024, carries tag 38696 and has been waiting in the wings for a while now. It entered the root zone back on January 11, 2025. Automatically updating resolvers were cleared to trust it from February 10, 2025. IANA’s schedule saves the real deadline for last: October 11, 2026, when 38696 begins signing alone.

A resolver that never picked up the new key hits a wall that day. Signatures made with KSK-2024 mean nothing to an anchor that only knows 20326, so validation fails. The resolver isn’t broken. The domains aren’t down. The stored trust connecting them is simply out of date.

First question: do you run a validating resolver?

Here is the question that decides whether the rest of this article is work or trivia: do you or your provider operate the recursive resolver that validates DNSSEC for your network?

Owning domains doesn’t put you on the hook. Neither does enabling DNSSEC for those domains at your registrar. That’s the authoritative side of the system, the part that publishes signed records. Validation happens at the other end, inside the recursive resolver that looks up names on behalf of your users. Namecheap has covered authoritative and recursive DNS servers before. The rollover checklist belongs entirely to the recursive side.

If your business points at your ISP’s resolvers, a public resolver service, or a managed DNS provider, the trust anchor is their job. A short message asking whether they’re ready for the October KSK rollover is a reasonable thing to send, and the answer should be a quick yes. That’s the whole task. If you run your own resolution, a campus resolver, an office appliance, Unbound on a VPS, BIND in a data center, the checklist below is yours.

Check for key tag 38696 now

ICANN’s operator reminder is blunt: verify that KSK-2024, key tag 38696, is present in your trust anchor configuration, and do not assume automatic updates succeeded. Turned into a working sequence:

1. Identify the resolver software and version on every box that validates. Forgotten appliances count.
2. Locate the active trust-anchor configuration. ICANN’s writeup names a few common homes for it: BIND keeps `bind.keys`, Unbound and PowerDNS Recursor use `root.key`, and Knot Resolver has `root.keys`. Your build may differ, which is why step one came first.
3. Look for tag 38696. If both 20326 and 38696 are present, that’s expected during the transition.
4. Confirm automatic trust-anchor updates are enabled in the configuration, not just assumed.
5. Check that the resolver can write to its trust-anchor file and the directory holding it.
6. If 38696 is missing, update the software or package first, then follow your vendor’s documented procedure for refreshing the trust anchor.

Ten minutes per resolver, most of it reading. The point of doing it now is that every fix on that list is calm before October 11 and urgent after it.

Why automatic updates can still leave a stale anchor

Nearly all modern resolvers track root-key changes automatically using the mechanism from RFC 5011, and ICANN reports that more than 95 percent of reporting resolvers already trust the new key. Note the denominator: resolvers that report. The ones nobody hears from are exactly the ones this section is about.

Automatic tracking only works when the resolver was running, connected, and able to record what it saw. A machine that sat offline through the observation window never watched the new key arrive. A resolver restored from an old snapshot or built from a stale image carries whatever anchor the image had. A trust anchor that someone pasted in by hand years ago sits outside the update mechanism entirely, and a config flag that disables tracking does the same job more honestly. Old packages miss the logic; hardened deployments sometimes leave the anchor file read-only, which preserves it perfectly and fatally. Unbound’s own unbound-anchor documentation is explicit that the daemon needs write access to both the anchor file and its directory, though the equivalent requirement looks different in other software.

Every one of those causes leaves the same quiet state behind: a configuration that looks fine and a key that isn’t there.

Rehearse the failure before the deadline

The failure, if it comes, will not look like one broken website. A resolver missing KSK-2024 starts failing validation for signed domains across the board, so from the helpdesk’s point of view, half the Internet goes down at once while every status page stays green. That pattern is the tell. The domains are healthy; the resolver’s trust is stale.

Rehearse against it now. Record the current key state so you know what you started from. Resolve a few signed domains through your own resolver and confirm they validate today. Work out what your monitoring would actually show if validation failed broadly, because “DNS is up” checks that bypass validation can stay green through the whole event. Keep two things reachable without working DNS: your vendor’s recovery instructions and IANA’s trust-anchor page. A known-good public resolver is useful as a diagnostic contrast. If names fail through your resolver and resolve through it, you’re looking at a validation problem on your side. Then fix the anchor. Switching validation off stops the bleeding and gives up the protection, so treat it as a tourniquet, not a repair.

Make October 11 a normal change window

Rollover readiness is an ownership question before it’s a technical one. Somebody on the team owns the resolvers; that person owns this date.

The plan fits on a sticky note. Verify tag 38696 on every validating resolver before October 11. Write down where each one keeps its anchor and which vendor doc covers recovery. Monitor on the day of the switch. Get on ICANN’s announcement list, so the next root-zone change arrives as an email you’re expecting. Between now and October, recheck any resolver that comes back from storage, a snapshot, or a long shutdown; restored machines are how stale anchors sneak back in.

The success condition is boring on purpose: October 12 feels like October 10, your users resolve names as if nothing happened, and the only evidence anything occurred is a checkbox in a change log dated well before the deadline.