Skip to main content

Changing the Keys to the Domain Name System (DNS) Root Zone

Changing keys dns root zone 756x503 09may16 en

Ensuring the Integrity of the top level of the DNS Through Security Best Practices

In July 2010, ICANN, Verisign, and NTIA added a level of protection to the Internet's top DNS layer using a technology known as DNSSEC, which stands for Domain Name System Security Extensions. This technology was developed to protect Internet users against attacks that can result in domain name hijacking and certain types of compromised servers. Use of DNSSEC increases the assurance that information obtained from the DNS has not been modified during transit from the data source to the machine asking the question on behalf of a user – this is done by digitally signing and validating the DNS data. This validation relies upon a "trust anchor," or key, that is associated with the root of the DNS.

As with any key, password or security system, the trust anchor needs to be updated on a regular basis. In keeping with best practices, the team at ICANN acting as the IANA Function Operator, along with the other Root Zone Management Partners (Verisign acting as the Root Zone Maintainer, and the U.S. Department of Commerce's National Telecommunications and Information Administration (NTIA) acting as the Root Zone Administrator), has been at work in preparing for the "rolling" or changing of the the cryptographic private-public key pair that is the Root Zone Key Signing Key (KSK), the public side of which serves as the Internet's DNSSEC trust anchor. Rolling the KSK means generating a new key pair and distributing the public component to parties who develop, distribute or operate validating resolvers. The KSK rollover can be thought of as changing the locks on a house. In cases where domain names are DNSSEC-signed, each time an Internet user attempts to connect to server identified by a domain name, the key is tried in the lock to verify the data associated with that domain name is authentic. However, if the lock is changed and the keys have not also been updated, the door will not open, the domain name will not resolve and the connection attempt will fail. The potential impact of the rollover underscores the need for widespread and adequate distribution of the trust anchor for the new KSK. To make sure the community is aware of the latest updates about the KSK roll and the resulting new trust anchor, we have created this resource page.

When the Internet community first deployed DNSSEC at the root, the Root Zone Management Partners in consultation with the community specified that the "KSK will be scheduled to be rolled over through a key ceremony as required, or after 5 years of operation." While some people in the community saw this as a five-year deadline, the timeline of rolling the KSK must be contingent on the operational realities of the Internet landscape. Over the past year or so, the IANA Stewardship Transition has been the most public facing issue from a communications perspective, but work on the KSK roll has continued in parallel. Moving forward, to make sure the community is aware of all of the work and due diligence around the activities of the KSK roll, I will be providing regular updates on our progress. Additionally, we will host sessions at ICANN meetings and other technical fora to provide in-depth information on the KSK roll and what actions need to be performed by those concerned to ensure the KSK roll goes smoothly.

Over the next few weeks we will be providing more details on the KSK rollover, but to give you a sense of the current timeline for the roll:

  • October 2016: KSK rollover new key preparation process begins
  • November 2016: Generation of new KSK
  • July 2017: Insertion of new KSK
  • October 2017: Withdrawal of old KSK
  • January 2018: Revocation of old KSK
  • March 2018: Completion of KSK rollover process

Obviously this timeline is subject to change should circumstances warrant: rolling the KSK, like periodically changing your password, is a best practice, but it needs to be done with due care and consideration to ensure it does not cause disruption to the operation of the Internet's DNS.

For those interested in becoming more involved in the KSK rollover, you can join the mailing list for public discussions at https://mm.icann.org/listinfo/ksk-rollover or if you have questions, you can send an email with your questions to globalsupport@icann.org with "KSK Rollover" in the subject line.

DNSSEC and the KSK rollover are important contributions to a more secure and robust DNS. We are committed to working closely with our Root Zone Management partners, DNS operators and the Internet community as a whole as we progress with this vital work over the course of the next two years. As we - as a global Internet community - prepare the first ever roll of the KSK, we are excited about the opportunity to further enhance the safety of the web and lay the groundwork for future work on the evolution of the Internet.

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