The DNS root zone switches to a new key-signing key on October 11, 2026. The current key, KSK-2017, is replaced by KSK-2024 as the key that signs the root zone. Most websites will never notice the change. Validating DNS resolvers that have not learned the new key, however, will start failing DNSSEC checks, and the domains behind them will look offline. If you run a DNS resolver on your own servers, this is a deadline to check now.
What changes on October 11
DNSSEC lets a resolver confirm that an answer really came from the zone owner. The chain of trust starts at the root, where a key-signing key (KSK) signs the root DNSKEY set. Resolvers store that key as a trust anchor. The root is changing this key for only the second time. KSK-2024 (key tag 38696) replaces KSK-2017 (key tag 20326), and both use RSA/SHA-256, so only the key material changes.
The IANA trust anchors page lists the milestones. KSK-2024 was published in the root zone on 11 January 2025. Resolvers that follow RFC 5011 automatic updates should start trusting it from 10 February 2025. The switch to KSK-2024 as the signing key is set for 11 October 2026. KSK-2017 is scheduled for revocation on 11 January 2027 and removal from the root zone on 22 March 2027.
Who needs to act
If you only host a website or a domain, you normally need to do nothing. Your zone’s DNSSEC records are not changing. The work falls on validating resolvers, meaning the DNS servers that answer lookups for your users or for your server’s own name resolution. That includes BIND, Unbound, Knot Resolver and resolver appliances. Cloudflare’s 1.1.1.1 and Gateway resolvers already trust KSK-2024.
A resolver that does not trust KSK-2024 after the switch will fail validation for every signed domain. Cloudflare points to earlier cases where failed DNSSEC checks made working sites unreachable, and the effect is not limited to one top-level domain.
Test your resolver with RFC 8509 sentinels
RFC 8509 defines trust anchor sentinels, which are special DNS names that ask a resolver whether it trusts a particular root key. The dnstest.dev site publishes sentinel names for KSK-2024. Run both queries against the resolver your clients or servers actually use. Replace 127.0.0.1 with its address if it runs on another host.
dig @127.0.0.1 root-key-sentinel-is-ta-38696.dnstest.dev A
dig @127.0.0.1 root-key-sentinel-not-ta-38696.dnstest.dev ARead the status line in each answer:
| Resolver state | is-ta query | not-ta query |
|---|---|---|
| Trusts KSK-2024 | NOERROR | SERVFAIL |
| Does not trust KSK-2024 | SERVFAIL | NOERROR |
If you get neither pattern, the resolver may not support sentinel queries. That result is inconclusive and does not prove the key is missing. Check the vendor documentation or test the resolver from a different path before you rely on it.
Fix a resolver that does not trust the new key
Back up any trust anchor file before you change it, so you can roll back quickly.
- BIND: If your configuration uses
dnssec-validation auto;, BIND maintains the root key itself through RFC 5011. Confirm the managed keys withrndc managed-keys status, then rerun the sentinel test. If the test still fails, check the BIND version and the logs for trust anchor errors. - Unbound: Unbound reads the root key from the file named by
auto-trust-anchor-file. Back up that file, refresh it, and restart the service:
sudo cp /var/lib/unbound/root.key /var/lib/unbound/root.key.bak-ksk-2024
sudo unbound-anchor -a /var/lib/unbound/root.key
sudo systemctl restart unboundUse the path from your own auto-trust-anchor-file setting if it differs from the example. Then rerun the sentinel test from the same host. A resolver that only passes after the restart should be logged and watched until the switch is complete.
How TechProvidence can help
Resolver and DNS changes are easy to overlook until they cause an outage. TechProvidence can audit your DNS resolvers, check trust anchor handling on BIND and Unbound, and schedule any updates with a rollback plan in place. We also handle the broader server work around this kind of change, including upgrades, migrations and managed server care. contact us if you want the resolvers on your servers checked before October 11.
Source: Cloudflare Blog
