The ICANN organization changed, or rolled, the root zone’s key-signing key (KSK) on 11 October 2018. The root zone KSK is configured as a trust anchor in many DNSSEC validators. The previous KSK had been in use since the root zone was signed in 2010 and is referred to as KSK-2010. The current root zone KSK is called KSK-2017. Further details about the root KSK rollover project are available at the root KSK rollover project page on ICANN’s web site.
The protocol defined in RFC 8145 allows a DNSSEC validator to report which trust anchors it has configured. The validator encodes the list of configured trust anchors as a domain name and sends a query for that name to one of the authoritative servers of the zone the trust anchor is for. If a validator supports RFC 8145 and the feature is enabled, it sends periodic reports of its trust anchor configuration to one of the root servers. Most of the root operators are recording these trust anchor report queries and sending that information to ICANN's Office of the CTO (OCTO) for further study. Graphs of this data are shown below.
Prior to the rollover, many resolvers were reporting using only KSK-2010 as a trust anchor. The data collected by the ICANN org and published on this page was part of a larger effort to identify resolvers that were not prepared for the root KSK rollover so their configuration could be updated. Since the rollover has now occurred and KSK-2010 is no longer used, this page and the data are largely of historical interest only. However, because there are still thousands of validators ostensibly indicating being configured with only KSK-2010, the ICANN org continues to maintain this page for any interested parties wishing to investigate further.
We encourage anyone interested in DNSSEC in the root zone to subscribe to the root KSK rollover mailing list, which continues to be used for planning and discussion of future root KSK rollovers.
The ICANN org continues to publish the IP addresses that are sending RFC 8145 telemetry ostensibly indicating that a resolver at the reported address (or another resolver that is forwarding through the resolver at the address) is attempting to perform DNSSEC validation using only KSK-2010 as a trust anchor. Since KSK-2010 is no longer used, any resolvers relying solely on KSK-2010 cannot validate any DNSSEC-signed data. However, publishing these addresses allows ISPs and other organizations who know who operates resolvers at those addresses to contact the resolver operator and notify them of the need to update their DNSSEC trust anchors.
The IP addresses reporting only KSK-2010 are available as a tab-delimited file here:
See below for more information about the data in that file.
Search the list for addresses on your network (or networks you are familiar with).
Contact customers associated with addresses in the list.
Ask the customer to check if the there is a resolver running at the address and, if so, check the resolver's list of trust anchors. The ICANN org has published a document describing how to check the current trust anchors in popular resolvers.
Ask the customer to update the resolver's configuration, if necessary. The ICANN org has published a document describing how to update popular resolvers with the latest trust anchor.
Collect results of your efforts and report them to ICANN. ICANN's OCTO is very interested in hearing how much success you have with the preceding steps, even if it is just reaching a few resolver operators. Please email a summary of your results to email@example.com.
The ICANN org continues to collect RFC 8145 telemetry data from almost all the root server operators. A validating resolver that is following the RFC 8145 specification should report every 48 hours. Some of the addresses seen are known to be temporary addresses assigned by ISPs, and are thus are likely to be for resolvers that have just one user behind them, or might even be for resolvers on a system where there are no users.
The ICANN org is publishing a list of addresses that have reported only KSK-2010 as a trust anchor. The list includes any address that has reported at least once in the past seven days (as of the particular day the list is published). Using these criteria to publish a subset of addresses should avoid reporting false positives, i.e., systems that have updated to also using KSK-2017 as a trust anchor.
Each address in the published list includes the address’s Autonomous System Number (ASN), as reported by Team Cymru. This can be used to help ISPs determine which addresses where they are most likely to know any DNS operators. (See here for a description of this service.)
For example, a row in the file containing the list of addresses might look like:
This indicates that 126.96.36.199 and 188.8.131.52 in ASN 577 sent out an indicator that it was trusting only KSK-2010 on at least one of the past seven days, as did 184.108.40.206 in ASN 680. Note that many ASNs have multiple addresses reporting KSK-2010 only. Also note that any lines with ASN 999999 are for IP addresses for which Team Cymru doesn't have data.
The list of addresses is updated daily.
The ICANN org has generated the graphs below from the RFC 8145 data.
The operator of g.root-servers.net is not contributing RFC 8145 data.