On October 11, 2026 the DNS root starts signing with a new key-signing key, KSK-2024, for only the second time ever. Most sites need to do nothing. A server that validates DNSSEC through its own resolver must already trust the new key, and a one-minute check tells you.
What Changes on October 11
On October 11, 2026, the DNS root zone starts signing its list of keys with a new key-signing key, KSK-2024 (key tag 38696), in place of KSK-2017 (key tag 20326). It is only the second time the root KSK has changed. The first rollover was in 2018.
The root KSK is where DNSSEC validation begins. A validating resolver keeps the root key as its trust anchor and checks every other signature against it. A resolver that does not trust KSK-2024 when the switch happens can no longer validate the root, and lookups through it can fail for every domain, healthy ones included.
Who Has Nothing to Do
Most site owners. Nothing changes for your domain's own records or DNSSEC keys, because the rollover concerns resolvers, the software that looks names up. If your servers use a public resolver or your provider's resolver, it is that resolver's operator who has to be ready. Cloudflare says 1.1.1.1 and its Gateway DNS already trust KSK-2024.
Who Should Check
Anyone running their own validating resolver on a server, such as Unbound, BIND, Knot Resolver, PowerDNS Recursor, or systemd-resolved with DNSSEC validation switched on.
Resolvers that follow RFC 5011 update their trust anchor on their own, and KSK-2024 has been published in the root since January 11, 2025, so most will already trust it. ICANN still asks operators not to assume that the automatic update worked. During the 2018 rollover Cloudflare saw resolvers lose a key they had learned after software upgrades or moves to new machines.
The One-Minute Check
The quickest test asks the resolver itself, using the root key trust anchor sentinel from RFC 8509. Run these two queries on the server, so they go through the resolver it actually uses:
dig root-key-sentinel-is-ta-38696.dnstest.dev A
dig root-key-sentinel-not-ta-38696.dnstest.dev A
A validating resolver that trusts KSK-2024 answers the first query and returns SERVFAIL for the second. The reverse means the key is missing. If both queries answer normally, the resolver either does not validate DNSSEC or does not support the sentinel, and the test tells you nothing about the key. Cloudflare's readiness test runs the same check from your browser, against the resolver your computer uses.
If the key is missing, ICANN's advice is to confirm that automatic trust anchor updates are enabled and to follow your resolver vendor's instructions for updating the trust anchor. Then run the check again before October 11.
Where It Fits
Checking the resolver on every server you run takes a few minutes per machine, and it belongs with the other routine checks in our server management work. If you are setting up a new server, our guide to hardening a fresh Ubuntu 24.04 VPS covers the first steps.
Sources
Or read how we handle it in Servers Management.
Related News
Your CI History Now Expires With Your Build Artifacts
From October 1, GitHub applies your Actions retention setting to checks, workflow runs and statuses, which used to survive 400 days regardless. Anyone who lowered that number to save on artifact storage just signed up to lose their build history at the same interval.
Server & DevOpsGitHub Now Migrates GitLab Repositories in One Command
GitHub Enterprise Importer now handles GitLab migrations self-service, no consulting engagement needed. Repositories, issues, merge requests and releases move with one CLI extension. Here is what comes across, what you rebuild, and how to size the work.
Server & DevOpsKubernetes 1.35.2 Becomes the Latest Supported Patch
Kubernetes 1.35 remained in active support as 1.35.2 shipped in late February 2026, giving platform teams a clearer current upgrade target.