The root KSK rollover happened on schedule: at 14:00 UTC on October 11, 2026, a new key called KSK-2024 began signing the DNS root zone. It replaced KSK-2017, which had signed the root since October 2018. This is only the second time the root key has changed.
As of October 14, ICANN reports no widespread problems. Most organizations did nothing and noticed nothing. A small group did need to act: teams that run their own DNSSEC-validating resolvers. This post explains the key in plain words, who was exposed, what failure looks like, and how to confirm your servers trust the new key.
The short version: if your staff use public DNS like Cloudflare’s 1.1.1.1, or your ISP’s DNS, there is nothing for you to do. If you run your own validating resolver (BIND, Unbound, Windows Server DNS with DNSSEC validation, or a firewall or appliance that validates), check that it trusts key tag 38696. Run the check again whenever you restore an old server image or put a spare appliance into service.
What the root KSK rollover changed
DNS turns names like example.org into addresses. If DNS is new to you, our plain-language guide to DNS covers the basics.
DNSSEC adds signatures to DNS answers. A validating resolver checks those signatures before it hands an answer to a laptop or a server. The checks form a chain, and the chain ends at the root zone, the top of DNS.
The Key Signing Key (KSK) is the root’s master key. Every validating resolver keeps a copy of its public half, called a trust anchor. If the resolver’s trust anchor does not match the key that signs the root, the whole chain fails.
On October 11, the root stopped signing with KSK-2017 (key tag 20326) and started signing with KSK-2024 (key tag 38696). The IANA trust anchor page now lists KSK-2024 as "Active" and KSK-2017 as signing between 2018-10-11 and 2026-10-11. Both keys use the same algorithm, RSA/SHA-256, according to Cloudflare.
A long lead time, and what is still coming
The root KSK rollover was planned years ahead. According to an ICANN blog post by Roy Arends, KSK-2024 was first published in the root zone on January 11, 2025. That gave resolvers 21 months to learn the new key before it took over.
The old key is not gone yet. IANA says KSK-2017 "remains a valid trust anchor" for now. ICANN’s rollover FAQ lists the remaining steps:
| Phase | Timing | What happens |
|---|---|---|
| Publication | January 2025 | KSK-2024 added to the root zone next to KSK-2017 |
| Rollover | October 11, 2026 | Only KSK-2024 signs the root key set |
| Revocation | First quarter of 2027 | KSK-2017 revoked and removed from the root zone |
| Deletion | Second and third quarters of 2027 | KSK-2017 deleted from both key management facilities |
A resolver that already trusts KSK-2024 has nothing to do for the 2027 steps. They matter only to a resolver that still trusts KSK-2017 alone, and that resolver is already failing.
Who the root KSK rollover affects
The root KSK rollover only touches DNS servers that validate DNSSEC. Most people never run one. Their laptops and phones ask someone else’s resolver, and that operator handles the key.
Cloudflare says 1.1.1.1 has trusted KSK-2024 since July 2024. We did not find a statement from Google about Google Public DNS (8.8.8.8), and we found no reports of trouble there either.
| Your setup | Exposed? | What to do |
|---|---|---|
| Staff and servers use 1.1.1.1, 8.8.8.8 or ISP DNS | No | Nothing |
| Your own BIND, Unbound, Knot or PowerDNS resolver with validation on | Yes | Confirm key tag 38696 is trusted |
| Windows Server DNS with root trust anchors loaded | Yes | Check the root trust anchor list |
| Firewall, router or appliance that validates DNSSEC | Yes | Check firmware and vendor notes |
| Forwarding server that validates before forwarding | Yes | Check it like any other resolver |
That last row catches people out. An Akamai post from October 8 notes that a resolver that forwards to an upstream server is still affected if it does its own validation.
What failure looks like
A resolver that missed the root KSK rollover, and still lacks KSK-2024, cannot validate the root anymore. ICANN’s FAQ says such resolvers "will treat responses signed under the new key as having been tampered with and will discard those responses." The resolver returns SERVFAIL, and the user sees a site that will not load.
It is not limited to signed domains. Cloudflare’s October 6 post says users behind such a resolver "may be unable to reach websites under any top-level domain." The websites themselves are fine. Only the lookup fails.
Timing makes it confusing. ICANN’s guide says the root’s key records have a 48-hour TTL, so failures start "sometime in the 48 hours after the rollover." It also says failures may be intermittent and may not hit every user or name the same way. Web pages may not load or may load in part. Email may stop arriving.
By the time this post runs, the 48-hour window after the root KSK rollover has long closed. If your resolvers have answered normally since October 13, they most likely trust the new key. The risk now comes from systems that were offline during the change.
Where the risk sits now
Akamai lists the places a stale trust anchor hides: golden images, VM templates, containers and appliance backups. Restore one of those and you restore the old key with it. Devices that were powered off, rebuilt or restored during the 30-day learning window can miss the new key too. So can resolvers whose trust anchor file is read-only.
Appliances are the easiest to miss. Akamai names firewalls, load balancers, security appliances and branch-office devices as systems that may validate DNSSEC on their own. One user on the Virtualmin community forum reported on October 12 that an ASUS router on older Asuswrt-Merlin firmware lacked the new key. The poster’s advice was to update the firmware and confirm key 38696 is present. If you keep an IT asset inventory, this is a good week to check which devices do their own DNS. Our firewall explainer covers what those boxes do beyond blocking traffic.
How to test a resolver after the root KSK rollover
The quickest check uses RFC 8509, the root key sentinel. A resolver that supports it answers special test names differently depending on which keys it trusts. Cloudflare runs a browser test at dnstest.dev/ksk-2024 that checks whatever resolver your browser uses.
To test a specific server, Cloudflare’s post gives these two commands. Replace 1.1.1.1 with your resolver’s address:
dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer
dig @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answerA ready resolver answers the first name and returns SERVFAIL for the second. If both names resolve, the resolver probably does not support RFC 8509. That result says nothing about the key either way, so check the trust anchor directly.
If a site will not load, compare a normal query with one that turns validation off. In dig, +cd sets the "checking disabled" bit. If the name fails without +cd and resolves with it, validation is the problem.
One caution on delv. By default it validates with its own built-in root key. It tells you what delv trusts, not what your server trusts.
How to check and fix the root KSK rollover on each platform
ICANN’s guidance is direct: "Do not assume automatic trust-anchor updates succeeded." Look for key tag 38696 on each server.
BIND. Run rndc managed-keys status (BIND 9.11 and later) or rndc secroots. Look for 38696. ISC’s root KSK rollover article notes that dnssec-validation auto keeps the root key current, while dnssec-validation yes with a hand-entered key needs manual action. If the key is missing, ISC says the first thing to check is that BIND can write to its directory or managed-keys-directory.
Unbound. Check the root.key file named in auto-trust-anchor-file. NLnet Labs recommends running unbound-anchor before Unbound starts, for example unbound-anchor -a "/usr/local/etc/unbound/root.key". Your path may differ by distribution. On Unbound 1.6.2 and later, ICANN suggests dig @address trustanchor.unbound -c CH -t TXT to read the live trust anchors.
PowerDNS Recursor. Run rec_control get-tas.
Windows Server DNS. Run Get-DnsServerTrustAnchor -Name . in PowerShell. Look for 38696 in the root entries. If none are listed, the server has no root trust anchor. If 38696 is missing, Microsoft documents Add-DnsServerTrustAnchor -Root, which loads root trust anchors from the server’s RootTrustAnchorsURL setting. We found no Microsoft guidance specific to KSK-2024 as of October 14.
Appliances. Check the vendor’s release notes for KSK-2024 or key tag 38696, and update firmware.
If users are failing right now
ICANN’s What to Expect guide gives two stopgaps. You can turn off DNSSEC validation for a short time, or add a negative trust anchor for the root zone. Either one stops the failures.
Both remove protection, so treat them as temporary. Install KSK-2024 as a trust anchor, confirm with the sentinel test, then turn validation back on.
ICANN asks anyone with possible rollover problems to email its support team with "KSK Rollover" in the subject line. The address is on the ICANN rollover page. If you are writing up the incident, add the steps to your disaster recovery plan. The next restore from an old image will bring the same problem back.
Frequently Asked Questions
What is the root KSK rollover?
It is the replacement of the key that signs the top of DNS. On October 11, 2026, KSK-2024 (key tag 38696) replaced KSK-2017 (key tag 20326). It is the second root KSK rollover since the root was signed in 2010.
Did anything break on October 11?
As of October 14, ICANN says “No indications of widespread operational disruption have been observed.” We found one user report of an older home router that lacked the new key. The poster recommended a firmware update.
Do I need to do anything if we use 1.1.1.1 or our ISP’s DNS?
No. The resolver operator handles the key. Cloudflare says 1.1.1.1 has trusted KSK-2024 since July 2024.
What is key tag 38696?
It is the short ID for KSK-2024. Every trust anchor file and status command shows key tags, so 38696 is the number to look for.
What does a failed resolver look like to staff?
Sites look down even though they are up. The resolver returns SERVFAIL. Failures can be intermittent, and email may stop arriving.
Will our resolver pick up the new key on its own now?
Not if it missed it before October 11. Automatic updates under RFC 5011 need a key set signed by a key the resolver already trusts. The root is now signed only by KSK-2024, so a manual update or new software is needed.
Why check again if everything works today?
Old server images, VM templates, appliance backups and spare devices can still carry only the old key. Restoring one brings the failure back.
What happens to KSK-2017 next?
ICANN’s FAQ lists revocation and removal from the root zone in the first quarter of 2027, then deletion of the private key from both key facilities later in 2027.
Can we turn off DNSSEC validation to fix it?
ICANN lists that as a temporary fix, along with a negative trust anchor for the root. Install KSK-2024 and turn validation back on as soon as you can.
Does this change anything for our own website or domain?
No. Cloudflare says most website operators do not need to make any changes. Signed domains keep their own keys. The rollover only affects resolvers that look names up.
