Over the next couple of days we are going to post a step-by-step guide on how we achieved this, starting today with the motivation for our migration and, in a separate post, the goals we set ourselves during the migration and the assumptions we have made. At the end of the series we will post an integral document that you can use if you want to perform a similar migration.
Motivation
In 2010 SURFnet deployed automated DNSSEC signing in its “SURFdomeinen” managed DNS service. One of the design decisions that we made during the implementation of DNSSEC in this service was to use “shared keys” (i.e. sharing the same set of cryptographic keys for multiple DNS zones, instead of using separate keys for each individual zone).
There were two reasons for this. First, the HSMs that we selected for secure key storage only support storing a limited number of objects. Secondly, we saw this as a way to simplify key management by only using one set of keys per user (in our case connected institutions such as a university or teaching hospital). Another decision that we made early on was to use OpenDNSSEC as software suite for our deployment.
Using shared keys has a number of drawbacks:
- It is harder to migrate zones to a different DNS operator due to the fact that this requires stopping key rollover for the zone; in the case of shared keys this affects all zones that share a key set
- The state of a zone cannot develop independently; the zone with the highest overall TTL determines the speed at which key rollovers can proceed and adding a zone with a higher overall TTL may pose a problem
- Using shared keys creates an artificial tie between zones that are otherwise independent of one another
- KSK rollover is problematic for the case where a large number of zones shares one key set because of the number of parent interactions and possibly because of differing policies on the parent side when different top-level domain registries are involved
- Synchronised key rollover as is the case with shared keys may impose additional load on the infrastructure because caches will be sending more requests for all zones for which the keys are rolled
On top of that, the OpenDNSSEC version that we are currently using (version 1.1) does not have optimal support for shared keys.
For this reason, we have decided to upgrade our HSMs to a version that supports storage of a much larger number of keys and to simultaneously migrate away from using shared keys. To do this in one go, we are going to migrate to new signers systems that are also running a newer version of OpenDNSSEC (version 1.3). Effectively, this means that we are performing a signer migration or signer rollover.
You can download the DNSSEC signer migration document (pdf). Please note, this document dates from 2012 and will not be updated
0 Praat mee