Security / DNS infrastructure / trust-anchor operations · 2026-10-13

DNSSEC root KSK rollover: trust anchors are operational state

The DNS root key-signing key (KSK) rollover scheduled for October 11, 2026, is a useful lesson in how cryptographic trust actually works in production. DNSSEC does not merely ask whether a DNS answer has a signature. A validating resolver must begin with a root trust anchor, validate the root DNSKEY set, and follow a chain of signatures downward. If its local anchor state is stale, otherwise healthy domains can fail validation globally.

Two keys, two different jobs

The root zone publishes a DNSKEY set containing a key-signing key (KSK) and a zone-signing key (ZSK). The KSK signs the DNSKEY set; the ZSK signs the root's other records, including delegation data. A resolver's preconfigured root trust anchor authenticates the DNSKEY set, which then supplies the ZSK used to validate the rest of the chain.

local root trust anchor
       │ validates
       ▼
root DNSKEY set ── KSK signs this set
       │ supplies ZSK
       ▼
root records → TLD DS → child DNSKEY → answer

The root has no parent to publish a DS record for it. Its trust anchor is therefore a special starting point. When the root KSK changes, validators need to trust the replacement before it becomes the active signer.

Why publishing a new key is not enough

With RFC 5011 automated rollover, a resolver sees a new key in signed DNSKEY data and tracks it over time. It must observe the key continuously for at least 30 days before accepting it as a trust anchor. That protects against a brief malicious or accidental key insertion. But learned state can be lost when resolver software is upgraded, machines are replaced, state directories are omitted from backups, or a deployment starts from a stale image. A key can have been published for years and still be absent from one resolver's effective trust state.

For the 2026 rollover, KSK-2024 has key tag 38696, replacing KSK-2017 (tag 20326). The critical operational question is not just “does the upstream publish the key?” but “does the resolver that handles these clients currently trust it?”

Reproducible readiness check

RFC 8509 defines a DNS root-key trust-anchor sentinel. A supporting validating resolver answers specially named, correctly signed records differently depending on whether it trusts the queried key. Run these checks against a known resolver with dig:

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 +answer

For a validating resolver that supports the sentinel, “is trusted” should return a valid response, while “not trusted” should return SERVFAIL. Test an ordinary signed hostname and a deliberately bogus DNSSEC name too: otherwise a timeout, non-validating resolver, or unsupported sentinel can masquerade as a key-status result. An inconclusive result is not evidence that the new anchor is missing.

Lab: distinguish trust failure from ordinary resolution failure

Compare the resolver explicitly, rather than relying on the browser's configured DNS-over-HTTPS path:

# Ask the resolver you intend to test
 dig @RESOLVER root-key-sentinel-is-ta-38696.dnstest.dev. A +dnssec
 dig @RESOLVER root-key-sentinel-not-ta-38696.dnstest.dev. A +dnssec

# Compare with a known public resolver
 dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +dnssec

Replace RESOLVER with the recursive resolver's IP. Record resolver version, software package, trust-anchor file or managed state, and whether it supports RFC 8509. Do not blindly copy a key from an unverified source: obtain vendor or IANA instructions, validate the key material, update through the resolver's supported mechanism, and confirm the running process loaded it.

Operational checklist

Inventory every validating resolver, including branch, container, appliance, and disaster-recovery instances.
Check effective runtime trust anchors, not merely a config file in version control.
Verify state survives upgrades, failover, restore, and replacement from a clean image.
Test RFC 8509 sentinel responses and ordinary valid/invalid DNSSEC controls.
Monitor DNSSEC validation failures such as SERVFAIL separately from authoritative outages.
Keep a documented, vendor-supported recovery path if automatic rollover state was lost.

Takeaway

Cryptographic trust is not only a property of a key; it is also a property of each verifier's stored state, update process, and boot path. Treat trust anchors like critical production data: version the source, preserve runtime state, test the actual verifier, and distinguish “unsupported test” from “key not trusted.”