Blog

On Sunday, October 11, 2026, the DNS root zone started signing its keys with a new key-signing key, known as KSK-2024. That key is the starting point for every DNSSEC validation on the Internet, and it has changed only once before, in October 2018.

For most networks the switch passed unnoticed: ICANN reported in July that more than 95 percent of reporting resolvers had already recognized the new key. For the rest it is anything but quiet. A validating resolver that doesn’t trust KSK-2024 can no longer validate anything, and every lookup through it fails.

What changed on October 11

DNSSEC works as a chain of signatures. A validating resolver starts from one key it already trusts, the root zone’s key-signing key, which is configured in the resolver as a trust anchor. That key vouches for the rest of the root zone’s keys, the root vouches for each top-level domain, and each top-level domain vouches for the domains under it.

A resolver whose only trust anchor is KSK-2017 can no longer verify the root’s key set, so it can’t verify anything beneath it either. It doesn’t quietly fall back to resolving without DNSSEC. It fails every lookup, for signed and unsigned domains alike.

Who’s affected, and who isn’t

The usual suspects:

• Resolvers that couldn’t save the new key. Automatic updates need write access to the trust anchor file. A read-only filesystem or the wrong permissions stops the update without much fuss.
• Static trust anchors. A key pasted into a configuration file, such as BIND’s old trusted-keys or a static-key entry, never updates itself.
• dnsmasq and Pi-hole with DNSSEC turned on. They read the root key from fixed trust-anchor= lines in their configuration.
• Firewalls, routers and other appliances that validate DNS with a key list baked into their firmware.
• Old images and long-offline machines. A VM template, container image or restored backup that only knows KSK-2017 can’t learn the new key through DNS any more, because the old key no longer signs anything.
• Windows Server DNS, but only if someone added a trust anchor for the root. Without one, it doesn’t validate the root’s chain and wasn’t affected.

Check a resolver in a minute

The root’s keys are now signed only by KSK-2024, so the test is simple: a resolver that can validate a signed domain trusts the new key (with one caveat for this week, below). Run these from any machine with dig, replacing 192.0.2.53 with your resolver’s address:

# Ask for a DNSSEC-signed name; look at the status and for "ad" in the flags
dig @192.0.2.53 icann.org A +dnssec | grep -E 'status:|flags:'

# If that returns SERVFAIL, ask again with validation switched off
dig @192.0.2.53 icann.org A +cd | grep 'status:'

To look at the trust anchors themselves, check for key tag 38696:

For anything else, including appliances, the dig test above is the reliable check.

Fixing a resolver that’s failing

• Update the software or firmware first. Current releases of the major resolvers include KSK-2024, and an update is usually the cleanest fix.
• Unbound: run unbound-anchor -a /var/lib/unbound/root.key (use your own file path). It fetches the current anchor from IANA’s published file and verifies it. Many distributions already run it whenever Unbound starts, so a restart may be all it takes.

• PowerDNS Recursor: it doesn’t follow root key changes on its own, because it has no RFC 5011 support. It uses the root key built into the release unless dnssec.trustanchorfile in its configuration points to a trust anchor file, such as /usr/share/dns/root.key from the dns-root-data package on Debian and its derivatives. A root key in that file overrides the built-in one, so a stale file can break even an up-to-date recursor. Check both:

  # Root keys the running recursor trusts (look for 38696)
  rec_control get-tas
  
  # If dnssec.trustanchorfile is set, check the file too (use your path)
  grep 38696 /usr/share/dns/root.key

  If 38696 is missing, update pdns-recursor and dns-root-data, or replace the file with IANA’s current anchors. Then restart the recursor so it loads the file right away; otherwise it only re-reads the file every 24 hours.

• BIND: replace any static anchor in named.conf by hand. If you use dnssec-validation auto;, make sure the keys built into your BIND version include 38696 (upgrade if they don’t), then run rndc managed-keys destroy so BIND reloads its trust anchors from them.
• dnsmasq and Pi-hole: update to a release that includes the new anchor, or add a trust-anchor= line for key tag 38696 using the DS values in IANA’s root anchors file.
• Appliances: apply the vendor’s firmware update. If there isn’t one, turn validation off on the device and let it forward to a validating resolver you control.
• Make the fix stick. Give the resolver write access to its trust anchor file so the next rollover happens automatically.
• Turning validation off is a stopgap, not a fix. If you have to do it to get people working, turn it back on once the trust anchor is right.

If your DNS is hosted with CloudFloorDNS

Nothing changed for your zones. If you sign them with our one-click DNSSEC, we manage your zone’s keys, and the root’s key change touches neither them nor the DS record at your registry. Unsigned zones are unaffected too.

Where it may show up is support. If someone tells you this week that your site, along with everything else, stopped loading on one network while it still works over mobile data, ask what resolver that network uses. A resolver that fails on the new key breaks every domain, not just yours.

And if your zones aren’t signed yet, they aren’t part of the chain of trust this rollover protects. CloudFloorDNS Managed DNS offers one-click DNSSEC signing, with the key management handled for you.

What happens next

The rollover isn’t finished. In 2027, ICANN plans to revoke KSK-2017 and remove it from the root zone. Resolvers that already trust KSK-2024 need nothing more; the revocation simply tells resolvers that track the root’s keys automatically to stop trusting the old one.

This won’t be the last root key change, either. Keep automatic trust anchor updates working and resolver software current, and the next one should pass without anyone noticing.

Frequently asked questions

Do I need to change my DS records or re-sign my zones?

No. The rollover changed the key at the very top of the chain. Your zone’s keys, and the DS record that links your zone to its top-level domain, are separate and didn’t change.

We don’t use DNSSEC. Are we affected?

Not as a domain owner. But if your network’s resolver validates DNSSEC, and many do by default, it needed the new key to keep resolving anything at all, including domains that aren’t signed.

Can I see the change for myself?

Yes. Run dig . DNSKEY +dnssec +short | awk '$1=="DNSKEY" {print $7}'. It prints the key tag of the key that signs the root’s key set: 20326 before October 11, 38696 since.

Will this happen again?

Yes. The root key is designed to be replaced over time. Resolvers that update their trust anchors automatically, and can write to their trust anchor file, handle it without help.

Related

• Managed DNS with one-click DNSSEC
• Secondary DNS with TSIG and DNSSEC
• Why is DNS so important?
• ICANN: Preparing for the Root Zone KSK Rollover