APNIC Pty Ltd.

10/21/2026 | Press release | Distributed by Public on 10/20/2026 20:05

Rolling the root key: What happened

This is an update to articles I posted in May and October 2026 ahead of the DNS root KSK rollover on 11 October. We will again use the Key Signing Key (KSK) Sentinel signal to see which networks have successfully tracked the rolling of the root key. The previous articles describe the KSK Sentinel signal, so I won't reproduce that material here.

Let's start with the big picture and look at the data collected by our advertisement-based measurement network for the first 16 days in October (Figure 1).

The shaded area in Figure 1 indicates the period from the start of the KSK roll (14:00 UTC, 11 October 2026) and the following 48-hour period that covers the cached lifetime of the root zone records in validating resolvers (two days).

The blue trace shows the number of measurements performed each day. Daily measurement ad presentation rates remained within normal levels of variation.

The red trace shows the percentage of measurements which indicate that the measured user is using only DNSSEC-validating resolvers. Prior to 11 October, this required that the outgoing KSK was trusted by the resolver. Once the locally cached resource record was refreshed - sometime before 14:00 UTC on 13 October - a validating resolver would need to trust the incoming KSK to successfully perform a validation operation.

This data indicates that the global average DNSSEC validation rate rose from a pre-roll value of 39.7% to a post-roll value of 40.6%. In global terms, this indicates that the KSK was rolled successfully and there was no major DNS outage. This is very positive feedback on the work of many parties who have invented, standardized, implemented, and deployed DNSSEC validation software in resolvers that tracked this roll of the KSK.

However, averages can often conceal individual behaviours that deviate from the norm. Let's take a closer look at two economies that have a significant population of DNSSEC-validating users, and see how they fared at an economy-wide level over the KSK roll. These economies are Brazil and India (Figure 2), which generally benefit from the use of ISP-provisioned recursive resolvers that perform DNSSEC validation.

Fortunately, we were able to contact a major Indian ISP on 9 October and alert them to the KSK Sentinel signal that indicated that their resolvers had failed to pick up local trust in the incoming KSK, and would likely fail in validation when the KSK rolled. This ISP was able to react in time, increasing the DNSSEC validation rate among measured Indian users from 55% to 59% across the KSK roll. We were not so fortunate in attempting to contact ISPs in Brazil in the same period that showed the same signal, and the DNSSEC validation rate fell from 54% to 50% after the KSK had rolled.

My article at the start of this month included a table of the 50 networks with the lowest rate of acceptance of over the previous week, where we had observed 1,000 or more tests that showed that their DNS resolvers supported the Key Sentinel mechanism.

We've tracked those 50 networks from the previous article and looked at their acceptance rate for the incoming KSK up to 18 October, as indicated by the Key Sentinel measurements (Figure 3).

Surprisingly, none of these networks was stranded when the KSK rolled. All of the networks added the new KSK to their trusted key set in the period between 7 and 13 October.

I must admit that I was not expecting this. It's unusual to observe that all of these networks that appeared to generate a Key Sentinel signal and had an acceptance rate of the incoming KSK below 50% later recorded an acceptance rate above 50% after the KSK roll. Such a uniform behaviour pattern is somewhat anomalous in the DNS!

Let's now look at DNSSEC validation outcomes across the KSK roll. What we are looking for in the data are those networks whose DNSSEC validation rate fell after 13 October as compared to the average rate observed in the first 10 days of October 2026. Figure 4 shows the distribution of DNSSEC validation change per network over the KSK roll.

The dataset includes 13,538 networks where we captured an average of 20 samples per day both before and after the KSK roll.

There were 35 networks with a positive change in validation of more than 50% between the before and after periods. A likely explanation is that these network resolvers had DNSSEC configurations that trusted the incoming KSK, but did not trust the incumbent KSK. Widening the selection criteria, there were 594 networks that had a positive increase of 10% or more in DNSSEC validation rates.

On the other side, there were 58 networks where the DNSSEC validation rate fell by 50% or more, and 660 networks where the DNSSEC validation rate fell by 10% or more.

We can estimate the user impact of this KSK roll by using estimates of the population of users.

The estimated total user population who are behind DNSSEC-validating DNS resolvers is 1,700,275,794, from a total of 4,308,517,174 users. Prior to the KSK roll, this user population of DNSSEC-validating users was 1,654,477,399. Across the KSK roll, we observed a net increase of 45.8 million DNSSEC-validating users.

Tables 1 and 2 show the economy-wide user populations and the total estimate of DNSSEC-validating users before and after the KSK roll.

Was the KSK roll a success?

The DNS is a highly distributed but loosely coupled system. Precise coordination of actions in the DNS is not feasible, so any effort to create a uniform outcome will encounter variation. Judgements of success (and failure) need to be tolerant of such variation. In that light, the measurements we've undertaken support the conclusion that the KSK roll of October 2026 was a success.

The data used for this report can be found in a CSV-format file with an explanation of the columns. Long-term measurement data on DNSSEC validation can be found at APNIC Labs.


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.

APNIC Pty Ltd. published this content on October 21, 2026, and is solely responsible for the information contained herein. Distributed via Public Technologies (PUBT), unedited and unaltered, on October 21, 2026 at 02:05 UTC. If you believe the information included in the content is inaccurate or outdated and requires editing or removal, please contact us at [email protected]