The Internet's Root Key Changes Today: What the KSK-2024 Rollover Means for Your DNS
On October 11, 2026 the DNS root zone switches the key that signs it: KSK-2024 comes in and KSK-2017 steps back. Most people will notice nothing; a resolver missing the new key stops resolving everything. This is the KSK-2024 rollover and the five-minute test.
The KSK-2024 Rollover: What Changes in the DNS Root Today
The root zone is the top of the DNS list: the one that says where the servers for each top-level domain live. From today, the key set for that zone is signed by KSK-2024 (key tag 38696) instead of KSK-2017 (key tag 20326), which held that role for eight years. Both are RSA/SHA-256 keys, so the algorithm does not change: the key material does.
This is only the second root rollover in the history of the internet. The first was in October 2018, when KSK-2010 handed over to KSK-2017, and it was postponed by a year because too many resolvers were not ready.
From KSK-2017 to KSK-2024: What a Key-Signing Key Actually Is
To check that a DNS answer really comes from who it claims to, DNSSEC exists. Inside DNSSEC there are two kinds of keys: the ZSK signs the day-to-day records of a zone and the KSK signs the zone's key set. That KSK is the trust anchor of the whole system: the validation chain starts there and nothing sits above it to vouch for it. That is why replacing it is delicate, and why operators are warned months in advance.
Read also
Two Dates: October 11, 2026 and January 2027
These are two separate moments, not one. Today the new key starts signing and the old one stops signing. KSK-2017 stays present in the root key set, but no longer signs, until it is formally retired in January 2027. After that second date, a resolver that only trusts the old key is left without validation.
Why the New Key Has Been Published for Months
KSK-2024 has been published in the root zone since February 2025, about twenty months before the switch. That margin is deliberate: it exists so resolvers can learn the key without rushing. Whoever used that time has nothing to do today; whoever did not, finds out today.
Why Most People Will Notice Nothing
Two Ways to Get the Key: RFC 5011 or Your Vendor's Package
A validating resolver can learn the new key in two ways. The first is automatic and it is called RFC 5011: the resolver itself sees the new key in the root and, after a waiting period designed to prevent trickery, starts trusting it with nobody touching anything. The second is more mundane: the update to your distro package, your container image or your router firmware already carries the new trust anchor.
If your resolver used either path, you notice nothing today. That is the case for most connections in the world, which also do not run their own resolver: they use their ISP's or a public one.
The Tricky Cases: Container Images and Enterprise Routers
Trouble shows up where software sits still. A container image pinned by tag instead of updated regularly, a server nobody has touched in years, an office managed router or a home-made resolver can hold a trust anchor that was never refreshed. That is not an exotic profile: it is the profile of a lot of software that works fine and therefore nobody looks at.
What Breaks When Your Resolver Doesn't Trust KSK-2024
SERVFAIL Everywhere: Signed and Unsigned Domains Alike
The failure is not partial. A validating resolver without the new key cannot validate the root answer, and without that validation there is no possible chain of trust: it returns SERVFAIL for signed and unsigned domains alike. That is, one specific site does not fail: everything going through that resolver fails. That is the scenario operators want to avoid, and it is where the "mysterious outages" come from when someone discovers the problem through users instead of through configuration.
DNSSEC Doesn't Encrypt, It Authenticates
Worth saying out loud because the easy headline usually gets it wrong: DNSSEC does not encrypt traffic and does not protect the privacy of your queries. What it does is sign and verify answers, so nobody can forge the address behind a name. If nobody validates, the effect is not that your data is exposed: it is that forged answers stop being detected.
The Five-Minute Test with RFC 8509 Sentinels
The Two Queries and How to Read Each Result
There is a standard mechanism to ask a resolver whether it trusts a specific key: the RFC 8509 trust anchor sentinels. They are special names under dnstest.dev. Run the queries against the resolver your machines actually use, not against the laptop you are typing on.
dig @192.0.2.53 root-key-sentinel-is-ta-38696.dnstest.dev A
dig @192.0.2.53 root-key-sentinel-not-ta-38696.dnstest.dev AReading each answer is the part people get wrong:
- is-ta-38696 asks whether the resolver trusts the key with tag 38696. It should answer with an A record: if it does, the resolver is ready for the rollover.
- not-ta-38696 asks the opposite, whether it does not trust that key. It should return SERVFAIL, precisely because it does trust it. A normal answer here means the resolver is not validating at all.
The Trap: When "Everything Answers" Means No Validation at All
If both queries answer normally, you cannot conclude that your resolver is ready. It means one of two things: it does not validate DNSSEC, or it does not support the sentinel mechanism. Resolvers that do not validate do not break because of the rollover, but they also do not check that the answers they hand out are genuine. A useful control is to query a tag that does not exist: it should return SERVFAIL.
Query the Right Resolver: Your Laptop Doesn't Count
The test is only worth anything if you run it against the resolver serving your real clients or servers. Checking the one on the laptop in front of you is the fastest way to get an "all good" that says nothing about the system you actually care about.
How to Check Your Trust Anchor, Per Software
The cross-cutting rule is to look for key tag 38696 — or its DS digest — in the resolver's trust anchor. If it is not there, that is your problem.
BIND: bind.keys and rndc managed-keys status
In BIND the material starts in the bind.keys file and the mechanism's state is queried from the control console with rndc managed-keys status. There you can see whether the key is accepted or still pending.
Unbound: the root.key File and a Service Restart
In Unbound the key lives in the file pointed to by auto-trust-anchor-file, normally root.key. Back it up before touching it, then refresh the anchor from the official source and restart the service. Changing the file without restarting leaves the change on disk but not in memory.
Knot Resolver, PowerDNS Recursor and systemd-resolved
Knot Resolver keeps its anchor in root.keys and exposes a summary of its state through its control socket; if the file is writable, it updates itself. PowerDNS Recursor and the local resolvers bundled with operating systems have their own mechanisms, and the exact path and command depend on the version: confirm them in your implementation's documentation before changing anything.
If Key Tag 38696 Is Missing, Here's What to Do
Update the Package or Refresh the Anchor from IANA
The first step is to update the resolver's package, image or firmware, which usually fixes it outright. If you cannot wait, the anchor is refreshed by hand with the material published by IANA, and then the service is restarted. That material always comes from the official source, never from a blog post or a key file copied from another installation.
The Temporary Fix: Point at a Public Resolver That's Already Ready
If you have users waiting and cannot update right away, the quick exit is to point temporarily at a large public resolver, which updated itself long ago, and go back to your own once you can fix it. It is a patch, not a solution, and it should be treated as one.
What Not to Do
Do not copy key files from a blog or a third-party guide, and do not restart everything on reflex: restarting a resolver without the new key just repeats the failure in a tidier order. The right order is to diagnose with the sentinels, update the anchor from the official source and then restart.
The Problem That Shows Up the Same Day: Expired Signatures
There is one detail that surfaces right now precisely because everyone is looking at their DNS: expired signatures. A poorly maintained zone can carry signature records that have already expired, and that breaks validation just like an outdated anchor, with nothing to do with the rollover. If your diagnosis does not add up, it is worth ruling this second problem out before going around in circles about the root key.
What's Still Pending Until January 2027
The calendar does not end today. The old key is retired in January 2027, and on that day the room for manoeuvre runs out: anyone still trusting only it will stop validating. The window between today and that date is exactly how much time you have to fix a system that is not ready yet.
Who has nothing to do: anyone using their ISP's DNS or a public resolver, and anyone relying on managed hosting that already updated. Who should look today: anyone running a server with BIND, Unbound or Knot, a container pinned to an image tag, an office router or a network's internal DNS. The maintenance nobody sees is what keeps the internet running, and this is one of those cases: if you run servers, the blog has a guide to deploying Laravel 13 on a VPS where this kind of infrastructure check fits just as well.
