Knowledge Base ISC Main Website Ask a Question/Contact ISC
Root KSK Rollover in BIND
Author: Stephen Morris Reference Number: AA-01525 Views: 613 Created: 2017-07-01 15:35 Last Updated: 2017-08-02 15:43 0 Rating/ Voters

In the latter half of 2017, the root zone key-signing key will be changed. A new key will be introduced and used to sign the root zone's DNSKEY RRset, and the old key will be removed. This article describes how BIND will cope with that transition.

This article assumes that you are familiar with DNSSEC. In not, it is suggested that you review ISC Knowledgebase Articles articles such as https://kb.isc.org/article/AA-00820 or read the BIND DNSSEC guide first.

Background

The Problem

DNSSEC was first introduced into the root zone in 2010. The deployment followed a "standard" DNSSEC model: the records in the zone are signed with a zone-signing key (ZSK) and the root zone's DNSKEY RRset is signed with a key-signing key (KSK).

The original intention was to update (or "roll") the KSK after five years. For various reasons, that operation has been delayed by two years but it is now going ahead in the latter half of 2017.

The root zone KSK is special, in that it forms the root of the DNS chain of trust, and so is known as a "trust anchor". The KSK of other zones can be validated by DS records in the zone's parent. Since there is no parent to the root zone, the root KSK has to be validated in other ways. Typically this has been done with a copy of the key provided with your name server software.

Rolling such a key presents a challenge: how can such a change be communicated to potentially millions of name servers? The solution to the problem is to be found in an Internet standards document called RFC 5011. In essence, this says that to roll a trust anchor:

  1. Introduce the new key into the zone and sign it with the existing trust anchor.
  2. Leave it a while so that name servers see the new key. Because it is signed with a key they trust, name servers can trust that key.
  3. When the new key is trusted, revoke the existing trust anchor. This means setting a bit in the old key and keeping the revoked key in the DNSKEY RRset. By querying the DNSKEY RRset, name servers will learn that the old should no longer be used.
  4. Remove the revoked key from the zone.

(There are various intervals between these steps and caveats to the process, all of which are documented in RFC 5011.)

BIND's Handling of Trust Anchors

Being the trust anchor for the whole DNS system, the root KSK is special. However, in the early days of DNSSEC, it was not uncommon for there to be different (independent) trust anchors for different parts of the DNS tree. As DNSSEC developed, BIND was updated to take account of it and as a result has ended up with four different ways of specifying the trust anchor.

1. No Trust Anchors Explicitly Specified
This is the simplest case, where there is nothing in the configuration file and nothing stored in a file on disk. If this is your configuration, then, quite honestly, the easiest way to get a new copy of the root key is to download a recent version of BIND. All versions of BIND since April 2017 (i.e. 9.9.10, 9.10.5, 9.11.1 and later) include a hard-coded copy of the new root KSK. If you have not configured your version of BIND with either a trusted-keys or managed-keys statement, just install the latest version of BIND and restart - BIND will automatically pick up the new key.

2. Presence of a bind.keys File
The bind.keys file (usually located in /etc) is a file that contains trust anchors for the root zone and the (now-obsolete) ISC DLV zone, overriding the hard-coded trust anchors in BIND. Unless there is any compelling reason why you have a bind.keys file, you are best advised to delete the file, install the latest version of BIND and restart, as described above.

3. trusted-keys Clause in the BIND Configuration File
The hard-coded keys in BIND (possibly overridden by the bind.keys file) are used if DNSSEC validation is enabled and the dnssec-validation configuration option is set to auto. If you have trust anchors for other than the root zone or the (now-obsolete) ISC DLV zone, you may have set dnssec-validation: yes in the configuration file and defined the trust anchors with a trusted-keys clause.

Under these circumstances, maintenance of the trust anchors is manual. To add the new root KSK, you must edit the configuration file and include into it a copy of the new root key. This can be obtained by looking at a default copy of bind.keys that ISC provides on its web site: https://ftp.isc.org/isc/bind9/keys/9.11/bind.keys.v9_11. Just copy the entry for the new key (20326) into your trusted-keys clause and issue an rndc reconfig command (or restart BIND).

4. managed-keys Clause in the BIND Configuration File
Recent versions of BIND have introduced the managed-keys clause, which should be used in preference to the now-deprecated trusted-keys option. The difference between them is that trusted-keys requires manual maintenance of key changes, whereas the update of trust anchors defined by managed-keys will happen automatically: BIND queries the zone on a regular basis and uses the algorithm described in RFC 5011 to update both the keys and their status.

As BIND updates the keys, the configuration file is not changed. Instead, BIND writes updated key information to the file managed-keys.bind and a journal file, managed-keys.bind.jnl. (Both these files are located in the directory specified by the directory statement in your configuration file.) You can check the progress of the key rollover, either by looking at this file or, more conveniently, executing the command rndc managed-keys status. The following describes what you should see as the rollover progresses.

Initially, assuming that you don't have any trust anchors other than the root key configured, executing the rndc managed-keys status output should include something like:

    name: .
    keyid: 19036
        algorithm: RSASHA256
        flags: SEP
        next refresh: Tue, 23 May 2017 16:21:37 GMT
        trusted since: Mon, 22 May 2017 16:21:37 GMT
 

(The exact dates and times in the output will be different from this example.) The "trusted since" date is an indication of how long BIND has trusted that this key is the root key. It is likely that this will be the date at which you first created your managed-keys.bind file. "next refresh" tells you when BIND will query the root zone looking for new keys.

When the new key is introduced (currently scheduled for 11 July 2017), BIND will see it and within two days, add it to the list of managed keys. At this point, the listing looks like:

    name: .
    keyid: 19036
        algorithm: RSASHA256
        flags: SEP
        next refresh: Mon, 29 May 2017 10:07:39 GMT
        trusted since: Mon, 22 May 2017 16:21:37 GMT
    keyid: 19741
        algorithm: RSASHA256
        flags: SEP
        next refresh: Mon, 29 May 2017 10:07:39 GMT
        trust pending: Tue, 27 Jun 2017 10:07:39 GMT
 
The standard that BIND is following for this operation - described in the document RFC 5011 - states that for the key to be fully trusted, it must be present in the zone for a period of 30 days. For this reason, BIND does not fully trust the key and so marks it as "trust pending". During this 30-day period, BIND periodically checks the zone. If ever the new key is not present, BIND will forget about it - should it reappear, the 30-day timer starts again.

Assuming however that the key remains in the zone for the full "trust pending" period, BIND will eventually accept it as a trusted key:

    name: .
    keyid: 19036
        algorithm: RSASHA256
        flags: SEP
        next refresh: Mon,  3 Jul 2017 10:07:39 GMT
        trusted since: Mon, 22 May 2017 16:21:37 GMT
    keyid: 19741
        algorithm: RSASHA256
        flags: SEP
        next refresh: Mon,  3 Jul 2017 10:07:39 GMT
        trusted since: Tue, 27 Jun 2017 10:07:39 GMT
 
When this occurs, BIND can use either key to validate DNSSEC signatures in the root zone and so the new key is also regarded as the root trust anchor for the world's DNS system.

The root zone entries are scheduled to start being signed by the new KSK three months after the key is introduced, on 11 October 2017. Three months after that, on 11 January 2018, the old KSK is revoked:

    name: .
    keyid: 19036
        algorithm: RSASHA256
        flags: SEP
        next refresh: Mon, 24 Jul 2017 10:07:39 GMT
        remove at: Mon, 14 Aug 2017 16:21:37 GMT
        trust revoked
    keyid: 19741
        algorithm: RSASHA256
        flags: SEP
        next refresh: Mon, 24 Jul 2017 10:07:39 GMT
        trusted since: Tue, 27 Jun 2017 10:07:39 GMT
 
Once the "remove at" date has passed (for the root KSK, this date is scheduled for 22 March 2018), the key is removed from BIND's managed-keys set.


© 2001-2017 Internet Systems Consortium

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Feedback
  • There is no feedback for this article
Quick Jump Menu