DNS root key rolls over on 11 October 2026 as APNIC measures resolver readiness

The rollover

On 11 October 2026, the Internet Assigned Numbers Authority (IANA) will switch the DNS root zone to a new key-signing key (KSK), the trust anchor at the very top of the DNSSEC validation chain. According to the APNIC Blog, the replacement key, KSK-2024, was published on the IANA website in July 2024 and added to the root zone's DNSKEY record set in January 2025, giving resolvers well over a year to pick it up. The change swaps the public/private key pair but keeps the same algorithm.

A key with no parent

Every other key in DNSSEC is vouched for by the zone above it. A zone-signing key is authenticated by its zone's KSK, and a KSK is authenticated when the parent zone signs a hash of it into a delegation signer (DS) record. The root key has no parent, so the outgoing root KSK instead signs over its own replacement, and resolvers are given a long observation window to accept the new key before the old one stops being used.

RFC 5011 defines the automated procedure. Once a resolver sees the new key in the root zone's DNSKEY set, it must wait through an add hold-down period of at least 30 days, and must see the key appear in at least two separately validated DNSKEY responses, before adding it to its local trust anchors. Resolvers that implement the RFC need no manual intervention; the whole rollover should pass unnoticed.

Measuring who is ready

APNIC describes two ways to check whether resolvers have actually adopted KSK-2024.

The first, standardised in RFC 8145, has resolvers stamp the key tags of the keys they trust onto queries sent to the root servers, for example a query name of _ta-4f66-9728, which signals trust in keys with tags 20326 and 38696. According to figures from the root server operator Verisign cited in the post, around 90% of reporting resolvers have already added KSK-2024 to their trust anchor sets. APNIC cautions that this counts resolvers rather than people: some validating resolvers serve millions of users, while others, including the one on the author's laptop, serve exactly one.

The second, RFC 8509's root key trust anchor sentinel, turns the resolver itself into the sensor. A query name that begins with root-key-sentinel-is-ta- followed by a key tag gets a normal answer if the resolver trusts that key and SERVFAIL if it does not. Cloudflare operates a web page where operators can run the test against their own infrastructure, and APNIC embedded these queries into its advertising-based measurement platform, which averages roughly 16 million tests per day. Of those, about 6 million land behind DNSSEC-validating resolvers and around 1.8 million produce a clear sentinel signal. Within that sentinel-capable group, about 70% report KSK-2024 (key tag 38696) as trusted, leaving a meaningful minority that still relies solely on the outgoing KSK-2017 (key tag 20326).

A smaller RIPE Atlas run on 5 October 2026, spanning 2,900 distinct autonomous systems, found 1,230 probes behind resolvers that had loaded the new key and 47 behind resolvers that had not. APNIC notes the headline averages conceal wide variation between networks, and lists the 50 networks with the lowest KSK-2024 acceptance among those with at least 1,000 usable tests.

Why it matters

Every DNSSEC validation chain ends at the root key, which is why its replacement is staged over years rather than days. The multi-year RFC 5011 schedule exists so that no validating resolver is left trusting a key that no longer signs the root zone. APNIC's measurements are the safety check on that assumption: they size the population of users sitting behind resolvers that have not yet learned KSK-2024, and it is exactly those resolvers for which the rollover risks breaking validation, because a resolver that cannot authenticate the root zone's new signature has no parent key to fall back on. The resolver-level picture looks broadly healthy, but the outlier networks in APNIC's table are where operators should be looking before 11 October.