Operational Notification: KSK-2010 will be retired from the root zone, potentially affecting validating resolvers

Summary

KSK-2010, the DNSSEC Key Signing Key that has served as the trust anchor for the root DNS zone (.) since it was introduced in 2010, is scheduled to be retired soon. A new key, KSK-2017, has been introduced and operators of validating resolvers should check their servers to ensure that they are correctly configured to make use of the new key, otherwise validation will break when the 2010 key is retired.

Original Posting Date: 28 September 2017

Updated: 27 September 2018

Program Impacted: BIND

Versions Affected: All release versions of BIND 9

Description

Best practices for DNSSEC require that the keys used to guarantee authenticity of data (via cryptographic signing) be periodically replaced at appropriate intervals. In accordance with these practices, ICANN, the organization responsible for stewardship of the DNSSEC keys for the root zone of the DNS, is performing a long-planned replacement of the Key Signing Key (KSK) used to sign the DNS root. Unlike other keys within the DNS hierarchy, the root zone KSK is unique, as there is no parent node above it which can sign it to demonstrate its authenticity. A validating resolver, therefore, needs to be aware of the root zone KSK so that it can be used as a trust anchor for the remainder of the DNS hierarchy.

The procedure for the replacement of the root KSK, which is described in RFC 5011, began earlier this year with the generation of a new key and its introduction into the DNS root. We are now approaching the date planned for the end of the overlap period laid out in the RFC, after which the old key will be retired from use and no longer used to sign records in the zone. However, telemetry data collected by ICANN, ISC, and the root server operators indicated in 2017 that there were still a significant number of validating resolvers which were using only the old, soon-to-be-retired KSK. Consequently, ICANN announced plans to postpone the KSK-2010 key's retirement to allow server operators more time to ensure they were prepared for the change. When the old KSK is retired, servers which have not at that time incorporated the new trust anchor will suddenly begin failing validation, as they will be unable to verify signatures generated from the new key, and only the new key will be in use at that time.

The key rollover date has been set for October 11, 2018, when the DNS root zone will be signed with a new key. We are therefore issuing this operational notification to inform operators how to check whether they are correctly configured to use the right root trust anchors .

Impact

The information in this advisory applies principally to recursive resolvers that are performing DNSSEC validation for their clients. If you are not using DNSSEC you do not need to be concerned about this specific issue.

Servers which have not been configured to use KSK-2017 by the time KSK-2010 is retired will begin failing validation once signatures from the old key are no longer present in the root zone; at that time they will begin incorrectly returning an error code to queries which should have a valid answer because they are not able to verify the answers using the only trust anchor of which they are aware.

Solution 

Ensure that you have configured your server to use the proper trust anchors before KSK-2010 is retired and check the state of your running server to verify that your configuration has been correctly applied.

How do I check?

The easiest way to check what trust anchors are available is to use the rndc command to query the server. In all currently supported release branches, rndc secroots will dump a list of current trust anchors to a file called named.secroots. In BIND 9.11 and higher, rndc secroots - (with a hyphen at the end) will print the same list to stdout. Also in BIND 9.11.0 and higher, rndc managed-keys status will provide the same information, along with additional details about key status and updates. Also, the managed-keys database can be inspected directly; on servers that are not configured to use views, this is a file called managed-keys.bind, and on servers with views it will be a file called .mkeys or .mkeys.

What should I look for?

If your server is aware of the new key (KSK-2017) it should be listed among your trust anchors.  Look for a key with ID 20326 to verify that your server is aware of KSK-2017.

What do I do if I don't have the new key listed among my trust anchors?

The answer to this question depends on why the new key is not included in your trust anchors.  The most common scenarios are:

• Keys are manually configured (using the "trusted-keys" and "dnssec-validation yes;" configuration statements in named.conf) and KSK-2017 has not been added. (Solution: enable automated key management or add the key manually.)
• Key management is set to be automatic (using the "managed-keys" or "dnssec-validation auto" configuration statements in named.conf) but the server cannot write the new key because the named process cannot write to the directory where keys are to be stored (either the server's working directory or the directory specified by "managed-keys-directory"). (Solution: ensure that the UID under which the named process is running (which may have been set to a particular non-root user using the -u startup flag) has the necessary permissions to write to the appropriate directory or specify a writable managed keys directory, then remove any existing managed-keys file and restart named.)
• If your situation is not covered by one of the two scenarios above: in most cases where automatic key management is configured, removing any existing trust anchors and restarting the server should cause named to correctly fetch the appropriate trust anchor information. More information is available in the article Root KSK Rollover in BIND.

Note: In recent versions of BIND (since 9.9.10, 9.10.5, and 9.11.1), KSK-2017 is included with the built-in initializing keys that are used when a server is configured with "dnssec-validation auto;". If you are running an older release, you can update the built-in keys by downloading a new copy of bind.keys from https://www.isc.org/bind-keys. This will be needed to initialize or reinitialize RFC 5011 key maintenance after KSK-2010 has been withdrawn from the root.

Legal Disclaimer

Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors.