Summary

  • KSK-2024 began signing the DNS root zone on schedule on 11 October 2026; ICANN reported no indications of widespread operational disruption.
  • That public status confirms a root-zone event, not universal resolver adoption or the absence of every local failure. KSK-2017 remains a valid trust anchor until later scheduled revocation and removal steps.

A successful switch has more than one meaning

ICANN’s rollover page records a precise event: at 14:00 UTC on 11 October, KSK-2024 began signing the root zone. Its accompanying status says no indications of widespread operational disruption had been observed and that monitoring would continue. IANA likewise records the new key as active and KSK-2017 as no longer signing. These are meaningful operational facts, but the scope of each statement matters.

A root-zone signing change is not the same event as every validating resolver accepting the successor key. The root zone publishes signed DNS data; recursive resolvers validate that data on behalf of clients. A validating resolver needs a local trust anchor from which it can verify the chain. If it lacks a usable KSK-2024 trust anchor once it needs to validate the new signing state, DNSSEC validation can fail at that resolver. The failure can affect the customers using that resolver without showing that the global root zone or all DNS is down.

The cutover therefore has at least four evidence layers: the key and its signing status at the root; the trusted-key state on each resolver; the behavior of software and update mechanisms that move keys into that state; and observed resolution outcomes for users. A report at one layer cannot stand in for receipts from the others.

The long runway was designed for independent resolvers

IANA published KSK-2024 well before it became active. The key appeared in the root zone on 11 January 2025, with an expected RFC 5011 trust date of 10 February 2025. The two-year runway gave compatible resolvers time to discover and accept the new key while the existing key still signed the zone. ICANN’s July guide said that more than 95% of reporting resolvers had recognized or adopted KSK-2024 before the switch. That is evidence of broad reported readiness, not a census of all resolvers or a post-cutover outcome rate.

RFC 5011 explains why “published” and “trusted” are separate states. An automated resolver observes a new key in a validated DNSKEY set, waits through an add hold-down period, and validates a later set that still contains the key before accepting it as a trust anchor. The default hold-down is at least 30 days, subject to the original TTL rule. Each resolver makes this decision from what it sees and stores. A central schedule can create the opportunity for adoption; it cannot certify local disk state, software configuration, or successful validation across a distributed fleet.

The 2018 rollover makes that boundary concrete. ICANN’s review says the first scheduled change was postponed after late data indicated that a significant number of ISP and network-operator resolvers were not ready. After the 2018 switch, DNSKEY query patterns suggested that some resolvers remained unprepared, although the review found no significant outages and only a small amount of disruption visible to users. The review also says the root-zone operator could not measure or control every resolver because operators manage their own systems.

That history explains why the 2026 status is phrased as an observation about widespread disruption rather than a claim of universal success.

October is a cutover, not the end of the lifecycle

The key sequence also remains open. IANA’s current schedule says KSK-2017 ceased signing on 11 October 2026, but it remains a valid trust anchor. IANA schedules publication of its REVOKE bit for 11 January 2027 and removal from the root zone for 22 March 2027. Those are later state transitions with their own resolver behavior and evidence. The October signing change should not be described as the old key’s immediate deletion or as the completed retirement of all trust in it.

The distinction is practical. Some systems update automatically; others use vendor packages, manually maintained trust-anchor files, appliance firmware, or managed resolver services. The same organization can use several paths. A package being available does not prove it was installed; a configured key does not prove an update process will persist; and a successful query from one test point does not prove every client path validates the same way. Those are operational states that need separate checks.

ICANN’s reminder asks validating-resolver operators to verify that KSK-2024, key tag 38696, is present and warns against assuming automatic updates succeeded. IANA says the signed XML trust-anchor publication is the normative source for key parameters and points operators to vendor instructions. This gives operators a concrete local verification target while leaving the wider fleet evidence decentralized.

What the public record can and cannot say

The public record supports three conclusions: the new key took over root-zone signing on the planned date; ICANN had observed no indications of widespread operational disruption at the time of its status update; and the old key’s revocation and removal remain future milestones. It does not provide a resolver-by-resolver inventory, a post-cutover denominator, a measured global adoption percentage, or a count of affected users. Nor does the absence of a published incident prove that no resolver or customer encountered trouble.

That is not a reason to discount the status update. It is a reason to describe the claim at the right scale. The root-zone operator can report the signing state and monitoring signals it sees. Resolver operators can report their local trust state and validation behavior. Vendors can document how packages and automatic updates propagate. Service providers can observe their own customer impact. Each has a different vantage point; none alone can speak for all of them.

The useful question after a scheduled rollover is not simply whether the ceremony or calendar succeeded. It is whether the evidence chain reaches the systems that rely on the key—and whether the remaining retirement steps preserve a clear path to recovery. For the 2026 rollover, the public answer is encouraging but deliberately limited: the root changed on time, and no widespread disruption had been observed. The rest must be established at resolver and service level, with the January and March 2027 milestones still ahead.