NIST logoITL Logo




DNSSEC


What is DNSSEC?

The DNS Security Extensions (DNSSEC) is a set of protocol extensions to DNS to digitally sign DNS information. This provides source authentication and integrity protection for DNS data and responses. DNSSEC is completely opt-in: clients must signal that they want DNSSEC information included in responses. Trust in DNSSEC is built upon the hierarchy already established in the DNS. Parent zones (e.g. ".gov") vouch for the security state of its child delegations (e.g. "nist.gov"). DNSSEC is mandated for use in the US Federal government and included in FISMA.

Clients must have one or more validation keys pre-configured in order to validate DNSSEC responses. Keys higher in the DNS hierarchy are preferred as then trust can be established for all delegations under that node in the DNS. For example, the key for .gov can be used to build trust in any DNSSEC signed domain under .gov. The DNS Root Zone (".") is the top node of the entire DNS tree. Clients configured to use the Root Zone key for DNSSEC will be able to validate any DNSSEC signed zone.

Root Zone DNSSEC Key Rollover

The Root Zone first deployed DNSSEC in 2010. With any secure protocol deployment, a regular changing of keys is necessary as part of normal operations. This key updating (called a "key rollover") will take place this year (2017). The Internet Corporation for Names and Numbers (ICANN), the entity that manages the DNS Root Zone, has developed and executing their plan to roll over the Root Zone key.

Due to operational concerns indicating that a minority of systems not reporting configuration of the new root key, ICANN has postponed the rollover. The postponement is expected to be 12 months from the initial rollover event (October 11, 2017). ICANN has also issued a new document "What to Expect During the Root KSK Rollover" (PDF) available for download.

The ICANN plan for the Root Zone key rollover is documented on their website. The major milestones are:

What DNS Administrators Need to Know

First, the KSK rollover only affects DNS recursive resolvers that have been configured to use DNSSEC. If DNSSEC is not configured, then the Root Zone rollover will not impact current operation.

If DNSSEC validation is used, the administrator has two options:

  1. 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. 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).
  2. 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. From the posted roadmap, this date is October 11, 2017. Therefore, the new Root Zone key (that is already published), must be added before October 11th, 2017.
  3. Testing: ICANN has set up an information page for administrators to test their own validating recursive servers to ensure that the correct set of KSKs are being used as trust anchors.

Other Resources


Questions or comments should be sent to the HAD admin

NIST is an agency of the U.S. Department of Commerce.

Privacy policy / security notice / accessibility statement / Disclaimer / Freedom of Information Act (FOIA) / Environmental Policy Statement / No Fear Act Policy / NIST Information Quality Standards / Scientific Integrity Summary

Date created 7/13/2017. Last updated 9/6/2018.