The Axiom Changes on October 11: Running a Resolver Through the Root KSK Rollover

Overview

Picture a validating resolver baked into a container image in the spring of 2024. It ships with a root.key file that holds one key: KSK-2017, key tag 20326. The image runs fine for two years. Every few days an orchestrator replaces the container with a fresh copy from the same image, so the resolver starts from that 2024 file every time. On Sunday 11 October 2026 the root zone starts signing its key set with a different key. Nothing breaks on Sunday. The resolver still has a cached root key set that it validated under the old key, and that cache entry has a 48 hour TTL. Sometime on Monday or Tuesday the cache expires, the resolver fetches the new key set, finds no signature from any key it trusts, and every validated lookup behind it starts returning SERVFAIL.

That is the whole failure in one paragraph, and each piece of it is documented. ICANN's guide for this rollover says users will likely start seeing effects "at some point in the 48 hours after the rollover happens" if their resolver's configuration was not updated, and that "it is impossible to predict when affected operators will notice." ICANN also calls out the exact deployment pattern above: containerized services and applications with private stub or DNS over HTTPS configurations "may use resolvers configured at build or deployment time, independently of the host operating system's resolver settings."

You are six days out as this is published. This piece treats the rollover as what it is for an operator: a distributed state migration with a hard cutover, where the state is a file on disk that most teams have never opened.

The Timeline

This is only the second root KSK rollover since the root was signed in 2010. The first took place in October 2018, a year later than planned. ICANN's July 2026 blog explains that it slipped "to allow more time for outreach after data showed that many operators had not yet updated their systems." The same post says the COVID-19 pandemic forced remote only attendance at key ceremonies for a period, and that a move to new hardware security modules required generating a brand new key, which became KSK-2024.

The phase letters come from ICANN's rollover FAQ, which describes an eight phase life cycle over roughly six years, with each key "actively used for signing for about three years." Phase C (October 2024) was the first batch of key signing requests signed with the new key, which is why it sits between replication and publication.

What the Root Key Set Looks Like Today

The root zone has two kinds of keys. Per ICANN's guide, zone signing keys "sign the main data in the root zone," key signing keys "sign just the root key set," and a new ZSK is published every three months. The KSK is the only key whose signature a validator checks against its configured anchor. Everything else chains from there.

A DNS over HTTPS query for . DNSKEY with the DO bit set, made on 29 September 2026 while writing this, returned four DNSKEY records and one RRSIG. Two records carry flags 256 (ZSKs). Two carry flags 257, the SEP bit that marks a KSK: one begins AwEAAaz/tAm8, the other AwEAAa96jeuk. The RRSIG covering the set names signer key tag 20326, algorithm 8, original TTL 172800 seconds (48 hours), with an inception of 19 September and an expiration of 10 October 2026. After the roll, that signer field changes to 38696. That field is the whole event.

You can check the anchor file against the live key set yourself, and it is worth doing once so the numbers stop being magic. A key tag is a 16 bit checksum over the DNSKEY RDATA: flags, protocol, algorithm, public key. The DS digest in root-anchors.xml is SHA-256 over the owner name (the root, a single zero byte) followed by that RDATA. Recomputing both from the PublicKey elements in today's root-anchors.xml gives 20326 with digest prefix E06D44B80B8F1D39 and 38696 with digest prefix 683D2D0ACB8C9B71, exactly the values IANA publishes. Both are 2048 bit RSA keys, matching the guide's statement that KSK-2017 and KSK-2024 use "the same cryptographic algorithm (RSA/SHA-256) and key size (2048 bits)."

RFC 5011 as a State Machine

RFC 5011 is how most resolvers were supposed to pick up KSK-2024 without anyone touching them. It solves a narrow problem: how can a resolver accept a new trust anchor from the DNS itself without letting an attacker who stole one key add their own? The answer is time. A resolver that sees a new SEP key in a validated DNSKEY set starts an acceptance timer. If the key ever disappears from a validly signed set, the timer resets. The key becomes an anchor only after the add hold down expires "AND it has retrieved and validated a DNSKEY RRSet after the hold-down time that contains the new key."

Read the hold down rule again with a container in mind. The timer only means something if the resolver remembers it. A resolver that restarts from an immutable image, with its managed key state inside the container filesystem, restarts the clock at every deploy. If your deploy cadence is shorter than 30 days, the resolver has been in AddPend for KSK-2024 since early 2025 and never reached Valid. It still validates today because KSK-2017 signs the key set. On 11 October it stops.

There is a second trap after the roll. RFC 5011 only learns a new key from a DNSKEY set signed by a key the resolver already trusts. Once KSK-2017 no longer signs the root key set, a resolver that only knows KSK-2017 has no path to learn KSK-2024 from the DNS. Automatic update cannot rescue it. The anchor has to arrive out of band: a package update, a config change, or a fetch of root-anchors.xml.

Where Anchors Live

ICANN's blog names the files to check: bind.keys for ISC BIND, root.key for Unbound and PowerDNS Recursor, and root.keys for Knot Resolver. That list is where to start looking, not the full answer. Each implementation has a built-in anchor, a managed state file, and a configuration mode that decides which one wins.

Verifying Without Trusting the Updater

If RFC 5011 is the mechanism under test, you cannot use RFC 5011 to confirm it worked. You need an independent reference. IANA publishes one at https://data.iana.org/root-anchors/root-anchors.xml. The format was defined in RFC 7958 (August 2016), which RFC 9718 obsoleted in January 2025. Unbound's man page still cites RFC 7958. The XML is compatible, but the trust model around it changed, so read 9718.

File checks tell you what is on disk. Two protocol mechanisms tell you what the running resolver believes, and they are how researchers produce the adoption numbers you read in press releases.

What Failure Looks Like

ICANN's guide is specific about sequence and symptoms, and it is worth reading before you write alerts, because the failure is delayed, partial, and uneven across users.

An October 11 Runbook

The runbook splits into three windows. The goal of the first is to make the second boring.

Cost Reality Check

There is no invoice attached to a KSK rollover. The costs are engineering hours before the roll and incident hours after it, and ICANN's FAQ frames them that way.

Key Takeaways

In this catalog