Written on 7 October 2026, four days before the change described below.
On 11 October 2026 the DNS root starts signing with a new key. Cloudflare, which published a guide to the change on 6 October, put it this way: "On October 11, 2026, the DNS root is scheduled to change its key-signing key (KSK) for only the second time ever."
For most businesses this is a non-event. Cloudflare's guide says so directly: "Most website operators do not need to make any changes for this rollover." But for a small number of organisations it will look, from inside the office, exactly like the internet has stopped working — while every website they try to reach is perfectly fine. This article is about telling which group you are in, and checking it in two commands.
What actually changes
When your computer looks up a website, a DNS resolver finds the address. Some resolvers also validate the answer with DNSSEC — checking a chain of digital signatures to confirm the answer was not tampered with. That chain has to start somewhere, and it starts at the DNS root, with a root key the resolver already trusts. That starting key is called a trust anchor.
IANA, which operates the root key, publishes the schedule. The new key, KSK-2024, carries key tag 38696. It replaces KSK-2017, key tag 20326. IANA's timeline:
- 11 January 2025 — "The successor key was introduced in the DNS root zone."
- 10 February 2025 — "The successor key should begin to be trusted by resolvers that follow the mechanisms described in RFC5011."
- 11 October 2026 — "The successor key is scheduled to sign the zone; the current key will not sign the zone. Validating resolvers must have updated trust anchors to continue validating the root zone."
The consequence, in Cloudflare's words: "If a resolver does not trust the replacement key, its users may be unable to reach websites under any top-level domain." Note the condition. Nothing happens to a resolver that already trusts KSK-2024, and nothing happens to one that does not validate DNSSEC at all.
Who actually has to do something
The people who must act are whoever runs a DNSSEC-validating resolver. In a business, that is usually one of:
- An on-premises DNS server — often the one that comes with Active Directory — if someone has switched on DNSSEC validation.
- A corporate recursive resolver your IT team runs, such as BIND or Unbound.
- A firewall or network appliance that resolves DNS for the office and validates it.
If your office simply points at your internet provider's DNS, or at a large public resolver, the change is the provider's to handle — though you can still check it, below.
The resolvers most likely to be caught out are the exceptions to the RFC 5011 timeline above. A resolver that followed RFC 5011 should have started trusting the new key on its own from 10 February 2025. The risk is concentrated in ones that did not: automatic trust-anchor updates turned off, a trust anchor that was set by hand and never changed, or a server that learned the new key automatically and then lost that state — rebuilt, re-imaged or restored from an older backup.
How to check, in two commands
The test uses a standard called RFC 8509, the root key trust anchor sentinel. You ask your resolver for two specially named addresses. One asks whether the resolver trusts key 38696; the other asks whether it does not. A resolver that supports the sentinel deliberately fails one of them, and which one it fails tells you the answer.
Run these from a machine on the network you want to test, using that network's normal DNS:
dig root-key-sentinel-is-ta-38696.dnstest.dev A
dig root-key-sentinel-not-ta-38696.dnstest.dev ALook at the status: line of each answer. To test a specific resolver, add it with @, for example dig @10.0.0.53 root-key-sentinel-is-ta-38696.dnstest.dev A.
is-ta-38696 | not-ta-38696 | What it means |
|---|---|---|
| NOERROR | SERVFAIL | Ready. The resolver validates and trusts KSK-2024. |
| SERVFAIL | NOERROR | Act now. The resolver validates but does not trust KSK-2024. |
| NOERROR | NOERROR | Inconclusive — not a pass. See below. |
That third row is the one people misread. Two clean answers look like success, but they mean the resolver did not take part in the test — it either does not validate DNSSEC or does not support the sentinel. Cloudflare is explicit: "If sentinel support cannot be established, the result is inconclusive; it does not mean the new key is missing." It does not mean the key is present, either.
We ran both commands on 7 October 2026. Against Cloudflare's resolver, 1.1.1.1, we got NOERROR then SERVFAIL — the "ready" pattern. Against Google Public DNS, 8.8.8.8, both names returned NOERROR — the inconclusive pattern, which by Cloudflare's own reading says nothing about whether the key is missing. The point is not either provider; it is that the most familiar resolvers do not all give you a clean yes or no, so read the table rather than the first green answer.
Two ways to fool yourself
Testing the wrong resolver. Cloudflare also offers a browser test at dnstest.dev/ksk-2024/, but notes that it "checks the resolver your browser uses, which may be affected by Secure DNS or a VPN." Many browsers now send DNS straight to a public resolver over an encrypted connection, bypassing the office DNS server completely. A browser can pass while the server every other device in the building relies on would fail. If the question is "is our office resolver ready", run dig from a machine that uses it.
Treating "inconclusive" as "fine". If you get two NOERROR answers from a resolver your own team runs, that is a reason to check its configuration, not to stop.
If your resolver does not trust the new key
Cloudflare's instruction is the right one: "If you run a DNSSEC-validating resolver, check that it trusts the new root key, KSK-2024, and follow your software vendor's instructions to update its trust anchors if the key is missing." The authoritative copy of both keys is IANA's own trust-anchor file at data.iana.org/root-anchors/root-anchors.xml — compare against that, not against a key pasted from a forum.
Cloudflare also says that if you use Cloudflare for your domain's DNS or rely on 1.1.1.1 and Gateway DNS, "you do not need to take any action — our systems already trust KSK-2024." That is Cloudflare's statement about Cloudflare's own services. It does not cover your office server, your firewall or any other provider.
What failure would look like
If a validating resolver misses the change, the symptom is not one broken website. Lookups through that resolver can start failing for everything, so staff report that "nothing loads" — email, the CRM, every site. The tell is that the same sites work from a phone on mobile data. If you see that pattern after 11 October 2026, check the resolver's trust anchors before anyone starts debugging the websites.
Not sure which resolver you run?
That is the most common answer, and a perfectly reasonable one — DNS is usually set up once and never looked at again. If you would like a second pair of eyes, get in touch and we will find out which resolver your network actually uses, whether it validates DNSSEC, and how it answers the test above.
Sources
- IANA, DNSSEC trust anchors and rollover timeline — iana.org/dnssec/files, and the trust-anchor file data.iana.org/root-anchors/root-anchors.xml (read 7 October 2026)
- Cloudflare, "root KSK-2024 rollover" — blog.cloudflare.com/root-ksk-2024-rollover/, published 6 October 2026 (read 7 October 2026)
- RFC 8509, A Root Key Trust Anchor Sentinel for DNSSEC