DNSSEC KSK Key Rollover

DNS/DNSSEC, Security, Tutorial/Howto, , , , , , , , , ,

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:

DNSViz:

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:

DNSViz:

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:

DNSViz:

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.

9 thoughts on “DNSSEC KSK Key Rollover”

  1. Are there interactions with ZSK and KSK rollover that one should be aware of? For example, if one were to decide to roll each once a year, could it be done at the same time?

    Reply

    1. Hi Earl.

      I am not aware of any specific problems if rolling over both keys at the same time. However, I would not recommend it though. Just a feeling. Keep it simple. (Since DNSSEC with its keys is already complicated enough.)

      If you want to roll over both keys once a year at the same time (that is: if you do NOT rollover your ZSK more often), you can use a single (!) key for both. That is: your parent zone points to this single key which directly signs the zone rather than the ZSK. Google for it. There are some tutorials out there.
      Otherwise I am recommending to rollover the ZSK more often (e.g., 3-4x a year) and the KSK less often (e.g., every 2-3 years).

      Cheers.

      Reply

  2. I’m puzzled.
    Can’t you let rfc5011 take care of updating the keys at your registry?

    Reply

    1. Hey MP.

      No, RFC 5011 is about *resolvers* that must update their trust anchors for each DNS tree (“islands of signed name spaces”). This would be the case if you have different islands of DNS trusts on your network. For the Intenet we currently have only one trust point, the root “.”. And yes, there was a KSK rollover on the Internet happening during 2017/2018 but I am not quite sure whether this RFC was helping the resolvers to do this.

      However, my blogpost here is about a KSK rollover of your *own zone* on an authoritative name server. In this case you must submit the new KSK/DS to your parent zone. I am not aware of any widely deployed mechanism that simplifies this quite manual process.

      Cheers, Johannes

      Reply

  3. Hi,

    In your double-signature drawing: https://weberblog.net/wp-content/uploads/2018/02/Grafik-Timeline-KSK-Key-Rollover-Double-Signature.png
    You are stating that there is no wait needed, between the introduction of the new KSK and double signature and swapping the old DS for the new DS in the parent.

    I think this is wrong as you do have to wait TTL KSK + propagation time before you may swap the DS in the parent. This to ensure all resolvers have the double signature in cache.

    If you swap the DS in the parent too early, then it could happen that there are still resolvers only knowing about the old KSK RRSIG in cache, while having fetched the new DS RRSET and so breaking their chain of trust.

    Reply

    1. Hey SvenVD,

      thanks for your comment. To be honest I am not 100 % sure at the moment. I am referring to https://tools.ietf.org/html/rfc6781#section-4.1.2 that states the following:

      new DNSKEY: During the “new DNSKEY” phase, the zone administrator
      generates a second KSK, DNSKEY_K_2. The key is provided to the
      parent, and the child will have to wait until a new DS RR has been
      generated that points to DNSKEY_K_2. After that DS RR has been
      published on all servers authoritative for the parent’s zone, the
      zone administrator has to wait at least TTL_DS to make sure that
      the old DS RR has expired from caches.

      My understanding is, that the only wait is *after* the new DS RR has been generated/published.

      Your scenario, however, sounds valid. Ugh. It’s not that easy to test it explicitly. (I have tried to test some other wierd scenarios, but did not succeed as well: https://weberblog.net/signed-dns-zone-with-too-long-living-ttls/) At least I was able to test an emergency KSK rollover which did not make any problems: https://weberblog.net/dnssec-ksk-emergency-rollover/

      Anyway, I would completely agree that you SHOULD wait for any TTLs to expire before doing the next step. This ensure that you’re not running into these kind of problems.

      Cu,
      Johannes

      Reply

    2. Hey SvenVD again,

      I had a little discussion on Twitter (https://twitter.com/webernetz/status/1053677060324052992) and it turned out, that your concern is valid! You MUST wait TTL_KSK before you’re changing the DS record at the parent zone!
      There is an errata to RFC 6781 that corrects exactly my quoted sentence: https://www.rfc-editor.org/errata/eid4844
      And for an even more detailed timing overview you can have a look at RFC 7583: https://tools.ietf.org/html/rfc7583#section-3.3.1

      I’ll update my graphic immediately. Thanks for your note!
      Johannes

      Reply

Leave a Reply

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