On 11 July 2017, a new KSK (Key Signing Key) is going to appear in the DNS root zone. This key labelled as KSK-2017 (key tag: 20326) will eventually replace KSK-2010 which has been the top-most pair of cryptographic keys used in the DNSSEC protocol since the Root Zone was signed in July 2010. It is the first time in history that ICANN is changing the Root Zone KSK as part of normal security best practices.

What is a Root Zone KSK?

The Root Zone KSK is known as the trust anchor of the DNSSEC infrastructure, which means that it is itself not signed by another key, as it is the case for keys down in the DNS hierarchy. That is why, the root key must be configured as trust anchor in all DNSSEC validators such as DNS recursive name servers and DNS resolvers, which are operated by Internet Service Providers (ISPs) and other network operators. Failure to update to the new root zone’s KSK, will result in DNSSEC validation error and DNS queries will not resolve.

The new Root Zone KSK with keytag 20326

How does it work?

DNSSEC is a security protocol, that was designed to add authentication and data integrity services to the DNS. Zone information can now be cryptographically signed and DNS clients can validate signatures by retrieving the zone’s public key, which is also stored in the zone file. However, to be able to trust public keys, we need a “chain of trust”. As opposed to the X.509 model, DNSSEC does not have a Certificate Authority (CA) that can vouch for authenticity of the public keys. Instead, DNSSEC builds a “chain of trust” starting with the “trust anchor”, a key that is declared as the authoritative and trustworthy one.

To validate a signature, the validator needs to start with the “trust anchor” and then it will validate the whole DNSSEC tree till it reaches the zone file of the record, which contains the public key information. Using the public key, the validator can now verify the signature of the DNSSEC RRset. Obviously, the validation process in reality is more complicated as it involves both KSK and ZSK.

As a simple example, let’s say your browser wants to access www.example.org, your DNSSEC validator will perform the following:

1. Fetch the “trust anchor” i.e. the Root Zone KSK installed locally
2. Fetch the .org  DNSKEY RRset in the root zone and validates the signature using the Root Zone KSK
3. Get the public key from the .org zone
4. Get the .example.org DNSKEY RRset and validate the signature using the .org public key
5. Get the public key from the .example.org zone
6. Get the www.example.org DNSKEY RRset and validate the signature using the .example.org public key

It is therefore required for any device doing DNSSEC validation to have the root zone’s KSK configured as a trust anchor.

What will happen on 11 October 2017?

Beginning the 11 October 2017, the new root zone’s KSK will start signing DNSKEY RRset, but the old root zone’s KSK will still be present in the root zone till 11 January 2018. This, to continue allowing validation of signatures using the old KSK.

How to obtain the new trust anchor?

Any organisation operating a DNSSEC validator should ensure that their system have the latest trust anchor. There are two ways to update the trust anchor in your DNSSEC validator:

1. Manually: You need to get a copy of the trust anchor from an official source and make sure it is authentic before manually updating your configurations. It is recommended that you use the root zone trust anchor file provided by IANA. You should also validate the detached signature provided by IANA, signed by the ICANN CA, to make sure the trust anchor is valid.
2. Automatically: If your DNSSEC-aware resolver or recursive name server is configured to use RFC5011, it should receive automatic updates of the DNSSEC Trust anchors and no further action is required. However, if the DNSSEC Validators are offline during the rollover process, they will have to be updated manually if they are brought online after the rollover is completed.

Timeline

Some references:

ICANN Material:

ICANN KSK Rollover website

AFRINIC-25 Presentation:

Rolling the DNSSEC Root Zone KSK

Testbed:

Automated Trust Anchor Update Testbed

Root Canary Project

Queries

For any queries regarding the DNSSEC Root Zone KSK rollover, contact us on This email address is being protected from spambots. You need JavaScript enabled to view it.