The ICANN organization is in the process of changing, or rolling, the root zone’s key-signing key (KSK), which is configured as a trust anchor in many DNSSEC validators. The current KSK has been in use since the root was signed in 2010 and is referred to as KSK-2010. The new key, called KSK-2017, has been published in the root zone’s DNSKEY RRset since 11 July 2017. The KSK roll is currently scheduled for 11 October 2018, though the date is tentative pending further review by the ICANN community. Further details 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.
For more information, subscribe to the root KSK rollover mailing list.
The ICANN org is publishing 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 validating using only KSK-2010 as a trust anchor. 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. Without further action, these resolvers will stop working after the root KSK is rolled on 11 October 2018.
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.
The ICANN org has been collecting RFC 8145 telemetry data from almost all the root server operators. Over one million individual IP addresses have reported using only KSK-2010 as a trust anchor, but analysis of that data over time indicates that many of these addresses report only once.
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. We is also aware of widely deployed software configured with just the KSK-2010 trust anchor that will be updated in the near future; see below for more information.
The ICANN org would like to make the addresses published the most useful to the community. Given the large number of addresses already seen, it is incumbent upon us to winnow down the address list to those that are likely to be currently hosting validating resolvers that are using only KSK-2010 as a trust anchor, and to further help members of the community prioritize the list to those that are most likely validating resolvers that are in active use.
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 three 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 metadata about the address that will help members of the community prioritize which addresses to focus on first. The metadata includes:
For example, a row in the file containing the list of addresses might look like:
This indicates that 192.0.2.222 in ASN 555555 sent out an indicator that it was trusting only KSK-2010 on 21 out of 28 days, that it also sent an indicator in the past three days that it trusted both KSK-2010 and KSK-2017, and that was in the Spamhaus PBL.
The list of addresses will be updated daily. This publication strategy may be updated in the future as the community starts to use the addresses to reach out to DNS operators.
Research by Wes Hardaker at ISI has recently shown that a large portion of the addresses appearing in the RFC 8145 telemetry data as only having KSK-2010 as a trust anchor correspond to resolvers embedded in VPN software running on smartphones and personal desktop systems. Details of this research is expected to be published in the near future. In the meantime, the developer of the identified software has been alerted to the problem and is extremely likely to update their software to include KSK-2017 soon; it is also expected that their users are likely to update their software before 11 October 2018.
This discovery brings up a few things that are relevant for the number of addresses seen reporting just KSK-2010 in the RFC 8145 telemetry:
The percentage of validating resolvers reporting RFC 8145 telemetry is small enough that no one has a clear idea of what percent of all resolvers are relying on KSK-2010 as their only trust anchor.
There is no way to know how many users that are represented by a particular address. As described above, there are a large number of validating resolvers that represent just a single user.
Even if a resolver is reporting KSK-2010 as its only trust anchor, it may in fact already have KSK-2017 correctly installed. Many resolvers act as forwarders for other resolvers.
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.
The operator of h.root-servers.net is not contributing RFC 8145 data.