Key Management

Best practice for DNSSEC key management is to use different keys to sign zone data (ZSK) and DNSKEY data (KSK), as we've discussed in the section called “Do I Need Separate ZSK and KSK?”. Since these keys serve different functions, their timing and methods of rollovers are also different. In the section called “Maintenance Tasks”, we have broadly talked about how to perform a generic ZSK and KSK rollover. In this section, we will discuss two topics in more detail:

  1. Different considerations and methods of key rollovers.
  2. Key meta data and management

Key Rollovers

Generally speaking, ZSKs should be rolled more frequently than KSKs. In the section called “Maintenance Tasks”, we described at a very high level how to roll the ZSK every year using key pre-publication (described below), and how to roll the KSK every five years using double DS (also described below). Here, we show some other methods of rolling keys. To see examples of key rolling, please refer to the section called “Rollover Recipes”. For (far) deeper discussions and considerations on the topic of key rolling, check out RFC 7583 .

ZSK Rollover Methods

Generally speaking, the ZSK is smaller in size (compared to the KSK) for performance, but smaller keys take less time to break, thus the ZSK should be changed, or rolled, more frequently. The ZSK can be rolled in one of the following two ways:

  1. Pre-publication: Publish the new ZSK into zone data before it is actually used. Wait at least one TTL so the world's recursive servers know about both keys, then stop using the old key and generate new RRSIG using the new key. Wait at least another TTL, so the cached old key data is expunged from world's recursive servers, before removing the old key.

    The benefit of the Pre-publication approach is it does not dramatically increase the zone size, but the duration of the rollover is longer. If insufficient time has passed after the new ZSK is published, some resolvers may only have the old ZSK cached when the new RRSIG records are published, and validation may fail. This is the method that was described in the section called “ZSK Rollover” and the section called “ZSK Rollover Recipe”

  2. Double Signature: Publish the new ZSK and new RRSIG, essentially double the size of the zone. Wait at least one TTL before removing the old ZSK and old RRSIG.

    The benefit of the Double Signature approach is that it is easier to understand and execute, but suffers from increased zone size (essentially double) during a rollover event.

KSK Rollover Methods

Rolling the KSK requires interaction with the parent zone, so operationally this may be more complex than rolling ZSKs. There are three methods of rolling the KSK:

  1. Double-DS: the new DS record is published. After waiting for this change to propagate into caches, the KSK is changed. After a further interval during which the old DNSKEY RRset expires from caches, the old DS record is removed.

    Double-DS is the reverse of Double-KSK: the new DS is published at the parent first, then the KSK at the child is updated, then remove the old DS at the parent. The benefit is that the size of the DNSKEY RRset is kept to a minimum, but interactions with the parent zone is increased to two events. This is the method that is described in the section called “KSK Rollover” and the section called “KSK Rollover Recipe”.

  2. Double-KSK: the new KSK is added to the DNSKEY RRset which is then signed with both the old and new key. After waiting for the old RRset to expire from caches, the DS record in the parent zone is changed. After waiting a further interval for this change to be reflected in caches, the old key is removed from the RRset.

    Basically, the new KSK is added first at the child zone and being used to sign DNSKEY, then the DS record is changed, followed by the removal of the old KSK. Double-KSK limits the interaction with the parent zone to a minim, but for the duration of the rollover, the size of the DNSKEY RRset is increased.

  3. Double-RRset: the new KSK is added to the DNSKEY RRset which is then signed with both the old and new key, and the new DS record added to the parent zone. After waiting a suitable interval for the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY and DS record are removed.

    Double-RRset is the fastest way to roll the KSK (shortest rollover time), but has the drawbacks of both of the other methods: a larger DNSKEY RRset and two interactions with the parent.

Key Management and Metadata

In the section called “auto-dnssec”, we alluded that auto-dnssec is doing a lot of automation for us so we don't have to, and we've also alluded to something called the key timing metadata. In fact, if you looked at your key file, it likely already has a section near the top that looks like this:

; Publish: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Activate: 20141120094612 (Thu Nov 20 17:46:12 2014)

These are only two of the five metadata fields of a key. Below is a complete list of each of the metadata fields, and how it affects your key's behavior:

  1. Publish: Sets the date on which a key is to be published to the zone. After that date, the key will be included in the zone but will not be used to sign it (yet). This is notifying validating resolvers that we are about to introduce a new key. By default, if not specified during creation time, this is set to the current time, meaning the key will be published as soon as named picks it up.
  2. Activate: Sets the date on which the key is to be activated. After that date, the key will be included in the zone and used to sign it. By default, if not specified during creation time, this is set to the current time, meaning the key will be used to sign data as soon as named picks it up.
  3. Revoke: Sets the date on which the key is to be revoked. After that date, the key will be flagged as revoked. It will be included in the zone and will be used to sign it. This is used to notify validating resolvers that this key is about to be removed or retired from the zone.
  4. Inactive: Sets the date on which the key is to become inactive. After that date, the key will still be included in the zone, but it will not be used to sign it. This sets the "expiration" or "retire" date for a key.
  5. Delete: Sets the date on which the key is to be deleted. After that date, the key will no longer be included in the zone, but it continues to exist on the file system or key repository.

You can set these metadata fields on a key pair as you've seen in the section called “ZSK Rollover” using commands such as dnssec-keygen or dnssec-settime.

Table 6.1. Key Metadata Comparison

MetadataIncluded in Zone File?Used to Sign Data?Purpose
PublishYesNoIntroducing a key soon to be active
ActivateYesYesActivation date for new key
RevokeYesYesNotifying a key soon to be retired
InactiveYesNoInactivate or retire a key
DeleteNoNoDeletion or removal of key from zone

Manual Key Management and Signing

This guide is intended as an introductory to DNSSEC deployment using BIND. Since BIND comes with a set of features to automate key loading and signing, that is the recommended configuration for readers of this document. In this section, we will only briefly cover tools and commands to manually load keys and manually sign zone data, but not go into great details.

The directive auto-dnssec maintain makes named check for new keys and load them automatically on an interval. If you wish to not automate this process, you could opt to change it to auto-dnssec off. This makes all key management manual, and to load new keys, you will need to execute the command rndc loadkeys example.com.

To manually sign the zone, first, you need to edit the zone file to make sure the proper DNSKEY entries are included in your zone file, then use the command dnssec-signzone as such:

# cd /etc/bind/keys/example.com/
# dnssec-signzone -A -t -N INCREMENT -o example.com -f /etc/bind/db/example.com.signed.db \
> /etc/bind/db/example.com.db Kexample.com.+008+17694.key Kexample.com.+008+06817.key
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 stand-by, 0 revoked
/etc/bind/db/example.com.signed.db
Signatures generated:                       17
Signatures retained:                         0
Signatures dropped:                          0
Signatures successfully verified:            0
Signatures unsuccessfully verified:          0
Signing time in seconds:                 0.046
Signatures per second:                 364.634
Runtime in seconds:                      0.055

The -o switch explicitly defines the domain name (example.com in this case), -f switch specifies the output file name. The second line has 3 parameters, they are the unsigned zone name (/etc/bind/db/example.com.db), ZSK, and KSK file names. This generated a plain text file /etc/bind/db/example.com.signed.db, which you can verify for correctness.

Finally, you'll need to update named.conf to load the signed version of the zone, so it looks something like this:

zone "example.com" IN {
    type master;
    file "db/example.com.signed.db";
};

You will need to re-sign periodically as as well as every time the zone data changes.

How Long Do I Wait Before Deleting Old Data?

If you have followed the examples described in the section called “Easy Start Guide for Signing Authoritative Zones” and the section called “Maintenance Tasks”, old keys and old signatures are automatically removed from the zone.

However, it is still good to discuss why bother waiting a period of time before removing any old data, be it DNSKEY or RRSIG. The goal here is to not "orphan" anyone out there who may be getting a cached answer, and the information to verify that cached answer doesn't exist anymore. For example, if you chose to pre-publish your ZSK, but did not wait long enough before removing the old ZSK, you're running with the risk that there may be users out there receiving the old RRSIG out of cache, but they are unable to verify the cached old RRSIG because the old ZSK has already been removed. To these users, the domain names would fail validation, until the cached RRSIG entries expire, and their validating resolver retrieves the new RRSIG signed by the new ZSK.

In the section called “Maintenance Tasks”, we recommended using a very generic and easy to remember 30 days as the amount of time to wait, partly because 30 days is also the default validity time for RRSIG. If you decide to manage your own zone signing and record removing, you should wait at least the duration of your old record's TTL before attempting to removing it from the zone. It is probably better to err on the safe side and leave the old data in the zone a little longer.

Note

One of the worst things to happen during a rollover is to "orphan" old keys, by deleting it too soon from the zone. This will result in the world's recursive servers come asking "hey, do you have the key(s) for these older signatures?" and not get an answer to satisfy their needs. The recursive servers would have to fail the validation, and the users may think you zone has been compromised because the keys and signatures to match up. This is why it is a good idea to wait a period of time in-between each phase of the key rollover, to ensure that not only new information has propogated to the world, but also that old information that was previously published to the world have expired from whoever has been caching them. This is why in this document we have chosen a very conservative period of 30 days. If you have unusually long TTL or signature expirations, it may be wise to change the rollover schedule accordingly.

Emergency Key Rollovers

Keys are generally rolled at a regular schedule (that is, if you choose to roll them at all). But sometimes, you may have to rollover keys out-of-schedule due to a security incident. The aim of an emergency rollover is re-sign the zone with a new key as soon as possible, because when a key is suspected of being compromised, the malicious attacker (or anyone who has access to the key) could impersonate you, and trick other validating resolvers into believing that they are receiving authentic, validated answers.

During an emergency rollover, you would follow the same operational procedures as described in the section called “Rollover Recipes”, with the added task of reducing the TTL of current active (possibly compromised) DNSKEY RRset, in attempt to phase out the compromised key faster before the new key takes effect. The time frame should be significantly reduced from the 30-days-apart example, since you probably don't want to wait up to 60 days for the compromised key to be removed from your zone.

Another method is to always carry a spare key with you at all times. You could always have a second key (pre)published (and hopefully this one was not compromised the same time as the first key), so if the active key is compromised, you could save yourself some time to immediately activate the spare key, and all the validating resolvers should already have this spare key cached, thus saving you some time.

With KSK emergency rollover, you would have to also consider factors related to your parent zone, such as how quickly they can remove the old DS record and published the new ones.

As usual, there is a lot more to consider when it comes to emergency key rollovers. For more in-depth considerations, please check out RFC 7583 .

DNSKEY Algorithm Rollovers

From time to time new digital signature algorithms with improved security are introduced, and it may be desirable for administrators to roll over DNSKEYs to a new algorithm, e.g. from RSASHA1 (algorithm 5 or 7) to RSASHA256 (algorithm 8). The algorithm rollover must be done with care in a stepwise fashion to avoid breaking DNSSEC validation.

As with other DNSKEY rollovers, when the zone is of type master, an algorithm rollover can be accomplished using dynamic updates or automatic key rollovers. For zones of type slave, only automatic key rollovers are possible, but the dnssec-settime utility can be used to control the timing of such.

In any case the first step is to put DNSKEYs using the new algorithm in place. You must generate the K* files for the new algorithm and put them in the zone's key directory where named can access them. Take care to set appropriate ownership and permissions on the keys. If the auto-dnssec zone option is set to maintain, named will automatically sign the zone with the new keys based on their timing metadata when the dnssec-loadkeys-interval elapses or you issue the rndc loadkeys command. Otherwise for zones of type master, you can use nsupdate to add the new DNSKEYs to the zone. This will cause named to use them to sign the zone. For zones of type slave, e.g. on a bump-in-the-wire inline signing server, nsupdate cannot be used.

Once the zone has been signed by the new DNSKEYs, you must inform the parent zone and any trust anchor repositories of the new KSKs, e.g. you might place DS records in the parent zone through your DNS registrar's website.

Before starting to remove the old algorithm from a zone, you must allow the maximum TTL on its DS records in the parent zone to expire. This will assure that any subsequent queries will retrieve the new DS records for the new algorithm. After the TTL has expired, you can remove the DS records for the old algorithm from the parent zone and any trust anchor repositories. You must then allow another maximum TTL interval to elapse so that the old DS records disappear from all resolver caches.

The next step is to remove the DNSKEYs using the old algorithm from your zone. Again this can be accomplished using nsupdate to delete the old DNSKEYs (master zones only) or by automatic key rollover when auto-dnssec is set to maintain. You can cause the automatic key rollover to take place immediately by using the dnssec-settime utility to set the Delete date on all keys to any time in the past. (See dnssec-settime -D <date/offset> option.)

After adjusting the timing metadata, the rndc loadkeys command will cause named to remove the DNSKEYs and RRSIGs for the old algorithm from the zone. Note also that with the nsupdate method, removing the DNSKEYs also causes named to remove the associated RRSIGs automatically.

Once you have verified that the old DNSKEYs and RRSIGs have been removed from the zone, the final (optional) step is to remove the key files for the old algorithm from the key directory.