Today, ICANN created a new root zone key signing key (KSK). This new cryptographic public/private key pair was made during the quarterly Root KSK Ceremony at our secure key management facility in Culpeper, Virginia. With this key generation, the initial operational phase of the first-ever root KSK rollover– the process of changing the “master key” of the Domain Name System (DNS) – has begun. The complete KSK rollover process is expected to take about two years.
The root zone KSK serves as the trusted starting point for DNS Security Extensions (DNSSEC) validation, similar to how the root zone itself serves as the starting point for DNS resolution. Software performing DNSSEC validation trusts the public portion of root zone KSK, which has been configured into resolvers and is known as the root “trust anchor”. DNSSEC validation software starts with the trust anchor to build a “chain of trust” of successive keys and signatures to check the authenticity of signed data in DNSresponses. However, like any password, the root’s key should be changed periodically. Performing a KSK rollover minimizes the risk that the key will be compromised and helps to make sure we have the ability to change the key if it is ever compromised or lost.
Now that the new key has been generated, it will be prepared for operational readiness in the coming months. A copy of the private part of the key pair will be stored at ICANN‘s second key management facility in El Segundo, California. The trust anchor file available from iana.org will be updated with the new KSK in February 2017. DNS software developers and integrators should then include the new key in their products. The new KSK will become widely visible when it is published in DNS for the first time on 11 July 2017. These activities all lead up to the actual rollover event, when the new key is used for signing in the root zone for the first time, which will occur on 11 October 2017.
Network operators who have enabled DNSSEC validation on their DNS resolvers will need to update their systems with the new root KSK once it has been published.
Neglecting to install the new trust anchor after 11 October 2017 will cause all DNS lookups performed by non-updated resolvers to fail.
Should such failures occur, clients making use of those resolvers would behave as if websites, email addresses, and all other domains do not exist. Fortunately, most modern validating resolvers have an automated mechanism to update the trust anchor. However, after the new trust anchor is published in February 2017, network operators should ensure that the new trust anchor is in place, either by confirming it has been updated automatically or configuring it manually.