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:
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 .
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:
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”
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.
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:
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”.
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.
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.
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:
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
| Metadata | Included in Zone File? | Used to Sign Data? | Purpose |
|---|---|---|---|
| Publish | Yes | No | Introducing a key soon to be active |
| Activate | Yes | Yes | Activation date for new key |
| Revoke | Yes | Yes | Notifying a key soon to be retired |
| Inactive | Yes | No | Inactivate or retire a key |
| Delete | No | No | Deletion or removal of key from zone |
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.keyVerifying 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.
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.
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.
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 .
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.
Gab
Twitter