Rolling the Root Key (Update)

Rolling the Root Key (Update)

October 2026

This is an update to an article I posted in May of this year. As I write this, it's now the 8th October, and the Root Key of the DNS is scheduled to roll on the 11th October. The major addition to this update is a list of vulnerable ISP networks which are showing a KSK Sentinel signal that they have not added to their DNS resolver's trusted key set at the end of this article.

Rolling the root key is special, in that every other key in DNSSEC has the notion of a parent key which is used to validate the authenticity of a key. In the case of a Zone-Signing Key (ZSK) it’s the zone's Key-Signing Key (KSK) if the zone uses a split of ZSK and KSK. In the case of a KSK it’s the key used to sign the entries in the parent domain. For these keys which are subordinate to another key, then all that’s required is for the parent key to sign across the new key value (or a hash of the public key component to be precise, published in the parent zone as a signed 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. The specification described in RFC 5011 "Trust Anchor Update" contains some 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." So the new KSK is added to the root zone's DNSKEY RRSet, enabling validating resolvers to 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 continuously observed for the 30-day hold-down time interval. As long as the key roll observes these minimum hold period 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 (termed "KSK-2024" denoting the year when the key pair was initially generated) was published on the IANA web site in July 2024 and added to the root zone's DNSKEY Resource Record in January 2025. The IANA plans to roll the KSK on the 11th of October 2026, when it will be used for generating the root zone's DNSKEY Resource Record digital signature.

How are we going with this KSK roll? Have all DNSSEC-validating recursive resolvers learned of KSK-2024 by now and incorporated this key into their trust anchor set? How can we measure this behaviour?

There are two techniques we can use to peer into the Internet's DNS infrastructure and find out which DNS resolvers have added KSK-2024 to their local trust anchor set.

The first is described in RFC 8145 (https://www.rfc-editor.org/rfc/rfc8145.html) "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 way is to place the tag values of all trusted keys into a query name (i.e. a query name of "_ta-4f66-9728" indicates that the resolver trusts keys with tag values of 20326 and 38696). An alternate method is to embed the trust key tag values into an edns-key-tag 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. Obviously, some DNSSEC-validating recursive resolvers are used heavily, sometimes by millions of users, while others, including the one on my local laptop, is used by just me! When these figures show that some 90% of reporting resolvers have added KSK-2024 to their trust anchor set, that does not readily map to an estimate of the end user population that is served by these recursive resolvers, nor the population of end users who may be affected by an immediate roll of the KSK.

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 a left-most label of a DNS query name and requires the DNS resolver to recognise this label and generate a response based on the resolver's set of trusted keys, as shown in Table 1. The resolver returns the SERVFAIL response code if the assertion related to the trust in the provided key tag does not match the local state.

For example, if the local resolver trusts the KSK with key tag value 20326 (which is the current KSK key tag as of the 8th October 2026), then a query for the name "root-key-sentinel-not-ta-20326.u564ee17a0.ap.dotnxdomain.net" will return SERVFAIL.

You can run these tests on your own DNS infrastructure with a web page operated by the DNS team at Cloudflare: https://dnstest.dev/ksk-2024/.

We use APNIC's ad-based measurement system to pose these queries to a collection of end users every day. What we are after here is not to identify individual validating recursive resolvers, but to quantify the population of end users who are located exclusively behind DNSSEC-validating resolvers where the resolver has so far failed to trust KSK-2024.

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 Trust Anchor 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 Trust Anchor Sentinel mechanism by testing if it trusts KSK-2017 (key-tag 20326). 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 KSK-2024 (key-tag 38696) into its local trust anchor set.

A small-scale run using the RIPE Atlas probes on the 5th October using probes located in 2,900 distinct ASs found 1,230 probes with a resolver behaviour consistent with a root key sentinel that has loaded the new KSK, and 47 probes with a resolver behaviour that has not loaded the new KSK value into its local trusted key collection, a failure rate of 3.7%.

We performed a larger set of measurements using ads, conducted between May and July in 2026, and resumed in early October 2026, with an average test count of some 16M tests per day.

The daily results of this measurement of the adoption of KSK-2024 as a Trust anchor are shown in Figure 2.

This larger test indicates an adoption rate of some 70% of tests appear to support the RFC8509 functionality, and are reporting that KSK-2024 (the incoming KSK) has been loaded as a trusted key. The absolute scale of this measurement is shown in Figure 3.

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

These average numbers are less than helpful, as they hide significant variation, and also mask where issues of lack of acceptance of the new key may be found. What would be more useful is to list those networks where the Key Sentinel tests indicate that the incoming key has not been loaded into the local trusted key set. A table of the 50 networks with the lowest rate of acceptance of KSK-2024 over the past week is shown in Table 4. 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 Key Sentinel mechanism.

If your ISP is listed here, then you may want to follow-up using Cloudflare's test script, and ask your ISP to review their DNS settings, as the KSK roll may present the ISP resolver with some problems after the KSK is rolled.

The above views do not necessarily represent the views of the Asia Pacific Network Information Centre.