Root DNS key rollover, 11 October 2026: who should check

The cryptographic key at the top of the internet’s address system is scheduled to change on Sunday 11 October 2026. ICANN, the body that coordinates the domain name system (DNS), says the DNS root zone will begin using a new key signing key, called KSK-2024, in place of the one that has done the job since October 2018. It is only the second time the key has been replaced.

For almost everyone in Australia, nothing will happen. ICANN’s guide to the changeover says “the vast majority of users are expected to be unaffected”. The exception is a network whose DNS resolver checks security signatures but has never picked up the new key. Its users would be likely to lose access to websites and email in the days after the switch.

What is changing

DNS turns a name such as a website address into the numeric address computers use. It is the same system that holds the SPF, DKIM and DMARC records that help your email reach the inbox. An add-on called DNSSEC lets DNS answers be signed, so the software looking them up, known as a resolver, can check they haven’t been altered.

That checking relies on a chain of signatures, and the chain starts with one key: the root zone key signing key. Resolvers that validate DNSSEC keep a copy of it, called a trust anchor.

ICANN says the root zone was first signed in 2010, and the key was changed for the first time in October 2018. The key being retired, KSK-2017, has signed the root’s key set since then. Its replacement, KSK-2024, was generated in April 2024 and has been published in the root zone since January 2025, which ICANN says gave resolvers about 21 months to pick it up automatically. Both keys use the same algorithm and key size, so only the key itself changes.

Roy Arends, a distinguished technologist at ICANN, wrote in July that more than 95 per cent of reporting resolvers had already recognised and adopted the new key.

Who is affected

ICANN’s guide sorts users into three groups:

Your DNS provider doesn’t validate DNSSEC. You will see no effect.
Your DNS provider validates and already trusts KSK-2024. You will see no effect.
Your DNS provider validates but only trusts the old key. Lookups are likely to start failing.

On our reading, if your home or office uses the DNS service supplied by your internet provider, or a public one, it is the operator of that service that has to hold the new key, not you. Cloudflare says users of its 1.1.1.1 resolver need to do nothing, because its systems already trust the new key.

The group that should check is anyone who runs their own validating resolver. ICANN names internet service providers, enterprise network operators and others who operate DNSSEC validation. On our reading, that includes any office whose IT provider has set up a resolver of its own. ICANN’s guide also warns that some applications, including containerised services and software using DNS over HTTPS, use a resolver chosen when they were built or deployed and not the one set on the computer, so a failure may come from a resolver nobody remembers choosing.

What a failure looks like

ICANN says an unprepared resolver won’t necessarily fail at the moment of the switch. Resolvers hold a saved copy of the root’s keys for up to 48 hours, so ICANN says affected users will likely start seeing problems at some point in that window. It adds that a resolver with a single user might not make the query that reveals the problem for hours, or even days, after that. ICANN’s published material gives the date but not a time of day. On our reading, that means Australian networks should watch at least through to Wednesday 14 October, and a quiet office resolver for longer.

When it happens, ICANN says web pages are likely to become unavailable or load only partly, and email programs may stop receiving new mail, until “no program is able to show new information from the Internet”. Automated systems that rely on the same resolver fail too. Because different people use different resolvers, one person may reach a site while a colleague on another network can’t, which ICANN says can make the cause harder to identify. A device with a second, working resolver configured should keep going, possibly more slowly.

How to check and how to recover

ICANN’s advice to operators is to look, not assume: “Do not assume automatic trust-anchor updates succeeded.” The new key has the key tag 38696. ICANN says to look for it in the resolver’s trust anchor file, which is bind.keys in ISC BIND, root.key in Unbound and PowerDNS Recursor, and root.keys in Knot Resolver. If it is missing, check that automatic trust anchor updates are switched on and that the resolver can write to its storage directory, then follow the software vendor’s instructions.

Cloudflare has published a browser test that checks whether the resolver your browser is using trusts KSK-2024. Cloudflare notes that an inconclusive result doesn’t mean the key is missing, and that a VPN or a browser’s secure DNS setting changes which resolver is being tested.

If a resolver does fail, ICANN says the operator may consider temporarily turning off DNSSEC validation, or setting a negative trust anchor for the root zone, which should stop the problems immediately. The operator should then install KSK-2024 as a trust anchor as soon as possible and turn validation back on. ICANN says service should return to normal almost immediately once the resolver is fixed.

What happens next

ICANN’s timeline has the old key, KSK-2017, removed from the root zone in the first quarter of 2027 and deleted from its two key management facilities in the second and third quarters. ICANN’s FAQ says the organisations that manage the root zone could reverse the change if problems turn out to be widespread, and that the timeline may be adjusted.

The next rollover is expected sooner than this one was. ICANN says it has set a three-year cycle, and that the next change, estimated to conclude in 2029, is expected to move to a different algorithm, ECDSA.

Checklist

Find out who runs your DNS. If it is your internet provider or a public DNS service, the operator is the one that has to hold the new key, and there is nothing to change on your own equipment.
Ask your IT provider whether your office runs its own validating resolver. ICANN warns that some applications also use a resolver set when they were built or deployed.
Confirm the resolver trusts key tag 38696. ICANN says to look in bind.keys for ISC BIND, root.key for Unbound and PowerDNS Recursor, and root.keys for Knot Resolver.
Turn on automatic trust anchor updates if the key is missing. Check the resolver can write to its storage directory, then follow the software vendor’s instructions.
Run Cloudflare’s KSK-2024 readiness test at dnstest.dev/ksk-2024. Cloudflare notes that a VPN or the browser’s secure DNS setting changes which resolver is tested, and that an inconclusive result doesn’t mean the key is missing.
Know the quick fix before you need it. If lookups fail in the days after the switch, ICANN says the operator can temporarily turn off DNSSEC validation, install KSK-2024, then turn validation back on.