DNS root key rollover risks resolver failures on October 11

The DNS root zone’s trust anchor will change on October 11, 2026, when KSK-2024 becomes the sole signing key. Resolvers that have not adopted the new key will fail to validate any DNSSEC-signed domain, effectively cutting off internet access for users behind them. While most modern resolver software includes KSK-2024 by default, frozen appliances, outdated VM images, and manually configured instances remain vulnerable. The failure mode is absolute: no domain will resolve, including the host’s own control panels and mail servers, until the resolver is updated or validation is disabled as a temporary workaround.

What changes on October 11

The root zone’s DNSKEY record set will carry signatures only from KSK-2024 (key tag 38696) after the change. KSK-2017 (tag 20326) will remain in the zone until January 2027 but will no longer sign the root’s DNSKEY set. Resolvers that rely solely on KSK-2017 will return SERVFAIL for every signed domain, including the root itself, rendering all name resolution impossible. The root’s DNSKEY set has a 48-hour TTL, so failures will surface gradually as cached copies expire, with most issues appearing between October 11 and 13.

ICANN and Verisign report that over 95% of resolvers signaling their trust anchors under RFC 8145 already trust KSK-2024. However, resolvers that do not signal—such as older builds or manually configured instances—are not included in this measurement. The 2018 rollover saw minimal disruption, but the remaining 5% could still represent thousands of resolvers, particularly in enterprise or embedded environments where updates are infrequent.

How to check for readiness

Operators can verify their resolvers’ readiness using RFC 8509 sentinel queries. A resolver that trusts KSK-2024 will successfully resolve root-key-sentinel-is-ta-38696.dnstest.dev and return SERVFAIL for root-key-sentinel-not-ta-38696.dnstest.dev. Cloudflare provides a browser-based test at dnstest.dev/ksk-2024, which runs these queries alongside control tests for correctly and incorrectly signed domains.

For Unbound, the trust anchor is managed by unbound-anchor, which requires write permissions on the root.key file. BIND users can check trusted keys with rndc managed-keys status or rndc secroots. PowerDNS Recursor ships with the root key built-in and does not support RFC 5011, so updates require a software upgrade. Dnsmasq and other static resolvers must have their trust anchors manually updated.

Impact on hosting providers

Hosting providers face two distinct risks. The first is their own resolvers—particularly those running on mail servers, appliances, or VM templates that may not have been updated since 2024. The second is customer support: users behind stale resolvers will report sites as unreachable, even though the issue lies with their resolver, not the host’s infrastructure. Failures will not be immediate; cached records will continue to resolve until their TTLs expire, so support teams should expect calls through October 13.

A quick cross-check against a public resolver like 1.1.1.1 or 8.8.8.8 can confirm whether the issue is local. For customers, the immediate workaround is to disable DNSSEC validation or switch to a public resolver. For hosts running their own resolvers, the fix is either a manual trust anchor update or a software upgrade, as automatic adoption via RFC 5011 will no longer be possible after October 11.