DNS root key change nears with gaps in measured readiness

A DNS root key change scheduled for 11 October 2026 is approaching with uneven readiness in measurements reported by APNIC's Geoff Huston. DNS, the Domain Name System, translates website names into network addresses. Its root key helps systems verify that DNS information is authentic, making this a security maintenance task with consequences for everyday browsing if the transition goes wrong.

In his APNIC article published on 9 October, and written on 8 October, Huston reports that around 70% of tests appearing to support a particular readiness-checking mechanism indicated that the incoming key was trusted. A separate measurement by root server operator Verisign showed around 90% of reporting resolvers had added it. Neither figure is an estimate of how many internet users will lose service. The methods observe different populations and have important limits.

Why the root key needs special handling

DNS Security Extensions (DNSSEC) use digital signatures, mathematical evidence of authenticity, to check DNS answers. A recursive resolver is the service that looks up those answers on a user's behalf. When a validating resolver cannot establish the required trust, a lookup can fail rather than return an answer it cannot authenticate.

Normally, DNS keys sit within a hierarchy. A Zone-Signing Key (ZSK), which signs records within a managed section of DNS called a zone, is authenticated through that zone's Key-Signing Key (KSK). A subordinate zone's KSK is linked to its parent through a signed Delegation Signer (DS) record, containing a hash, a mathematical fingerprint of the public key. This lets trust flow down from one level to another.

The root KSK has no parent. Instead, the existing trusted key signs a set of key records containing its successor. Resolvers must then have enough time to observe and accept the new key as a trust anchor, a locally stored starting point for authentication.

The automatic update procedure is specified in RFC 5011. Its waiting period is at least 30 days, or longer if required by the original time to live (TTL), the validity interval attached to the first relevant set of key records. A resolver must see at least two authenticated DNSKEY resource record sets, the collections of published DNS keys, containing the new key before accepting it. With the required waiting periods respected, the transition is intended to happen automatically.

This rollover changes the key pair, not the cryptographic algorithm. The incoming KSK-2024 was published on the Internet Assigned Numbers Authority (IANA) website in July 2024 and added to the root's DNSKEY records in January 2025. IANA plans to start using it to sign the root DNSKEY record set on 11 October 2026.

Two ways to examine readiness

RFC 8145 describes how resolvers can signal their trusted keys to root servers. A key tag is a short numeric identifier for a key. Resolvers can place these tags in a query name: `_ta-4f66-9728` indicates trust in keys tagged 20326 and 38696. Alternatively, they can include the values in an edns-key-tag option, an additional field carried with a DNS query.

Root server operators can examine these signals in their query logs. Verisign's July 2026 sample showed around 90% of reporting resolvers had added KSK-2024. But a resolver can serve millions of people or just one, as Huston's laptop resolver does. Counting resolvers therefore does not reveal the number of users behind systems that are not ready.

RFC 8509 takes a different approach. Its Root Key Trust Anchor Sentinel mechanism sends a signal back to the person making the query. A supporting resolver recognizes a special prefix in the requested name and adjusts its response according to the keys it trusts.

For `root-key-sentinel-is-ta-`, a trusted key produces the original answer; an untrusted key produces SERVFAIL, a DNS failure response. For `root-key-sentinel-not-ta-`, those outcomes are reversed. Cloudflare's DNS team operates a web page through which users can run these tests on their own DNS setup.

APNIC uses advertising-based measurements to present three test queries to internet users. The first two check support for the mechanism using KSK-2017, tagged 20326. A supporting resolver that trusts that key should return NOERROR, a successful DNS response, for the is-ta test and SERVFAIL for the not-ta test. A resolver without support instead returns an authenticated answer for both. The third query tests whether KSK-2024, tagged 38696, is trusted.

Rather than identify individual resolvers, APNIC seeks to measure users whose DNS requests go exclusively through validating resolvers that have not yet trusted the replacement key. Only samples with the expected initial test responses count as reporting users.

What APNIC's tests found

Huston reports that a small test on 5 October using RIPE Atlas probes, devices used to measure internet connectivity, covered 2,900 distinct Autonomous Systems, separately administered networks. It found 1,230 probes behaving consistently with sentinel support and acceptance of the new key. Another 47 behaved consistently with not having loaded it.

APNIC's larger advertising-based tests ran between May and July 2026 and resumed in early October, averaging around 16 million tests daily. Around 6 million daily tests appeared to be behind DNSSEC-validating resolvers, and about 1.8 million gave a clear sentinel-support signal. Within the samples appearing to support that mechanism, around 70% reported trusting KSK-2024. Those filters matter: the result cannot simply be extended to every resolver or internet user.

The averages also conceal substantial differences between networks. Huston describes a table of the 50 networks with the lowest acceptance rates, restricted to networks with at least 1,000 tests showing sentinel support. The supplied excerpt ends before the full table is visible. Listed acceptance rates include 16.40% for Allo Comms in the United States, 12.70% for Vodafone Libertel in the Netherlands, 8.20% for Vodafone-CZ in Czechia, 6.20% for Superloop in Australia and 2.50% for Reliance Jio in India. These are measured readiness signals, not confirmed outage rates or proof that every customer on those networks is affected.

For businesses and website owners, the practical issue is whether the DNS service they depend on has accepted the replacement trust anchor. Asking the provider or IT team to verify readiness is more useful than treating an aggregate percentage as a prediction for a particular connection.

AEU DNS offers private, encrypted DNS for readers seeking to protect their lookups in transit, but encryption is separate from DNSSEC trust-anchor readiness and does not itself establish readiness for this rollover. The evidence reported here concerns preparation before the scheduled change, not an observed outage after it.