The KSK key pair for the root zone, the first link in the chain of trust that DNSSEC offers, is being renewed. What does this mean for the registries and the administrators of validating resolvers?
What is DNSSEC?
stands for Domain Name System – the system of domain names that Microsoft.com links to the digital IP address 2a02:6e0:0:2015::139 (ipv6) or 18.104.22.168 (ipv4). The user could not possibly remember those digital addresses.
A security layer is added to guarantee the authenticity of those IP addresses: DNS Security Extensions or DNSSEC. This is intended to prevent the injection of false information in the of the DNS servers (cache poisoning) or interception or falsification of the communication between the DNS and the computer that carries out the query (Man-in-the-middle attack).
The extra security layer of DNSSEC consists of a digital signature, which is added to the answer to the DNS query. The task of DNSSEC is to sign (generate and record the digital signature for a domain name in the DNS system) on the one hand, and to validate it (check the digital signature when a domain is requested) on the other.
New key pair
The very first root Key Signing Key (KSK), the cryptographic key pair that underlies the entire DNSSEC infrastructure, was generated, installed and published in 2010. It is now being replaced – a delicate operation which requires also the cooperation of all administrators of validating resolvers. They must in fact ensure that the new public key is added as the trust anchor on their servers. Once the roll-over is completed, they must remove the old key from their systems.
The implementation of these new keys is therefore very important – otherwise, the Internet would become inaccessible in 2018 for all users and all applications of those validating resolvers.
How to proceed with the implementation
Without delving excessively into the technology, there are in essence three ways for administrators of validating resolvers to proceed:
- Manually: retrieve the key from the website and process it in the configuration of the resolver. Then remove the old key or switch it off.
- Automatically (especially applicable for various Linux distributions): install the new trust anchor and then remove the old trust anchor as part of an update.
- RFC5011: with this new protocol, the validating resolver itself will retrieve a new (public) key and install it as a trust anchor fully automatically. This protocol is supported by PowerDNS, BIND named and Unbound, but not by Infoblox.
Whichever method is used, it cannot be stressed enough that this is a delicate operation. Administrators of these services must also monitor the installation of the new (public) key closely, even when it is carried out automatically.
Tip: Is your .be website secured with DNSSEC? Test it at ViewDNSinfo.
This schedule is subject to change for operational reasons.