Happy holidays from ISC!
ISC is fortunate to have staff members in so many different countries around the world: our software development benefits from all the different perspectives - and we benefit personally!
Read post
Update September 28, 2017 - ICANN has decided to postpone the October 11th key rollover step. No new schedule is available yet. https://www.icann.org/news/announcement-2017-09-27-en
Update August 2, 2017 - see this detailed more recent description of the Root KSK Rollover in BIND.
Executive Summary
If you manage a DNS resolver, you may need to take action due to the upcoming root key rollover.
- If you use BIND with “managed-keys” for the root zone or “dnssec-validation auto”, there is low risk.
- If you use BIND with “trusted-keys” for the root zone, you need to update your configuration.
- Anyone setting up a new BIND instance around the time of the root key rollover will need to pay careful attention, to ensure their system is able to initialize properly.
- Organizations repackaging or redistributing BIND will need to update their distributions in 2017 to ensure any new installations that happen during or after October 2017 include the new key.
There are some risks in all configurations, discussed below.
What is the Root Key (KSK) Rollover?
The DNS root key is a cryptographic public-private key pair used for DNSSEC signing of the DNS root zone records. The root zone key-signing key (KSK) serves as the anchor for the “chain of trust” that enables DNS resolvers to validate the authenticity of any signed data in the DNS. The integrity of the DNS depends on a secure root key.
In 2017 IANA will replace the current key with a new key. It is important to roll cryptographic keys periodically to help protect them from compromise. In this case, since this is the very first time the key has been changed since the DNS root was initially signed in 2010, it is also a test of the rollover process.
Timeline
Matt Larson presentation at DNS-OARC, Dallas, TX, Oct 2016
The rollover includes multiple steps. It has already begun, and will continue through 2017.
Key dates are:
- October 27, 2016: KSK rollover process begins as the new KSK is generated.
- July 11, 2017: Publication of new KSK in DNS.
- September 19, 2017: Size increase for DNSKEY response from root name servers.
- October 11, 2017: New KSK begins to sign the root zone key set (the actual rollover event). (NB: Postponed as of September 28, 2017)
- January 11, 2018: Revocation of old KSK.
- March 22, 2018: Last day the old KSK appears in the root zone.
- August 2018: Old key is deleted from equipment in both ICANN Key Management Facilities.
(Dates for these steps are published by ICANN at https://www.icann.org/resources/pages/ksk-rollover/#overview
Impact of Changing the DNSSEC Root Key
DNS Message Size Increase
The first impact is increased size of DNS messages containing the root keys. The process of replacing the 2010 key with the 2017 key requires a period of overlap, during which the 2010 key is still used for signing, but the 2017 key is also present, so that systems can learn the 2017 key and “trust” it, based on the 2010 key. While both keys are present, they will increase the size of some messages in the DNS. Even after the 2010 key is removed, the messages will still be larger than they were before the key rollover was started, because the 2017 key is larger than the 2010 key. (The larger 2017 key is of course harder to crack, and therefore more secure.) While all the effects of this increase in message size are difficult to predict, this issue has been studied extensively and is not believed to pose any significant problem. (see ICANN’s external design team’s ICANN Root Zone KSK Rollover Plan for detailed analysis or Geoff Huston’s more recent blog posting on the impact of the root key rollover). In addition to that, ICANN’s operational plans are also available.
Impact on Validating Resolvers
Of much greater concern is the possible impact on validating resolvers. All DNS resolvers that are currently validating, or that wish to enable DNSSEC validation, must be updated with the public half of the 2017 root KSK, and they have to switch from using the 2010 key to the 2017 key for validation at the right time. This is an issue that applies to any DNS software, not just BIND. A query to a resolver that tries to use the 2010 key to validate after the rollover will fail, and any signed DNS data will not be available to those users. This would mean a blackout of DNSSEC-signed zones for users of validating resolvers that don’t adopt the updated key. Since the root zone is signed, this would effectively blackout the root, and with it, the entire DNS tree, for those users.
It is not difficult to ensure your DNSSEC-validating BIND resolver is properly updated to track the root key rollover. BIND stores the public half of the root key in a local trust anchor database. This database is created when you install BIND and is initialized with the bind.keys file included in the BIND distribution. After initial installation, BIND provides two ways to manage that database: trusted-keys and managed-keys. What, if anything, you need to do during the root key rollover of 2017 depends on which method you are using. We recommend the use of managed-keys, because with managed-keys, BIND will self-update when the root key changes. If you are using BIND with trusted-keys, you will need to update your configuration prior to October, 2017, to avoid a potentially serious service impact.
No Impact on Authoritative Publishers
If you are managing an authoritative BIND system, the root key rollover should not have any impact on your operations. It would still be wise to be aware of the timing of the rollover, particularly if you are signing your zones.
BIND with Managed-Keys
Managed-Keys is the newer, recommended method for maintaining the trust anchor database, and it is the default configuration. If you used the “dnssec-validation auto;” shortcut, that command will have enabled managed-keys for you.
The managed-keys method was introduced in BIND 9.7.0 and permits BIND to automatically update the trust anchors. A BIND resolver configured to use managed-keys will initialize itself upon installation with a default anchor. This anchor comes from a supplied initial-key, if you specify one in the managed-keys statement, the bind.keys file or a built-in default trust anchor, if neither of the other seeds are provided. During initialization, BIND fetches the DNSKEY RRset directly from the zone apex, and validates it using the key specified in the managed-keys statement. If the DNSKEY RRset is validly signed, then it is used as the basis for a new managed keys database.
After the initialization, when BIND is restarted, if there is a keys database, BIND will use that, rather than the key specified in the bind.keys file. The bind.keys file is not consulted, or used, after initial installation, so changing the bind.keys file on a BIND server that is already initialized to use managed-keys will not have any useful effect.
Initializing the BIND managed-keys database
After it is running, BIND observes if there are new trust anchors being introduced for the root, and downloads them and updates the trust anchor database. If you are using managed-keys, BIND will obtain the new root KSK automatically, once it is published in July 2017. A running resolver will query the root periodically for the trust anchor point, whether anyone is querying the resolver or not, so this is not dependent on having a lot of traffic.
The process of updating and putting the new key into service is described in IETF RFC 5011, which BIND supports.
What to do if you are using BIND with managed-keys
- Relax! You probably don’t have to do anything at all.
- Verify that your BIND instance has acquired the new key after it is published in the DNS, in July, 2017.
If you run a RNDC managed-keys status, you would see the new key marked as ‘added’ after July 2017 publication.
If you are using multiple views, check each view to ensure the new key is showing. (BIND 9.7.0 permitted only one managed-keys statement per system, but in BIND 9.8 this was expanded so that there can be a separate set of managed-keys per view.)
If you are running an older version of BIND, and don’t have access to the RNDC managed-keys query, you may have to check the .mkeys files in each view, as below, to see if the new keys were added.
From the ARM:
If named is not configured to use views, then managed keys for the server will be tracked in a single file called managed-keys.bind. Otherwise, managed keys will be tracked in separate files, one file per view; each file name will be the view name (or, if it contains characters that are incompatible with use as a file name, the SHA256 hash of the view name), followed by the extension .mkeys.
- Monitor ICANN for updates on the process as there may be changes in the dates, or new information provided.
- Be on the lookout for DNSSEC validation failures when the key in use changes to the new key.
BIND with Trusted-Keys
Trusted-Keys is the older, manual method for maintaining the trust anchors. ISC recommends against using trusted-keys for the root zone unless you are an expert user with a specific use case requiring manual key management. If you are still using trusted-keys, the best way to avoid an outage during the upcoming key rollover is to change from trusted-keys to managed-keys.
With the trusted-keys method, the system administrator must manually update the bind.keys file, which BIND uses to create the trust anchor database. When you download BIND, there is a copy of the current bind.keys file in the root directory, and another is always available from the ISC website. This file contains the public half of the root KSK.
What to do if you are using BIND with trusted-keys
If you can, the best thing would be to update your configuration to use managed-keys, at least for the root zone key. If you choose this option, tt is essential to make this change before the key rollover occurs in October, so that BIND can successfully initialize managed-keys with the 2010 key prior to the rollover.
The easiest way to enable managed-keys is to simply use the shortcut, dnssec-validation auto; . You must also have a bind.keys file with the 2010 key included, which you can get by downloading a fresh copy of BIND, or by just downloading and installing the keys file itself. To initialize the managed-keys database, restart BIND with managed-keys enabled and a valid bind.keys file present. If you do this prior to the October 2017 rollover, BIND will validate the 2010 key and self-maintain during the rollover.
If you want to continue using trusted-keys for the root zone, you must ensure your bind.keys file is updated to add the 2017 root key before the rollover occurs. You can’t do anything to prepare until the new key is published. To get the new bind.keys file after the 2017 key is published:
- If you download and run an updated version of BIND from ISC* after the new key is published (currently planned for February, 2017), the new key will be included. (* While we will update the software published by ISC, and we will alert the operating system packagers to update their packages, we have no control over what is provided in the various operating system packages.) If you then restart with a managed-keys configuration (either using managed-keys or dnssec-validation auto) BIND will initialize with the included key and self-maintain during the key rollover.
- If you don’t want to update your BIND software, you can download just the new key from ISC or ICANN and manually add it to the bind.keys file in /etc (it is moved there after installation), or replace the bind.keys file with a new one downloaded from isc.org, and restart BIND. This will cause BIND to load the keys in the new bind.keys file. Be sure to update the bind.keys file in your “master copy” of BIND if you have a provisioning system creating builds for new installations.
- Keep the 2010 key in the trust anchor database during the overlap and rollover period. When the old key is withdrawn, you may remove the old key (you don’t have to and it might be wisest to leave it in there just in case).
In Summary
- If you are running authoritative services with BIND, or a resolver that is not doing DNSSEC-validation, you should not see an impact.
- If you are running a BIND validating resolver using managed-keys, relax, you should be fine. If you are curious, check for the new key in your managed-keys BIND instance after July, 2017.
- If you are running a BIND validating resolver using trusted-keys and you can upgrade to managed-keys, do so now, before the root key rollover
- In any case, we recommend monitoring news from ICANN about the root key rollover, as dates may change. Be on the lookout for possible DNSSEC validation failures on or around October 11th, 2017, in case of unforeseen problems.
ISC will be releasing updated versions of BIND in 2017 that incorporate the new key. At this time, the new key is not yet ready to be published. ISC will be able to begin introducing the new key in BIND at some point after the successful completion of the next key ceremony, currently planned for February 2, 2017. Anyone providing re-packaged versions of BIND should plan to update their distributions in Q1 or Q2 of 2017. Older versions of BIND, for example in older operating system releases, must also be updated.
Corner Cases
We have tried to think of corner cases where BIND may not work as some might expect it to, so we can check BIND’s behavior, change it if necessary, or simply explain what to expect.
- BIND can’t update the managed-keys.bind file
The working directory should be always be writable by named. If for some reason, it is not, then the managed-keys initialization process will not work properly, because it has to write to the managed-keys.bind file.
- Running instance updates, but master copy is not updated
A popular operational practice is to use an external provisioning system to create docker images or similar packages, to use when installing and re-installing BIND. If you are using a configuration management system like this, possibly over-writing the managed-keys file created on initial installation, you may have to update the bind.keys file in your provisioning system. Else, you run the risk of installing a version of BIND with an outdated key, that will not validate during installation.
- Fresh install of an older copy of BIND
It is important to download a fresh copy of BIND when doing a new installation, in case the root key has since been updated. If you install copy of BIND with only the 2010 key after the 2017 root key rollover, it will not initialize properly, and will not update itself with the new 2017 key. The trust anchor database must first initialize with a currently valid key. This is a pre-condition for the 5011 rollover support.
From the ARM:
The first time named runs with a managed key configured in named.conf, it fetches the DNSKEY RRset directly from the zone apex, and validates it using the key specified in the managed-keys statement. If the DNSKEY RRset is validly signed, then it is used as the basis for a new managed keys database.
Questions
Q. Wouldn’t it be safest to disable DNSSEC validation?
Uh, no. This is definitely the wrong time to give up on DNSSEC validation. After years of debate over the net value of DNSSEC, given that signed answers are larger and can be used for amplification attacks, DNSSEC validation is now looking like a great defense against one current significant abuse technique. The signed “negative space” in the DNS can prevent “random-subdomain” query attacks (see the IETF Draft on NSEC Aggressive Use or the Geoff Huston blog post on this). In addition, there is growing interest in using DNS with DNSSEC to ensure integrity of cryptographic keys for other applications, such as secure email.
Q. How can you determine whether a BIND instance is configured for managed-keys or for trusted-keys?
Check your named.conf file for a managed-keys or trusted-keys statement specifically for the root zone, “.”
The following is an example of what you would like to see:
managed-keys {
. initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=";
};
If you are running BIND 9.11 or later, you can use the RNDC command,
managed-keys (status | refresh | sync) [class [view]]
You can use both managed and trusted keys for different trust anchors, so look specifically for the key for the root zone, “.”.
If you don’t have access to the relatively new rndc managed-keys feature, use the contributed script in contrib/scripts/check5011.pl. This tool has similar functionality to the rndc command. It reads the managed-keys.bind zonefile and reports on the status of the keys (trusted, untrusted, pending until such-and-such a time, revoked, etc.).
Q. It says in the ARM that there is only one managed-keys statement per system, but here you mention one per view?
The first time managed-keys was added to BIND, it was system-wide. Later it was updated to support a separate trust anchor database for each view. We didn’t update all the places in the ARM we should have when we made that change. We will fix the ARM, sorry about that.
Q. Can I have more than one root key at a time?
Of course. You can have more than one key defined for any zone. During the root key rollover, there is a period of several months when two keys will be published for the root.
If you have one trusted-key for “.” and a different managed-key for “.”, BIND loads up both keys – one as trusted and the other as managed.
If you have the same key configured as both trusted and managed, BIND loads the managed and ignores the trusted.
Q. What is the difference between dnssec-validation auto and dnssec-validation yes?
The difference between dnssec-validation yes and dnssec-validation auto is subtle but important. Dnssec-validation yes requires that a managed-keys statement include an initial key. If you change dnssec-validation auto to dnssec-validation yes and there are no root keys configured in the managed-keys statement, then that signals to named that you no longer care about the root key and you want it to delete it from the database. You probably don’t want to do that in a production system. We recommend using dnssec-validation auto, which will use the built in root key as the initial trust key for initializing the database.
Q. What is ISC going to do to help OS packagers update their packages?
This is a significant concern, because many users get their BIND software via operating system packages. ICANN is considering a possible DNS-ecosystem wide CVE or similar operational notice to reach operating system packagers who publish versions of any DNS system. This notice would come out in 2017. ISC will participate in that announcement and will provide OS packagers of BIND with explicit information on how to incorporate just the new root key into their packages, particularly when they are packaging older versions of the software.
Thank You
Several people reviewed and provided comments or answered questions for me. Besides the ISC BIND team I got advice and helpful comments from:
- Ed Lewis, ICANN
- Timothe Litt, BIND user and contributor
- Tony Finch, BIND user and contributor