Replacement of the KSK of the root zone: Are you ready?

On 18 September ICANN published a decision of its Board. It puts an end to more than 2 years of procrastination over the replacement of the KSK (Key Signing Key) of the root zone. The replacement will take place on October 11, 2018.

The reason is that since the implementation of DNSSEC in 2010 in the root zone, the same cryptographic key (called KSK-2010*) has been used to sign the ZSK (Zone Signing Key) which has been used to sign on its turn the root zone. KSK-2010 represents the entry point which, by the interplay of delegations, it is possible to create a chain of trust validating the integrity of a response on a DNS record within a signed zone. This explains why it is strategic.

The decision is especially relevant if you operate, for yourself or for your customers, a DNS resolution service configured to perform DNSSEC validation. In this case, there is still time to comply if you do not yet have KSK-2017 in your keyset.

Why the hell, in 2018, name the key KSK-2017?

Quite simply because the key, created in 2016, was supposed to come into use in 2017. However, ICANN was forced to postpone the operation due to several alerts from community members who were worried about the impact it could have on users. This has triggered impact studies that all concluded that there would indeed be a visible impact. For example, the implementation of RFC-8145 which is used, among other things, by validating resolvers to indicate which trust keys are used for the root, has made it possible to collect data for analysis. The data show that even if a majority of the resolvers "participating" in the data collection are familiar with the 2 keys (KSK-2010 and KSK-2017), the figure of 100% has not yet been reached.

However, given the guarantee that the most important players in the sector are now ready for the change and the conviction that the few percentages of non-compliant resolvers actually represent only a "small" fraction (on the scale of the Internet, it could still quickly represent a few million users), ICANN has decided to cross the Rubicon on October 11. Only a few more days to wait and we shall see the real impact of the change.

So if you are directly concerned, and your validating DNS resolver does not contain these 2 keys, you need to quickly add KSK-2017 to your keyset to anticipate the validation problems. Consulting the 2 links provided at the end of this post should allow you to carry out the operation.

(*) In actual fact, the keys are not identified with these 2 labels (KSK-2010 / KSK-2017) but by integers called "Key Tags". KSK-2010 and KSK-2017 have respectively 19036 and 20326 as "Key Tag".

How to check that your resolver is familiar with KSK-2017?

Logically, on a recent version of Bind, Unbound... the implementation of RFC-5011 ensures the presence of the 2 keys (KSK-2010 and KSK-2017). Here is a non-exhaustive list of a few tests to validate that this is the case.

If you use:

• Unbound: check the file "/var/lib/unbound/root.key" (Caution, it may be elsewhere if the configuration has been customized).
• Bind: on recent versions (> 9.11), use the command "rndc managed-keys status"; on the others, you have to look for one of the bind.keys files, managed-keys.bind or *.mkeys (it depends on your configuration).
• Knot Resolver: type the command "trust_anchors.keysets" in the console.
• PowerDNS Recursor: type the command "rec_control get-tas".

For more detailed information, we recommend the following 2 links:

• https://www.icann.org/resources/pages/dns-resolvers-checking-current-trust-anchors-2018-06-28-fr

• https://www.icann.org/resources/pages/dns-resolvers-updating-latest-trust-anchor-2018-06-27-fr

Other useful Afnic links on DNSSEC:

• Afnic DNSSEC Issue paper

• Afnic DNSSEC Deployment Guide

(*) In actual fact, the keys are not identified with these 2 labels (KSK-2010 / KSK-2017) but by integers called "Key Tags". KSK-2010 and KSK-2017 have respectively 19036 and 20326 as "Key Tag".