DNSSEC Key Rollovers Explained

In an earlier post I explained the idea of DNSSEC how to generate keys and sign your DNS zone. In this post I will walk you through the rollover methods as described in RFC 6781. You should understand the rollover process so that you can securely run your zone. This way you can  replace the key in a secure manner when necessary, without service interruptions.

In the earlier post I explained that there are two sets of keys for most DNSSEC signed zones, a Key Signing Key (KSK) and a Zone Signing Key (ZSK). The ZSK is used most often, and should be replaced about yearly, and is also the easiest to replace. Once that process is explained, it is easier to understand how to rollover a KSK also.

Zone Signing Key Rollover

There are two methods for doing a ZSK rollover: a Pre-Publishing method, where the DNSKEY record is already announced, and a Double Signature method, where the zone is signed using both keys temporarily. For the first  method the key must be announced early, and may thus be vulnerable to analysis already, but the zone is always kept small. The latter method means that your zone doubles in size temporarily, and the new key can be generated when you want to do the rollover. Both achieve the same effect, and you can pick the one you like most.

The practical implementation of these methods is left as an exercise to the reader. No, it is not very hard, and yes, you can use ldns-signzone with three key names.

Pre-Publishing Key Rollover

In this case the new key is already generated and the DNSKEY record is announced to the world. Once you are sure that this record has reached everywhere, you can switch over to the new key and generate signatures with the new key. You should keep the old DNSKEY record so as not to invalidate cached results. Once all the old caches have expired, you can remove the old DNSKEY record.

1. Initial situation. Sign with KSK0 and ZSK0.
2. Announce new key (ZSK1) with DNSKEY record. Sign with KSK0 and ZSK0.
3. Rollover to ZSK1, keep ZSK0 DNSKEY record. Sign with KSK0 and ZSK1. (After Key TTL value of step 1)
4. Remove ZSK0 DNSKEY record. Sign with KSK0 and ZSK1. (After max TTL value of step 1)

If desired, you can introduce the future ZSK (ZSK2) DNSKEY record already in step 3 to simplify a future rollover process. Note that you do not need the private key material of ZSK2 to do this and you can store this offline.

Double Signature Key Rollover

With the Double Signature rollover, the new key is generated at the moment it is required. To make sure that the results stay valid, the results are signed with two signatures temporarily. Once all the old results have expired, the old key is removed, and only the new signatures remain.

1. Initial situation. Sign with KSK0 and ZSK0.
2. Announce new key (ZSK1) with DNSKEY record. Sign with KSK0, ZSK0 and ZSK1.
3. Remove ZSK0 DNSKEY record. Sign with KSK0 and ZSK1. (After max TTL value of step 1)

This process requires one less step, and less preparation, but does mean that your zone doubles in size. This may not be a problem for smaller zones.

Key Signing Key Rollover

The procedures for the Key Signing Key are similar to the above. The difference is that another party must be involved in this process, i.e. the registrar. The process you can use depends on the support and the speed of your registrar. Note that in this case the double-signature method only gives a couple of extra records, so the size consideration does not apply here. Because of the extra time delays by involving the registrar, this process should be planned more carefully.

Algorithm Rollovers

The above only allows you to do key rollovers while sticking to the same algorithm set. If you want to change your signing algorithm (e.g. SHA1 to SHA256), a more complicated process is required, and I suggest you read RFC 6781. The same applies for changing from NSEC to NSEC3.

Recommendations

The RFC recommends to keep a set of stand-by keys, using the pre-publishing method. These keys should be kept  a secure, separate location. This way you can always quickly recover from a disaster should your primary server fail or become compromised. It is also wise to backup your current keys, so you can recover even quicker if your server only fails.