DNSSEC KSK Key Rollover

Probably the most crucial part in a DNSSEC environment is the maintenance of the key-signing key, the KSK. You should rollover this key on a regular basis, though not that often as the zone signing keys, the ZSKs. I am doing a KSK rollover every 2 years.

In the following I will describe the two existing methods for a KSK rollover along with a step-by-step guide how I performed such a rollover for my zone “weberdns.de”. Of course again with many graphics from DNSViz (with “redundant edges”) that easily reveal the keys and signatures at a glance.

Note that this blogpost is NOT about the Root Zone KSK Rollover that appears in 2017/2018. It is merely about your OWN zone that is secured via DNSSEC.

This blogpost is part of a series about DNSSEC. Refer to this list for all articles.

Generally keep in mind that as long as a single chain-of-trust is authentic, you won’t have any problems. Hence: Unless you’re deleting a DNSKEY or a DS record, you must not be afraid. You can add KSKs (DNSKEY 257) and DS records without the fear of loosing your secured zone. However, be carefully in talking to your registrars since at some point they must replace/delete the correct DS record pointing to your KSK. For official details about key rollovers in general, or especially for key signing key rollovers, refer to RFC 6781, section 4.1.2, Key Signing Key Rollovers.

Again: It’s all about Timing!

The RFC mentiones two approaches for the KSK rollover. The first one is called “Double-Signature KSK Rollover“. While the child domain has the new KSK along with the old KSK present in the zone in parallel (hence the name: double-signature since both KSKs sign the ZSK), the parent zone replaces the old DS with the new DS record at a time. The old KSK must not be deleted before the TTL of the old DS record times out:


The other approach is called “Double-DS KSK Rollover“. Here the parent zone has both DS records in parallel (hence the name) while the child replaces the old KSK with the new one at a time, just after the new DS record is propageted in the global DNS. The old DS record can be removed after the TTL of the old KSK times out:


While the ZSK rollover, refer to this blogpost, relies on the four different dates a DNSKEY stores (publish, activate, inactive, delete), a KSK rollover only needs active and delete. That is: publish/activate can be at the same time, while inactive/delete can be at the same time as well.

Time …” by Martin Gommel is licensed under CC BY-NC-ND 2.0

For my KSK rollover I decided to use the first variant (double-signature) in which I have two KSKs in my zone while replacing the DS record at the parent zone. However, I did not fully follow “Figure 4” within this RFC section 4.1.2 since during a short period both DS records were present at my parents zone. That is: two DS records pointing to two KSKs. However, though not needed this was no problem for a valid chain-of-trust.

0) Initial

My initial situation: only one DS RR and one KSK (id: 63202). Querying the “dnskey” for my weberdns.de zone revealed exactly this single KSK (DNSKEY type 257) and a single ZSK (DNSKEY type 256) as well:

Same for the DS record (only a single one) at the parent zone:


1) Generating a new KSK

I generated a new KSK as always, corrected the ownership to be readable by BIND, and did a reload:

Immediately after that both KSKs were present in my zone. The new KSK had id 3880:

Note that at this time the three DNSKEY RRs are signed by all of the three keys (2x KSK, 1x ZSK) which might look a bit strange:

DNSViz (with many redundant edges at this time):

2) New DS in Parent Zone

Now I sent my new DS record to my parent zone which did not replace the old DS but added it. Hence there were two DS records in the zone. Note that this step is NOT NEEDED and I just wanted to test it. You MUST NOT have both KSKs and both DS RR active while using one of the KSK rollover schemes.

A whois weberdns.de looked like that:

And a query of the DS record(s) like that:


Haha, and just to mix up more keys: Since my scheduled ZSK (not KSK) rollover took place in the meantime, I had two ZSKs in the zone as well (ids: 32058, 54816), which gave 4x DNSKEYs along with 3x RRSIGs. You can see this in the DNSViz graph above as well. ;)


After some time I told my parent zone to remove the old DS record which is the actual “DS change” event. That is: The new and only DS record pointed to the new KSK, while the old KSK was still present in the zone. DNSViz:

Now I had to wait for the TTL of the old DS record to time out.

3) Deleting the old KSK

Just for fun I did not only set the delete date but scheduled it after one day of inactivity. Note again that this is NOT NEEDED. You can simply set both dates at one time.

Followed by a sudo rndc loadkeys weberdns.de.

During this one day of “inactive” I had both KSKs in my zone, while only the new KSK (along with the ZSK) signed the RRSIG:


And, as expected, after the “delete” date the old KSK was completely gone. That is: During several steps in the last days/weeks the chain of trust was always valid, while at the end a single and new DS record pointed to the single and new KSK at my zone. So for the last time today, the DNSViz graph:

Featured image “Roll” by Quinn Dombrowski is licensed under CC BY-SA 2.0.

Leave a Reply

Your email address will not be published. Required fields are marked *