Skip to main content

Minimal User Impact Expected From Root Zone Key Signing Key (KSK) Rollover

The ICANN organization believes that an update of the Domain Name System Security Extensions (DNSSEC) trust anchor for the global Domain Name System (DNS) on 11 October 2018 will affect only a very small number of DNS users. The decision to roll the root zone Key Signing Key (KSK) is being made after a significant outreach effort and careful consideration of all available data.

Since the DNS root zone was originally signed in 2010, the DNSSEC Practice and Policy Statement1 has set the expectation that the root zone KSK will change. Fortunately, most validating resolvers that observe a new root zone KSK should be able to configure it as a new trust anchor automatically using "Automated Updates of DNS Security (DNSSEC) Trust Anchors," defined in RFC50112. A resolver operator can also update their trust anchor configuration manually if they have become aware that the root KSK is changing based on ICANN's various outreach efforts.

There is no standardized or deterministic way to actively measure that a validating resolver has the correct set of trust anchors configured. The best method currently available is "Signaling Trust Anchor Knowledge in DNS Security Extensions" (documented in RFC 81453) that was published in April 2017. In that protocol, validators emit a DNS query that contains the DNSKEY key IDs of configured trust anchors in the query name. These queries can be passively observed in traffic at the root servers. In September 2017, there were a handful of resolvers using this protocol and the announcements of trust anchors showed a higher percentage of misconfigured trust anchors than initially anticipated. However, the signal observed at the time was not well understood and, as a result, the ICANN org decided to postpone the root zone KSK roll to better understand the signal with the help of the technical community.

Further research by the ICANN org's Office of the CTO (OCTO) team and others revealed concerns with the quality of the RFC 8145 data. For example, a DNS query reporting trust anchor information that is sent to a forwarder is treated the same as any other query and will be sent to a root server regardless if the forwarder is validating or not. In one case, a popular DNS resolver implementation signaled the trust anchor even though the resolver was not configured to validate and thus would not have the new trust anchor. This implementation decision was reversed in a subsequent release of the software. In another case, a well-known DNS resolver library signaled the trust anchor but did not have a method to automatically update its trust anchor configuration. As a result, a single deployment of a popular single-user VPN implementation using that DNS resolver library would emit the old trust anchor signal from different source addresses over time. Wes Hardaker at the University of Southern California Information Sciences Institute discovered this behavior and the vendor using the library was informed and updated their software. This change has significantly reduced the number of sources reporting the old trust anchor.4

However, the RFC 8145 data reports only resolvers; it does not provide an indication of the number of end users dependent upon those resolvers. To understand the size of the population of users behind validating resolvers, the Regional Internet Registry for the Asia Pacific region (APNIC) used a measurement system that utilizes Google's advertising network to query the DNS. Analyzing the intersection of ICANN's trust anchor signaling sources with their own resolver sources and then extrapolating, APNIC calculated that only 0.05 percent of Internet users would be negatively affected by the root KSK roll.5

Looking forward, the ICANN org will soon reach out to the 1,000 Internet Service Providers (ISPs) with the most active resolver traffic that suggests DNSSEC validation has been enabled in order to ensure they aware that the root KSK roll will occur on 11 October 2018. Those ISPs will also be surveyed on their preparation plans for the rollover, which may cause those resolver operators to become more aware of the KSK rollover.

Since the first announcement of the development of plans to roll the trust anchor in 2015, the ICANN org has maintained an outreach campaign that has (to date) included nearly 100 speaking engagements at international, regional, and national conferences, and more than 150 news stories in the technical press. The ICANN org has also published nine blog articles related to the trust anchor rollover and continues to reach out to the ISPs that have validating resolvers in their networks but which, from RFC 8145 data, do not appear to have the new trust anchor configured.

As a result of these efforts and the data we have been able to collect, the ICANN org has increased confidence that the root KSK rollover planned for 11 October 2018 will have the potential to affect only a tiny fraction of DNS users.


1 https://www.iana.org/dnssec/icann-dps.txt

2 https://datatracker.ietf.org/doc/rfc5011/

3 https://datatracker.ietf.org/doc/rfc8145/

4 http://root-trust-anchor-reports.research.icann.org/

5 http://www.potaroo.net/ispcol/2018-04/ksk.pdf [PDF, 184 KB]

Comments

    Jessica Mullen  07:08 UTC on 27 July 2018

    Will this again jumble-up the ranking on Google on October?

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."