Rolling the root key

As I write this on 8 October, the root key of the Domain Name System (DNS) is scheduled to roll on 11 October 2026.

Rolling the root key is 'special' because every other key in DNS Security Extensions (DNSSEC) has the notion of a parent key that is used to validate its authenticity. In the case of a Zone-Signing Key (ZSK), it's the zone's Key-Signing Key (KSK). In the case of a KSK, it's the key used to sign the entries in the parent domain. For keys that are subordinate to another key, all that's required is for the parent key to sign across the new key value (or, more precisely, a hash of the public key component, published in the parent zone as a signed Delegation Signer (DS) resource record).

The root key is different, as it has no parent. The way a new key is authenticated by a DNS resolver is by having the old KSK sign across the new KSK ('old signs new'). Then an extended period is required to allow DNSSEC-validating clients sufficient time to pick up and trust the incoming key. RFC 5011 - "Trust Anchor Update" provides guidance for this process.

It states:

"The add hold-down time is 30 days or the expiration time of the original TTL of the first trust point DNSKEY RRSet that contained the new key, whichever is greater. This ensures that at least two validated DNSKEY RRSets that contain the new key MUST be seen by the resolver prior to the key's acceptance."

The new KSK is added to the root zone's Resource Record Set (RRSet), so validating resolvers learn of this new key automatically when they retrieve this resource record. They are supposed to add the key value into their local cache of trusted keys when the new key has been observed for the 30-day hold-down time interval. So if the key roll observes these minimum hold periods for each stage of the key roll, then the entire process should be automatic.

The 2026 key roll is not a change of algorithm, but simply a change of the private/public key pair. The incoming KSK () was published on the Internet Assigned Numbers Authority (IANA) website in July 2024, and added to the root zone's resource record in January 2025. IANA plans to roll the KSK on 11 October 2026, when it will be used to generate the root zone's resource record digital signature.

How are we going with this KSK roll? Have all DNSSEC-validating recursive resolvers learned of by now and incorporated this key into their Trust Anchor (TA) sets? How can we measure this behaviour?

Trust signal - RFC 8145 measurement

There are two techniques we can use to peer into the Internet's DNS infrastructure and find which DNS resolvers have added to their local TA set.

The first is described in RFC 8145 - "Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)". In this technique, the resolver embeds the key tags of its trusted keys in queries that are sent towards the authoritative servers for the root zone. One method places the tag values of all trusted keys in a query name. For example, a query name of '' indicates that the resolver trusts keys with tag values 20326 and 38696. An alternative method is to embed the trust key tag values into an option in queries.

This information is visible in the log of queries managed by the operators of root servers. An analysis of this RFC 8145 signal received by a root server operator (Verisign) is shown in Figure 1.

What the data in Figure 1 does not show is the population of users who are using these recursive resolvers. Some DNSSEC-validating recursive resolvers serve millions of users, while others, including the one on my laptop, serve just one. These figures show that around 90% of reporting resolvers have added to their TA set. This does not translate directly into an estimate of the end-user population they serve, or the number of users who may be affected by the KSK roll.

RFC 8509 - "A Root Key Trust Anchor Sentinel for DNSSEC" proposes a different approach, where the signal of a recursive resolver's trusted keys is folded back and sent to the querier, rather than onward towards a root zone server. The approach involves the leftmost label of a DNS query name and requires the DNS resolver to recognize this label and generate a response based on the resolver's set of trusted keys, as shown in Table 1.

You can run these tests on your own DNS infrastructure with a web page operated by the DNS team at Cloudflare.

We use APNIC's advertisement (ad)-based measurement system to pose these queries to a collection of end users every day. We do not identify individual validating recursive resolvers, but rather quantify the population of end users who are located exclusively behind DNSSEC-validating resolvers where the resolver has so far failed to trust .

The test we are using has three queries, as shown in Table 2. A resolver that is configured to perform DNSSEC validation and supports this Root Key TA Sentinel mechanism will provide DNS responses, also shown in Table 2.

The first two tests are intended to determine if the resolver supports this Root Key TA Sentinel mechanism by testing if it trusts (). If it does not, it will return a validated response in both cases. If it does report responses as per Table 2, then we can classify the sample point as a 'reporting user'. The third query is intended to determine if the resolver has loaded () into its local TA set.

Results

A small-scale test using RIPE Atlas probes on 5 October, covering 2,900 distinct Autonomous Systems (ASes), found 1,230 probes with a resolver behaviour consistent with a Root Key TA Sentinel that has loaded the new KSK. 47 probes showed resolver behaviour consistent with not having loaded the new KSK value into local trusted key collections.

We conducted a larger set of ad-based measurements between May and July 2026, and resumed them in early October 2026, averaging around 16 million tests per day.

The daily results of this measurement of the adoption of as a TA are shown in Figure 2.

This larger sample indicates that around 70% of tests that appear to support RFC 8509 report that has been loaded as a trusted key.

While the measurement platform undertakes 16M tests per day, only around 6M tests per day show that the tested end system lies behind DNSSEC-validating recursive resolvers. Around 1.8M tests per day provide a clear signal that they support the RFC 8509 Key Sentinel mechanism.

These average numbers are less than helpful, as they hide a significant variation. What would be more useful is to list those networks where the RFC 8509 Root Key TA Sentinel tests indicate that the incoming key has not been loaded into the local trusted key set.

Table 3 shows the 50 networks with the lowest rate of acceptance of KSK-2024. I've filtered this list so that it only shows those networks where we observed 1,000 or more tests that showed that their DNS resolvers supported the Root Key TA Sentinel mechanism.

The KSK roll may present the listed ISP resolvers with some problems. If your ISP is listed in Table 3, then you may want to follow up using Cloudflare's test script and ask your ISP to review their DNS settings.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.