Signer migration: a step-by-step guide (introduction)

Written by Roland van Rijswijk in category: Architecture, Procedures, Technical

One of our goals with this blog has been to share what we have learned from our DNSSEC deployment with our constituency and the wider Internet community. Last month we performed a complicated operation on our DNSSEC signer deployment: we migrated from the existing signer setup to a completely independently running new signer. We had prepared this migration beforehand and the migration was a big success; all our signed domains were migrated safely while remaining secure.

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.


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.

Links to the articles

Click on one of the links below to jump straight to the article

Comments are closed