Skip to main content

KSK Rollover Operations Begin

Ksk rollover operations 750x514 27oct16 en

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 DNS responses. 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.

Learn more about the KSK rollover.

Comments

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."