ICANN root zone KSK rollover countdown: October 11 may affect global resolution

ICANN root zone KSK rollover countdown: October 11 may affect global resolution

ICANN's official blog recently issued a reminder: ICANN and Verisign are preparing the second root zone Key Signing Key (KSK) rollover in history. For ordinary users, whether domain resolution works depends on this "master key of Internet trust"; for site owners, it can directly affect the reachability of websites and email.

What a KSK rollover is

The root zone KSK is the top-level cryptographic trust anchor in DNSSEC, used to verify the authenticity of domain resolution results and prevent users from being redirected to phishing or spoofed sites. The first rollover took place in October 2018; because of the pandemic and hardware security module (HSM) upgrades, this cycle was extended, and the new key, KSK-2024, was first published in the root zone on January 11, 2025.

Under the RFC 5011 automated trust update mechanism, resolvers must observe a new key for 30 days before trusting it automatically. Data shows the current adoption curve nearly mirrors the successful 2018 rollover, with more than 95% of reporting resolvers recognizing and adopting KSK-2024.

Comparing the two rollovers

A longer window isn't a bad thing — more buffer for operators means lower risk of missing the change. The trade-off is that the "preparation phase" easily gets buried under day-to-day work, and most incidents actually happen in the days right before the deadline.

The critical deadline: October 11, 2026

After October 11, 2026, the root zone will use only KSK-2024. This means: if your DNSSEC-validating resolver has not been configured with KSK-2024 by that date, you will experience total DNS resolution failures, cutting off Internet access for your users. ICANN stresses that system administrators must manually verify configurations rather than assume automatic updates worked.

The trust anchor files to check include:

• ISC BIND: bind.keys
• Unbound / PowerDNS Recursor: root.key
• Knot Resolver: root.keys

The new key's Key Tag is 38696. If it is missing from your files, confirm that automated trust updates are enabled and that your resolver has write permission to its storage directory.

What happens if you don't update

Picture an office network running its own resolver that never adopts KSK-2024 before October 11. Just after midnight, the resolver asks the root zone for DNSKEY records, finds the key mismatch, the validation chain breaks, and every domain it validates starts returning SERVFAIL. Users hit timeouts on every site; email clients keep reporting "can't connect to server". The nastiest part is how hard this is to diagnose: the network is up, the server is online, nothing resolves — and people usually blame the switch, the firewall, or the ISP before anyone thinks of the root zone key. That's why ICANN keeps pushing "verify manually": the automatic update exists, but the moment one older resolver falls behind due to disk permissions, clock skew, or a software bug, the outage happens without anyone noticing.

For ordinary users on public DNS (like 8.8.8.8 or 1.1.1.1) and for most hosted sites, there's nothing to do; the ones who need to act are operators running their own recursive resolvers and edge caching resolvers.

How to verify your resolution chain

If you run your own recursive resolver, two commands will tell you where you stand. First, check that Key Tag 38696 appears among the DNSKEY records currently published in the root zone:

dig +dnssec DNSKEY . @8.8.8.8 | grep 38696

Then run a full validation chain from the root to a domain with delv:

delv @127.0.0.1 example.com A +rtrace

A result of valid or fully validated means the chain is healthy; no valid RRSIG or indeterminate usually points to a wrong trust anchor — upgrade the resolver software first, then import the new anchor manually per the official guide. For sites already running DNSSEC, also confirm your own DNSKEY/DS records are still valid — many "sudden resolution failures" actually come from an expired signature on your own domain.

What site owners should do

For most sites hosted with professional providers (cloud hosts, CDNs, managed authoritative DNS), the provider usually handles trust anchor updates on the resolver side. But if you run your own DNS resolver, your own mail server, or caching resolvers at the network edge, mark October 11 as an operations milestone. Suggestions:

1. Add the KSK rollover date to your maintenance calendar and re-check resolver logs a week ahead;
2. Use delv or dig to verify that the DNSSEC validation chain is healthy (commands above);
3. Check that server clocks are NTP-synced — time skew breaks signature validation, and this class of problem is especially common around a rollover;
4. Run a read-only drill: back up the trust anchor files, confirm the auto-update switch and the storage directory permissions, then decide whether manual intervention is needed.

DNS is the foundation of website availability, and this rollover is a reminder that scheduled, deterministic maintenance beats emergency firefighting. For domain and DNS hardening, see domain and hosting security.

Reference: ICANN KSK rollover resources https://www.icann.org/resources/pages/ksk-rollover
Source: https://www.icann.org/en/blogs/details/preparing-for-the-root-zone-ksk-rollover-what-you-need-to-know-27-07-2026-en