On October 11, 2026 the DNS root zone will start being signed with a new key, KSK-2024, according to ICANN. It is only the second time this has happened. Most websites have nothing to do. Anyone who runs a server or a network with its own DNSSEC-validating resolver should check it before that date.
What we know
- What happens and when: on October 11, 2026 KSK-2024 becomes the active key used to sign the DNS root zone, according to ICANN's press release of August 11, 2026. It replaces KSK-2017, which has been signing since October 11, 2018, according to IANA.
- How to tell them apart: the new key has key tag 38696 and the old one 20326, according to IANA. The new key has been published in the root zone since January 11, 2025.
- What the key is: it is the starting point of DNSSEC, the signature system a DNS resolver uses to check that an answer is authentic. Every validating resolver stores it as a "trust anchor".
- Who has to act: organizations operating DNSSEC-validating recursive resolvers, DNS software vendors and operators with manually configured trust anchors, according to ICANN.
- ICANN's warning: its rollover page asks operators to verify that KSK-2024 is present in their configuration and adds: "Do not assume automatic trust-anchor updates succeeded."
- How many people could be affected: a very small percentage of Internet users, according to the guide ICANN published on July 27, 2026. The guide gives no figure.
- When it would show: not necessarily on the day. Resolvers cache the root's key set for up to 48 hours, so failures can start at any point in the 48 hours after the change, according to that guide.
- What comes next: the process continues into 2027, when ICANN plans to revoke KSK-2017, remove it from the root zone and delete its private key, according to Cloudflare's blog post of October 6, 2026.
What changes and what doesn't
What changes is the key that signs the root's list of keys. A validating resolver that does not trust KSK-2024 will stop validating: its users may be unable to reach websites under any top-level domain, even though those sites are working fine, according to Cloudflare.
Nothing changes on your domain. You do not need to touch your DNS records or your domain's own DNSSEC keys, if it has them: the key being replaced is the root's. According to Cloudflare, most website operators do not need to make any changes.
Users of a resolver that does not validate DNSSEC, or of one that already trusts the new key, will see no difference, according to the ICANN guide.
How to tell if it affects you
Most likely it doesn't. It is worth a look if you run a VPS or a dedicated server, or if you manage your office network.
- Find out who resolves names for you. On shared hosting, your provider does. On a Linux VPS, open the file "/etc/resolv.conf". If it points to an outside address, validation is that service's job. If it points to the machine itself (an address starting with 127), there is a local resolver: find out which one (Unbound, BIND, systemd-resolved) and whether it validates DNSSEC.
- Run Cloudflare's test. Open dnstest.dev/ksk-2024 from that network: it asks the resolver your browser uses whether it trusts the new key. Cloudflare notes that the browser's Secure DNS setting or a VPN changes which resolver is asked, and that an inconclusive result does not mean the key is missing.
- On a server, from the command line. Cloudflare suggests two queries: "dig root-key-sentinel-is-ta-38696.dnstest.dev. A" and "dig root-key-sentinel-not-ta-38696.dnstest.dev. A". Cloudflare runs them against its own 1.1.1.1; without naming a server, dig asks your machine's resolver. If the key is trusted, the first returns addresses and the second returns SERVFAIL. It only works if the resolver supports this test (RFC 8509).
- If the key is missing, ICANN says to confirm that automatic updates are enabled and to follow your resolver vendor's guidance. According to IANA, vendors often ship up-to-date trust anchors through their regular software updates.
- Ask your hosting company or your Internet provider: "Do your resolvers validate DNSSEC, and do they already trust KSK-2024, key tag 38696?"
- Keep an eye on October 11 to 13. If your server stops sending email, reaching the payment gateway or downloading updates on those days, or no website opens at the office, check the resolver first. That list is this article's, based on what the guide describes: pages that do not load, mail that does not arrive and automated systems that fail. As an emergency exit, the guide allows temporarily disabling DNSSEC validation; after that, install the key and turn validation back on.
If a visitor cannot reach your site on those days while everyone else can, the problem may be their resolver and not your server: according to the guide, two people can get different results at the same moment if they use different resolvers.
Related: Cloudflare Shipped 46 Launches: What Changes for Your Site
Sources
- ICANN, "Root Zone KSK Rollover", official page
- ICANN, "ICANN Publishes Guidance to Help Prepare for the October 2026 Root KSK Rollover", August 11, 2026
- ICANN, guide "What to Expect During the Root KSK Rollover", July 27, 2026 (PDF)
- IANA, "Trust Anchors and Rollovers"
- Cloudflare, "The keys to the Internet change on October 11. Are you ready?", October 6, 2026
Updates: this note will be extended with how the October 11 change went and whether ICANN reports failures.