Is Your Server's DNS Resolver Trusting the New Root Key?

If your VPS runs its own validating DNS resolver, such as Unbound or BIND, it must now trust the new root key, KSK-2024, key tag 38696, or it can stop resolving signed names. You can check in about ten minutes: find the trust anchor file, look for 38696, and confirm with one dig query that answers come back validated. Most servers updated themselves long ago, but "most" is not the same as "mine".

Here is the surprising part. On 11 October 2026 the root zone stopped signing with the key it had used since 2018. According to ICANN's guide, a resolver that only knows the old key keeps working from cache for a while, then fails "at some point within 48 hours after the rollover", and the exact moment cannot be predicted. So a server that looked fine on Sunday can fail to reach its own database host or payment API on Tuesday, with nothing in the deploy log to explain it.

By the end of this guide you will be able to check which root key your resolver trusts, fix it safely on Unbound or BIND, prove the fix with real queries, and know what to ask your host if you are on shared hosting.

What the root KSK rollover actually is

DNSSEC adds digital signatures to DNS answers, so a resolver can tell a real answer from a forged one. A validating resolver is a DNS server that checks those signatures before it hands an answer to your applications.

Every chain of signatures starts at the root zone's Key Signing Key, or KSK. Your resolver keeps a copy of the trusted root key in a local file called a trust anchor, and checks everything else against it.

Think of an office building that changed its master key. Every tenant got a copy of the new key in early 2025, with a note saying it takes over in October 2026. Tenants who filed it away are fine. Tenants who threw the note away are now locked out.

At the time of writing (1 November 2026), IANA lists the timeline like this:

• 11 January 2025: KSK-2024 was introduced in the root zone.
• 10 February 2025: resolvers that follow RFC 5011 (the standard for updating trust anchors automatically) should have started trusting it.
• 11 October 2026: KSK-2024 started signing the zone and KSK-2017 stopped.
• 11 January 2027: KSK-2017 is scheduled to be published with the REVOKE bit set, so RFC 5011 resolvers can revoke it.
• 22 March 2027: KSK-2017 is scheduled to be removed from the root zone.

A key tag is a short number that identifies a key. IANA lists KSK-2024 with key tag 38696 as "Signing since 2026-10-11". The old key, KSK-2017, has key tag 20326.

ICANN announced on 15 October 2026 that the rollover completed as planned. It also said it is aware of reports of issues affecting a limited number of systems and is still assessing whether they relate to the rollover. Nobody has tied a specific outage to it, and this guide does not either. The goal is simply to make sure your resolver is not one of those systems.

Why this matters: ICANN's FAQ says resolvers without the new key "will treat responses signed under the new key as having been tampered with and will discard those responses". Your applications then see SERVFAIL, a DNS error that means "I could not give you a trustworthy answer".

Before you start

This guide is for people who run their own recursive resolver on a VPS or dedicated server. On shared hosting your host runs the resolver, so skip to the shared hosting section.

• SSH access to the server, with sudo rights.
• Knowing which resolver you run. If you are not sure, systemctl status unbound and systemctl status named will tell you.
• The dig tool, which ships with the BIND utilities package on most distributions.
• About 10 to 20 minutes, plus a quiet moment for a resolver restart.
• A backup of the trust anchor file and resolver config. The steps show how.

Risk level: checking is read-only and safe. Updating the anchor and restarting is low risk, but DNS on that server is briefly unavailable during the restart, so avoid your busiest hour.

Heads up: according to the ICANN and Verisign rollover notes, BIND uses bind.keys, Unbound and PowerDNS Recursor use root.key, and Knot Resolver uses root.keys. For PowerDNS Recursor and Knot Resolver, apply the same idea (back up, search for 38696, check the service user can write the file) and follow your vendor's own update steps, as ICANN advises.

Check and fix Unbound

Unbound tracks the root key through the auto-trust-anchor-file setting, which the unbound.conf manual describes as a "file with trust anchor for one zone, which is tracked with RFC 5011 probes". If Unbound can write to that file, it should have learned 38696 in 2025.

Step 1: Find the trust anchor file

Package builds put the file in different places, so ask Unbound itself. This command checks your config and prints the value of the setting:

sudo unbound-checkconf -o auto-trust-anchor-file

You should see a single path. The default named in the unbound-anchor manual is /usr/local/etc/unbound/root.key, but your distribution may differ. If the line is empty, the setting is off; check the static setting instead:

sudo unbound-checkconf -o trust-anchor-file

Step 2: Back up the file

This copies the file and keeps its owner and permissions. Replace the path with the one from Step 1:

sudo cp -p /usr/local/etc/unbound/root.key /usr/local/etc/unbound/root.key.bak-2026-11-01

Run ls -l on the directory and you should see both files with the same owner.

Step 3: Look for key tag 38696

ICANN's advice is short: "The key to look for is Key Tag 38696." This searches the file for it:

sudo grep -n 38696 /usr/local/etc/unbound/root.key

Matching lines are a good sign. No match is a strong hint to continue with Step 4, though the final proof is the query test in "How to check it worked". Now check who owns the file:

ls -l /usr/local/etc/unbound/root.key

The unbound-anchor manual says that for RFC 5011 tracking, "the user that Unbound runs under (by default 'unbound') must have write permissions to the file". A root-owned file that unbound cannot write is a very likely reason the key never updated.

Step 4: Update the anchor as the unbound user

The unbound-anchor tool reads and writes the file named with -a. If needed, it downloads root-anchors.xml from data.iana.org and verifies its signature before using it.

Quick tip: run it as the unbound user, as the manual suggests. Running it as root can leave a root-owned file that Unbound cannot update, which recreates the problem.

If Step 3 showed the wrong owner, this gives the file back to the Unbound user and group (confirm the names with id unbound first):

sudo chown unbound:unbound /usr/local/etc/unbound/root.key

This runs the update as the Unbound user. The -v flag matters, because by default the tool "prints nothing on errors":

sudo -u unbound unbound-anchor -a /usr/local/etc/unbound/root.key -v

Do not trust the exit code alone, because the manual warns that a zero can also cover an error. Read the -v messages and repeat the grep from Step 3 to confirm the key is there.

Step 5: Restart Unbound and read the logs

This restarts Unbound so it loads the file:

sudo systemctl restart unbound

This shows the log for the last few minutes:

sudo journalctl -u unbound --since "10 minutes ago"

You want a normal start with no trust anchor or validation errors. To make Unbound explain failed validations, the manual describes val-log-level: 1 logs each failed query, 2 also gives the reason. This snippet goes in the server: section, followed by another restart:

server:
    val-log-level: 2

Set it back to 0 when you are done, because it makes busy logs noisy.

Check and fix BIND

The BIND DNSSEC guide says that with dnssec-validation auto, BIND uses its built-in root trust anchor and keeps it up to date "without intervention from the DNS administrator". ISC recommends auto "unless there is a good reason to require a manual trust anchor".

Step 1: See which validation mode you use

Your main config may be /etc/named.conf or /etc/bind/named.conf.options. This searches both places for the relevant settings:

sudo grep -rn "dnssec-validation\|trust-anchors\|static-key\|managed-keys" /etc/bind /etc/named.conf 2>/dev/null

What the results mean:

• dnssec-validation auto; is the good case. BIND manages the root key itself.
• dnssec-validation yes; with a static-key in a trust-anchors block means someone pinned the key by hand. The guide says such a key is "always trusted until it is deleted from the configuration file", so if it only holds the old key, your resolver lost the root.
• dnssec-validation yes; with no root key means no validation takes place, per the guide. The rollover cannot break you, but DNSSEC is not protecting you either.

Step 2: Back up the config

This creates a dated archive of the BIND config directory in your home directory:

sudo tar -czf ~/bind-config-backup-2026-11-01.tar.gz /etc/bind

On systems that use /etc/named.conf, add that file to the command. Leave the managed keys database in BIND's working directory alone; the guide names its journal managed-keys.bind.jnl.

Step 3: Ask BIND what it trusts

ISC's knowledge base on root KSK rollovers points to two rndc commands. This one dumps the server's security roots and negative trust anchors:

sudo rndc secroots

Look for 38696 in the root zone entries. This one prints the status of the managed keys database:

sudo rndc managed-keys status

You should see the root zone with key 38696 trusted. ISC explains that a newly seen key shows as pending first and becomes trusted after 30 days, so a healthy server finished that long ago.

Step 4: Fix what you found

If 38696 is not trusted, check that BIND can write to its working directory. ISC says these directories must be writable by the user BIND runs as. Find them in the directory and managed-keys-directory settings, check the owner with ls -ld, fix it if wrong, then force a refresh:

sudo rndc managed-keys refresh

If Step 1 found a hand-pinned static-key for the root, remove or comment out that entry and make sure the options block contains this setting:

options {
    dnssec-validation auto;
};

This reloads the configuration without a full restart:

sudo rndc reconfig

Heads up: the DNSSEC guide's own example of BIND's built-in key block still mentions key 20326 from 2017. A very old build that only knows 20326, with an empty managed keys database, cannot learn 38696 by itself now that the old key has stopped signing. If a refresh does not help, update BIND through your distribution and check again.

Step 5: Restart if needed and read the logs

After an ownership change or package update, this restarts BIND (the unit is named on many systems and bind9 on some Debian based ones):

sudo systemctl restart named

This shows the recent log:

sudo journalctl -u named --since "10 minutes ago"

Run rndc managed-keys status again. You should see 38696 trusted.

If you are on shared hosting

On shared hosting there is no resolver file for you to check. Your host's servers resolve names for your PHP scripts, cron jobs and mail. If you see a sudden wave of "could not resolve host" errors, open a short ticket and ask:

1. Do the resolvers used by my account validate DNSSEC?
2. If yes, do they trust the root KSK-2024, key tag 38696?
3. Do they track root key changes automatically, so the January 2027 revocation needs no manual work?

Resolver trust is a separate problem from your own records. If you manage zones too, our guide on cleaning up dangling DNS records covers that side.

If DNS is failing right now

ICANN's "What to Expect" guide lists two temporary measures: disable DNSSEC validation, or configure "a negative trust anchor for the root zone (see RFC 7646)", which tells the resolver to stop validating under that name. Then install KSK-2024 "as soon as possible" and turn validation back on.

On BIND, this turns validation off without editing files:

sudo rndc validation off

Once Steps 3 to 5 show 38696 trusted, this turns it back on and confirms the state:

sudo rndc validation on
sudo rndc validation status

Why this matters: with validation off, the resolver accepts forged answers without complaint. It is like pulling the battery from a beeping smoke alarm: fine for ten minutes while you find the cause, never as the fix.

How to check it worked

The file tells you what the resolver should trust; queries show what it actually does. Run these on the server, against the local resolver.

This sends a query with the DNSSEC OK bit to your resolver:

dig @127.0.0.1 example.com A +dnssec

In the ;; flags: line, look for ad, plus status: NOERROR. The dig manual says the AD (authentic data) bit means all records were validated as secure, and the BIND guide calls the ad flag "the important detail in this output".

If you got SERVFAIL, this repeats the query with checking disabled:

dig @127.0.0.1 example.com A +cd

The BIND guide's rule: "If the query succeeds with dig +cd, but ends in SERVFAIL without it, you know you are dealing with a validation problem." If both fail, look at network reachability, not the root key.

This prints the root key set with human-readable comments, thanks to +multiline:

dig @127.0.0.1 . DNSKEY +dnssec +multiline

The comments next to the keys should include key id 38696, and the answer should carry ad.

For a second opinion, this runs delv, whose +vtrace option toggles validation logging:

delv @127.0.0.1 example.com A +vtrace

You should see the chain checked from the root down with no validation failure. One caution: delv uses its own built-in root anchor, and its manual says "RFC 5011 key management is not supported". So delv tests the DNS data, while dig tests your resolver. Use both.

Made-up example: imagine a made-up shop server, shop.example.com, whose checkout calls a payment API by name. Its owner runs the checks and sees ad, 38696 in the DNSKEY comments, and a clean delv trace. Ten minutes, no restart. That is the result most readers will get, and it is worth getting on purpose rather than by luck.

Troubleshooting

Symptom: every lookup returns status: SERVFAIL, but +cd works

Cause: the resolver does not trust 38696, so it rejects the newly signed root key set.

Fix: follow Steps 3 and 4 for your resolver. Use the temporary measures above only if you need DNS back while you work.

Symptom: grep 38696 finds nothing and root.key is owned by root

Cause: the file was created or updated as root, so Unbound could not write RFC 5011 updates into it.

Fix: chown the file to the Unbound user, run unbound-anchor with sudo -u unbound and -v, then restart.

Symptom: unbound-anchor prints nothing, returns 0, and the key is still missing

Cause: exit code 0 also covers errors, and the tool is silent without -v. A firewall blocking HTTPS to data.iana.org is one possible reason.

Fix: rerun with -v (repeat it for more detail), read the message, and allow outbound HTTPS to that host if it is blocked.

Symptom: rndc managed-keys status shows only key 20326 for the root

Cause: BIND could not write its working directory, or a very old build started with only the 2017 key.

Fix: fix the directory owner, run rndc managed-keys refresh, and update BIND if 38696 still does not appear.

Symptom: lookups validate, but your own domain points to the wrong place

Cause: that is a record problem, not a root key problem. A healthy resolver shows exactly what the zone says.

Fix: check where your records are really served. Our guides on mapping a host to a domain and fixing shadowed Cloudflare DNS records cover the usual causes.

What happens in January and March 2027

On 11 January 2027 IANA plans to publish KSK-2017 with the REVOKE bit set, and on 22 March 2027 to remove it. A resolver tracking keys automatically will mark the old key revoked and later drop it.

Quick tip: set a calendar reminder for the week after 11 January 2027 and rerun the dig checks. If you still see 38696 and ad, you are done until the next rollover.

The one message worth forwarding

Send this to whoever runs DNS for your servers, or to your host's support team:

"Hi, the DNS root zone switched to the new root key KSK-2024 (key tag 38696) on 11 October 2026, per IANA. Could you confirm for each validating resolver we use: (1) that its trust anchor includes key tag 38696, (2) that dig @<resolver> example.com A +dnssec returns the ad flag, and (3) that the resolver can write its trust anchor file, so the KSK-2017 revocation on 11 January 2027 is handled automatically? If validation was turned off anywhere as a workaround, please tell me when it will be back on. Thanks."

The takeaway: grep for 38696 and look for ad in one dig query, and in ten minutes you know whether your resolver trusts the new root key.