The short story: A KSK rollover on the OpenDNSSEC platform is easy and you should not be scared of it.
The longer story: A little over a year ago, we decided in the Go6lab to start learning DNSSEC by doing it, so we set up OpenDNSSEC for signing domains and followed this excellent deployment document, written for us by Matthijs Mekking. Our domains were signed and DS records published – both “normal” domains like zorz.si, go6.si,go6lab.si and also reverse domains, like 4.e.7.2.c.7.6.0.1.0.0.2.ip6.arpa , 96.239.91.in-addr.arpa and 97.239.91.in-addr.arpa. During the process we found some bugs in the software and in the document, and since then all of them have been fixed.
A year passed and we decided to do a KSK rollover for all signed domains, as it’s advisable for security reasons. To be honest, this was one of the steps in the whole DNSSEC signing process that worried us most, as it’s not a secret that some people mess up the process in this part of the DNSSEC maintenance sequence. Matthijs promised to write another deployment-oriented document for KSK rollovers – and one day in August the first document draft was in our mailbox.
After reading it, we sent some comments on what would be the bare minimum of information that needs to be added (or removed) to understand the process and what’s going on to the point that we can do a KSK rollover and not cause our domains to disappear from the Internet. We believe that the final version of the document is now exactly what you need to know, if you want to do the KSK rollover on OpenDNSSEC and not read more than three pages of documentation 🙂
So, what does the KSK rollover process look like? A misunderstanding of the documentation lead to a quick fix, so after the first domain all the others were done as described in the document mentioned above.
When you decide to do a KSK rollover, you check your keys in the OpenDNSSEC repository and if there are new KSK keys with status “ready”, you export them, get the DS (or DNSKEY) information, replace the DS set with the new one at the parent DNS and wait until you can see the new DS set being served from your parent DNS server. Of course, for .si zones we submitted the DS keys to our .si TLD and for reverse zones we changed the DS information in the RIPE domain database objects.
Not to panic – when your signing platform automatically creates a new KSK key, your domain will not “fall off the Internet” or become unreachable. The KSK key doesn’t expire and rollover is your administrative choice. If you decide to do nothing, the old key will stay there and still protect your domain. It’s good advice, though, to change the KSK key every year just to make sure that nobody can try to break your KSK key over a longer period of time.
OpenDNSSEC creates a new KSK key automatically for you a year after signing. When you see new information being active you issue the ds-seen command on your OpenDNSSEC platform and the system itself will take care of everything for you. When reading the more thorough documentation before I thought that those timers for removing the old KSK keys were exaggerated, but now I’m grateful that they are as they are!
All KSK rollovers went fine, and I was checking the availability and analyzing DNSSEC validity all the time throughout the rollover process with several tools available! You can analyze them too – here’s the example of one of my domains: zorz.si.
So, there is no reason for any concern or fear – KSK rollovers are really easy, once you do it once you’ll just repeat it every year with no questions asked!
A few thoughts arose during the process, though, mainly in terms of how to fully automate this KSK rollover process.
First of all, when OpenDNSSEC rolls over your KSK key and makes it available, we should have implemented and in use the CDS (CDNSKEY) mechanism of communicating our keys to our parent server. This mechanism is described in RFC 7344 and would help a lot in automating the KSK rollovers and making this part of the process less seem less complex and dangerous. We are already discussing this with some people and as soon as the first prototypes come out we’ll test them in our lab and report here.
Next is the DS-SEEN command. OpenDNSSEC knows DNS (as it has this in its name), so what are the impediments to make this part completely automatic? When you export your DS set and replace it at your parent DNS server (through whichever mechanism, CDS, EPP, …) you could instruct your OpenDNSSEC platform, “hey, I changed the DS keys at the parent, can you issue the DNS query every hour and when you see the new DS keys published by the parent server, start the DS-SEEN timers and retirement procedure of the old KSK key?” OpenDNSSEC have all the necessary information about where the parent is and the ability to issue simple DNS queries, compare the answer with its database, and decide when things are ready to proceed.
How hard can it be?
A KSK rollover could be completely automated and we were quite tempted to write a bunch of bash scripts that would do that, but the decision was that this needs to be solved at a system level and not by a bunch of home-brewed scripting tools.
Conclusion: A KSK rollover on OpenDNSSEC is easy and you should not be scared of it, just follow the instructions and don’t forget to analyze the DNSSEC validity during the process. Really.