The DNSSEC Trust Anchor Your Rebuild Threw Away

Written 9 October 2026. The rollover described here is scheduled for 11 October 2026.

On 11 October 2026 the DNS root changes the key that anchors DNSSEC. KSK-2024, key tag 38696, takes over from KSK-2017, key tag 20326, as the signer of the root's DNSKEY set. It is only the second time the root key-signing key has been rolled.

For most people this is a non-event. Cloudflare's guide, published on 6 October 2026, puts it plainly: "Most website operators do not need to make any changes for this rollover." Your domain's DNSSEC records do not change. What changes is the starting point that validating resolvers use to check every signed answer, and the people who need to act are the ones who run those resolvers.

Cloudflare's action line for them is: "If you run a DNSSEC-validating resolver, check that it trusts the new root key, KSK-2024, and follow your software vendor's instructions to update its trust anchors if the key is missing."

This article is about one group inside that group, which is easy to miss: resolvers that were set up correctly, learned the new key, and then lost it because the machine or container was rebuilt or restored.

What happens if a resolver does not trust the new key

A validating resolver cannot check any DNSSEC signature without a root key it already trusts. Once KSK-2024 signs the root's DNSKEY set, a resolver that only trusts KSK-2017 can no longer verify the root, and everything below the root depends on that. In Cloudflare's words: "If a resolver does not trust the replacement key, its users may be unable to reach websites under any top-level domain."

The failure does not look like a DNSSEC problem from the outside. Applications see lookups fail, for names that are working for everyone else.

How a resolver learns the new key: RFC 5011

Validating resolvers do not have to be updated by hand for a rollover. RFC 5011 lets them learn a new root key automatically: the root publishes the new key alongside the old one, signed by the old one, and a resolver that keeps seeing it accepts it after a waiting period. Cloudflare summarises the rule: "the resolver waits at least 30 days and keeps checking the root's signed DNSKEY records."

IANA's timeline for this rollover:

So a resolver that has been running continuously since early 2025 with RFC 5011 enabled should have trusted KSK-2024 for about twenty months. That leaves a short list of resolvers at risk:

• resolvers with automatic trust-anchor updates turned off;
• resolvers with a root trust anchor pinned by hand in their configuration;
• resolvers whose learned state was thrown away.

The first two are configuration choices someone made deliberately. The third usually happens by accident.

Where learned trust goes missing

RFC 5011 is stateful. What a resolver has learned about the root keys is written to a file on disk, separate from the software and its configuration. If that file is replaced with an older one, the resolver forgets it ever saw KSK-2024. This is not hypothetical. Describing the first root rollover in 2018, Cloudflare wrote that "software upgrades and moves between machines caused some resolvers to lose their learned trust-anchor state."

The hosting-shaped versions of this:

• A resolver inside a container image. If the trust-anchor file is baked into the image and the resolver writes its updates into the container's writable layer, every recreate starts again from the file in the image. If that file predates KSK-2024, the resolver goes back to trusting only KSK-2017.
• A golden image or base template. Every server built from an image taken before the resolver accepted KSK-2024 starts with the old state.
• A restore from an old snapshot or backup. Restoring a server, or just its /var/lib, can put back a trust-anchor file from before the resolver learned the new key.

Each of these resolvers will start learning KSK-2024 again through RFC 5011, because the key is still published. The problem is the clock. The 30-day wait starts when the resolver first sees the new key, so a resolver that started from old state later than about 11 September 2026 cannot finish waiting before the switch on 11 October 2026. A container that is recreated more often than every 30 days, with its state discarded each time, never finishes at all.

What it looks like: a test with Unbound

On 9 October 2026 we ran Unbound 1.24.2 on a test machine with an auto-trust-anchor-file seeded with only the KSK-2017 record, which is what an old image or snapshot would contain. A few seconds after start, the file showed the resolver had seen the new key and was waiting on it:

; {id = 38696 (ksk), size = 2048b} ;;state=1 [ ADDPEND ] ;;count=1
; {id = 20326 (ksk), size = 2048b} ;;state=2 [  VALID  ] ;;count=0

ADDPEND is the RFC 5011 waiting state: seen, not yet trusted. Asked directly (see the next section), the resolver answered that it did not trust key 38696. An ordinary lookup through it still succeeded, because KSK-2017 is still the signing key. Nothing about this resolver looks wrong until the rollover.

The same resolver started from a fresh trust-anchor file showed both keys as state=2 [ VALID ] and reported that it trusted 38696.

How to check your resolver

1. Ask the resolver with the trust anchor sentinel

RFC 8509 defines a way to ask a resolver whether it trusts a particular root key. You query two special names; a resolver that supports the sentinel validates them and then deliberately fails one of them. Cloudflare's test names live under dnstest.dev. Replace RESOLVER_IP with the address of the resolver you want to check:

dig @RESOLVER_IP root-key-sentinel-is-ta-38696.dnstest.dev A +noall +comments
dig @RESOLVER_IP root-key-sentinel-not-ta-38696.dnstest.dev A +noall +comments

Read the status: field of each answer:

The last row needs care. A resolver that supports the sentinel always fails exactly one of the two names, whichever way it answers. Two normal answers mean the sentinel was not used, either because the resolver does not support RFC 8509 or because it is not validating. Cloudflare is explicit that this is not a pass or a fail: "If sentinel support cannot be established, the result is inconclusive; it does not mean the new key is missing." In that case, check the resolver's own trust-anchor state (step 2).

Cloudflare also runs a browser-based readiness test. It is convenient, but as Cloudflare notes, "The browser test checks the resolver your browser uses, which may be affected by Secure DNS or a VPN." A laptop using encrypted DNS can pass while the resolver your servers use fails. To test a server's resolver, run dig on that server against that resolver.

2. Look at the trust-anchor state

For Unbound, open the file named by auto-trust-anchor-file in your configuration and find the line for key 38696:

grep 38696 /path/to/root.key

You want state=2 [ VALID ]. ADDPEND means the resolver is still in its 30-day wait, and no line at all means it has not seen the key. For other resolver software, your vendor's documentation describes where it keeps managed trust anchors and how to list them.

Fixing a resolver that lost the key

Waiting is not a fix if the resolver cannot complete its 30 days before 11 October 2026. Load the current trust anchors directly instead.

One trap we hit with Unbound: running unbound-anchor against a stale file does not repair it. In our test it printed success: the anchor is ok and exited 0, because the old key still validates the root, and the file was left with KSK-2024 in ADDPEND. A clean exit code here means only that the file works, not that it contains the new key.

What did work in our test was letting unbound-anchor rebuild the file from IANA's signed trust-anchor file. With the stale file moved aside, it fetched root-anchors.xml, verified its signature, and wrote both keys:

# stop the resolver, keep the stale file for reference
mv /path/to/root.key /path/to/root.key.stale
unbound-anchor -a /path/to/root.key
grep -c 38696 /path/to/root.key   # expect 1
# start the resolver again, then repeat the sentinel check

Use the path your configuration actually reads, and make sure the file is owned by the user Unbound runs as. For other resolvers, follow your vendor's instructions for updating trust anchors.

If you pin the anchor by hand, add KSK-2024 next to KSK-2017 and take its values from IANA's published file at data.iana.org/root-anchors/root-anchors.xml, not from an article (this one included). In that file, KSK-2024 is the entry with key tag 38696 and validFrom="2024-07-18".

Stop it happening again

The rollover is a one-off. A rebuild that throws away learned state is a pattern, and it will matter again when KSK-2017 is revoked and when the root eventually moves to a new algorithm.

• Keep resolver state outside the image. Put the trust-anchor file on a persistent volume so a container recreate does not reset it.
• Refresh anchors when you build an image. If a base image includes a resolver, update its trust anchors as part of the build, not only when it was first created.
• Re-check after every restore. Add the sentinel query to your post-restore checklist. It costs two dig commands.
• Do not stop at a clean exit code. An anchor tool that says "ok" has told you the file works at the moment it ran. Whether it holds the key that will be in use on 11 October 2026 is a separate question, and you answer it by asking the resolver.

If you do not run your own resolver, none of this is yours to do. Your provider's resolver is their responsibility, and Cloudflare's no-action statement is scoped to Cloudflare: "If you use Cloudflare for your domain's DNS or rely on 1.1.1.1 and Gateway DNS, you do not need to take any action — our systems already trust KSK-2024." If you use another provider's resolver and want to know, ask them or run the sentinel check against their resolver.

Sources, read 9 October 2026: Cloudflare, "The keys to the Internet change on October 11, 2026. Are you ready?", 6 October 2026 (blog.cloudflare.com); IANA, DNSSEC trust anchors and rollover dates (iana.org/dnssec/files) and root-anchors.xml; RFC 5011 and RFC 8509. Unbound results are from our own test with Unbound 1.24.2 on 9 October 2026.