(August 25, 2017 – Jarret Cummings) The National Telecommunications and Information Administration (NTIA) of the U.S. Department of Commerce has asked EDUCAUSE to help spread the word about the scheduled transition in cryptographic keys for the Domain Name System Security Extensions (DNSSEC) protocol. Networks that have implemented DNSSEC will need to plan for the rollover to new keys in order to avoid service disruptions.
Please review the NTIA memo below for more information, including links to relevant ICANN resources about preparing for the DNSSEC key update. Note that the update will occur on Wednesday, October 11, 2017.
TO: Internet Service Providers/Network Operators/DNS Administrators
FROM: National Telecommunications and Information Administration (NTIA), U.S. Department of Commerce
SUBJECT: Changes to Domain Name System Cryptographic Key – Take Action Prior to October 11, 2017, to Avoid Potential Disruption
Overview: If your DNS recursive resolvers have been configured to use domain name system (DNS) Security Extensions (DNSSEC), congratulations, your network is utilizing a protocol designed to protect Internet users from domain name hijacking by validating DNS data. That being said, if your network has DNSSEC enabled and your recursive resolvers are performing validation, your administrators *must* take action in advance of October 11, 2017, to avoid potential network disruption.
Background: The Internet Corporation for Assigned Names and Numbers (ICANN), which is responsible for the DNSSEC-signed DNS Root Zone, is planning to roll, or change, the "top" pair of cryptographic keys used in the DNSSEC protocol, commonly known as the Root Zone Key Signing Key (KSK). This will be the first time the KSK has been changed since it was initially generated in 2010.
Changing these DNSSEC keys is an important security step, in much the same way that regularly changing passwords is considered a prudent practice by any Internet user. The root zone KSK consists of a private key and a public key. The private component is securely stored by ICANN, but the public component is widely distributed and configured in a large number of devices, possibly numbering in the millions. The multi-step KSK rollover process basically involves generating a new cryptographic key pair and then distributing the new public key. Internet service providers, enterprise network operators, and others performing DNSSEC validation must ensure their systems are updated with the public part of the new KSK in order to assure trouble-free Internet access for their users.
If you don't use DNSSEC, your system will not be affected by the rollover. However, you should know that DNSSEC is an important part of preventing domain name hijacking.
ACTION: What DNS Administrators Need to Know
NOTE – The KSK rollover only affects DNS recursive resolvers that have been configured to use DNSSEC. If DNSSEC is not configured, then the Root Zone KSK rollover will not impact current operation.
If DNSSEC validation is used, the administrator has two options for implementing the KSK rollover:
- Configure automated key rollover: Most DNS implementations now support the automated key rollover protocol specified in RFC 5011. This protocol enables a DNSSEC client to automatically update its trusted keys when the trusted DNS zone signals that it is changing its key. How this configuration is done is implementation-specific, so administrators should consult their implementation's documentation. Automated key rollover can be tested using the ICANN KSK Rollover Testbed [https://automated-ksk-test.research.icann.org/]. This requires the use of a test system, as production systems should not use the testbed (it is not a full root zone). Administrators should monitor their systems during major operations in the rollover time frame (see above). If a large number of errors are seen on the day of or immediately after an event, this could mean that the automated rollover did not work or encountered an error. Administrators may have to the resort to manually updating the Root Zone key (see 2 below).
- Manual key rollover: If the given DNS client uses DNSSEC, but does not support the automated key rollover protocol, administrators must update the key manually. How this is done is implementation-specific, so administrators should consult their implementation's documentation. The new Root Zone key can be added to the set of trusted keys at any time, but should be added before the old key is revoked in order to ensure continued operation. This date is October 11, 2017. Therefore, the new Root Zone key must be added before October 11th, 2017.
Additional Resources:
Quick Guide: Prepare Your Systems for the Root KSK Rollover (ICANN)
KSK Rollover at a Glance (ICANN)
KSK Rollover: Questions and Answers (ICANN)
Jarret Cummings is the Director of Policy and Government Relations for EDUCAUSE.