DNS Root Key Rolls to KSK-2024: 3 Checks for Small Sites

On October 11, the key that signs the very top of the DNS, the root zone, rolls over to a new one called KSK-2024. If your site uses DNSSEC and the resolver your visitors rely on is holding the old trust anchor, DNSSEC validation can fail and your domain simply stops resolving for those people. Not a slow page. Gone.

The good news: for most small sites, nothing will break, because the resolvers you depend on already trust the new key. But "most" isn't "all," and the fix if you're caught out is five minutes of work you'd rather do before the rollover than during it. Here are the three checks to run this week, in plain terms, written for people who own websites rather than run nameservers.

If you host with us, you can stop reading and relax: TPC Hosting's resolvers and signing are already on KSK-2024. The rest of this is for the parts of your stack we don't control, your office network, your laptop, and any DNS you run yourself.

What's actually changing on October 11

The Key Signing Key for the DNS root is being replaced, and every validating resolver needs the new key's trust anchor to keep checking DNSSEC signatures. The root zone is the foundation that signs everything beneath it. A fresh KSK was generated (named KSK-2024), published alongside the old one for months, and on rollover day the old key stops being used for signing.

Here's the part that matters: this only affects resolvers that validate DNSSEC. A resolver that ignores DNSSEC entirely won't notice. A resolver that validates but has the new trust anchor won't notice either, it's been ready for ages. The only machines in trouble are ones that validate DNSSEC and somehow never received KSK-2024. That's a small slice: stale forwarders, a Pi-hole or Unbound someone set up years ago and never updated, or an appliance with hardcoded anchors.

If that resolver is the one your customers use, your DNSSEC-signed domain will look dead to them. The rollover itself is run competently by ICANN; the risk lives at the edges, in gear nobody has touched since it was installed.

Check 1: Is my resolver ready? Use the RFC 8145/8509 sentinel

Run a sentinel test to confirm the resolver you use already trusts KSK-2024. RFC 8509 defines special "sentinel" hostnames that answer differently depending on which root keys your resolver trusts, so you can test from any browser without touching config files.

The easiest path is a hosted test page. Open one of these from the network you want to check, your office Wi-Fi, your home line, a phone on mobile data:

• dnssec-tools.org sentinel checkers, or search "DNSSEC root KSK sentinel test"
• ICANN and APNIC both publish rollover test pages that give a plain green/red answer

If you're comfortable at a terminal, you can query the sentinels directly. One important catch: the sentinel names only mean something when the zone you query actually implements RFC 8509. Do not use example.com here, it is a placeholder and will give you a meaningless answer. APNIC runs a working sentinel zone at rootcanary.net, so query against that. The key tag for KSK-2024 is 38696. Run these two lookups:

• Valid key test: dig +short kskroll-sentinel-is-ta-38696.rootcanary.net A
• Negative test: dig +short kskroll-sentinel-not-ta-38696.rootcanary.net A

A resolver that already trusts KSK-2024 resolves the "is-ta" name (you get an A record back, NOERROR) and returns SERVFAIL for the "not-ta" name. That is the healthy result. In full dig output the difference is in the header: a good answer shows status: NOERROR with an address in the ANSWER section, while a failure shows status: SERVFAIL and an empty ANSWER. If both names resolve, your resolver isn't validating DNSSEC at all (no immediate danger, but no protection either). If the "is-ta" name fails while a plain lookup like dig rootcanary.net works, that resolver is not ready, and that's your action item.

Test every network your team actually uses to reach your own site. The one that catches people out is a forgotten internal resolver in the office, not the big public ones.

Check 2: Is my own DNS ready? (self-hosted resolvers and plugins)

If you run your own resolver, confirm its trust anchors auto-update via RFC 5011; if not, update them by hand before the 11th. This is where the real breakage happens for small outfits, the self-managed box nobody remembers.

Modern resolvers handle this automatically. BIND, Unbound and Knot all support RFC 5011 automated trust anchor updates, which means they picked up KSK-2024 when it was published and will switch over on their own. Confirm it's on:

• Unbound: check that auto-trust-anchor-file points at a writable root.key and inspect it, you should see the 38696 key listed. Or run unbound-anchor -v.
• BIND: confirm dnssec-validation auto; is set, or that your managed-keys / trust-anchors block is being maintained. Look in the managed-keys database for key tag 38696.
• Pi-hole with unbound: this is the classic risk. Run sudo unbound-anchor and restart unbound. Old installs with a static root.key never got the memo.

Here's how to read root.key with your own eyes. Open the file (cat /var/lib/unbound/root.key on most Debian/Ubuntu setups) and look at the DNSKEY lines. Each ends with a comment from the automation, something like ;;id = 38696 (ksk), size = 2048b ; state = 2 [ VALID ]. The id = 38696 is KSK-2024; state = 2 [ VALID ] means your resolver has fully trusted it and will keep validating after the rollover. If you see 38696 but it reads state = 1 [ ADDPEND ], the RFC 5011 hold-down timer hasn't elapsed yet, which brings us to the caveat below.

If your resolver software is more than a couple of years out of date, update the package first, then the anchors. A resolver shipped before mid-2024 won't know KSK-2024 exists until you tell it.

One honest caveat: if your box has been offline for weeks, RFC 5011 has a hold-down timer and may not have fully trusted the new key yet. When in doubt, fetch the anchor manually with unbound-anchor rather than hoping the automation caught up.

Check 3: Is my domain itself signed, and does it still validate?

Confirm your domain's own DNSSEC chain is intact, because a broken chain looks identical to a rollover failure and is far more common. The rollover is a convenient moment to verify the thing you do control: your domain's signatures and DS record.

Run your zone through an external validator:

• DNSViz draws the full chain from the root down to your records, any red means a problem
• Verisign DNSSEC Analyzer gives a quick pass/fail per step

Two things trip people up. First, a mismatched DS record: you enabled DNSSEC at your DNS host but the DS record at your registrar points at an old key, or was never added. Second, expired signatures (RRSIGs), which happens when signing automation quietly stalls. Both produce SERVFAIL on validating resolvers, and both get blamed on "the rollover" when they have nothing to do with it.

If you don't run DNSSEC on your domain at all, October 11 cannot break your domain, full stop. You might still hit a broken resolver (Check 1), but your own zone is fine. If you do run it, five minutes in DNSViz buys real peace of mind.

What to tell your host if something breaks

If your site goes dark after the rollover, give support the exact symptom and the two test results above, not "my site is down." That turns a long back-and-forth into a quick fix.

Say this: "DNSSEC validation is returning SERVFAIL after the KSK-2024 rollover. Here's the DNSViz output for my domain, and the sentinel test for key tag 38696 from my network." A good host will tell you within minutes whether the fault is in your zone, your registrar's DS record, or a resolver on your side.

This is the part we're genuinely built for. With TPC Hosting you can reach our AI assistant on chat at any hour, and real engineers follow up in business hours, so a 2am "is it me or the rollover?" doesn't sit in a ticket queue until Monday. Our EU-hosted resolvers and signing are already on KSK-2024, so if you're on us, the only moving part left is anything you run yourself.

Your pre-October-11 checklist

Do these four things this week and you're covered.

• Run the RFC 8509 sentinel test (key tag 38696) against rootcanary.net from every network your team uses
• If you run your own resolver, confirm RFC 5011 auto-update is on, or fetch the anchor with unbound-anchor and check for state = 2 [ VALID ]
• Validate your own domain in DNSViz and confirm the DS record at your registrar matches
• Know your host's fastest support channel in case something slips

None of this needs a DNS engineer. It needs twenty minutes before the 11th instead of a panicked hour after it.

FAQ