Signer migration: our goals and assumptions

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

Introduction

As mentioned in the previous post, we will be publishing a series of articles on signer migration. In this article, we will address the goals we set ourselves for the signer migration as well as outline the assumptions we made. We’ll end the article with a brief explanation of the diagrams we will be using to illustrate the steps in the migration process.

Terminology

In the articles on the migration process we will talk about two systems:

  • The source signer – by this we mean the system that is currently responsible for serving out a signed version of the zone that will be migrated
  • The destination signer – by this we mean the system that will be serving out the signed version of the zone to be migrated after the migration completes

Goals

We set ourselves the following goals for the migration process:

  • The DNSKEY RRset may only consist of keys that are active on one or both signers
  • Manual zone editing shall be kept to a minimum
  • The migration must take place as quickly as possible

Assumptions

At the start of this process, the following conditions are assumed to be true:

  • There is no KSK rollover in progress on the source signer
  • The validity of the signatures is significantly longer than the maximum TTL in the zone that is to be migrated (at least 4 times as long)
  • Source and destination signer function as a hidden primary (i.e. are not authoritative name servers that are part of the NS-set for the domain); consequently, no change to the NS-set for any signed domains is required to facilitate the migration
  • There is a means to switch signers (e.g. reconfiguring the public primary name server to source the zone data from a different signer)
  • Key management and zone signing are separate processes (as is for instance the case when using OpenDNSSEC)
  • A split-key policy is used (i.e. with separate ZSK and KSK)
  • The parent zone allows a single DS for a secure delegation

Notation

Each step is illustrated using a diagram. For these diagrams, we have used consistent arrow types and colour coding:

  • Blue indicates (part of) the chain of trust that uses the active key set on the source signer
  • Red indicates (part of) the chain of trust that uses the active key set on the destination signer
  • Grey indicates (part of) a chain of trust that is no longer used or published
  • An arrow indicates a validation based on the object at the origin of the arrow for the object that the arrow points to (in most cases this implies a signature)
  • A dashed line in an arrow indicates that this relationship may exist but does not necessarily have to exist
  • “Self-references” (i.e. KSK signatures over the KSK) are omitted for reasons of clarity

To further clarify the diagrams independent of the colour coding we have included subscripts for each object. The following subscripts are used:

  • src – indicates that this object belongs to or originates from the source signer
  • dst – indicates that this object belongs to or originates from the destination signer
  • old – indicates that this object is an old key that is no longer actively being used to sign data
  • act – indicates that this object is a key that is actively being used to sign data
  • pre – indicates that this object is a key that is being pre-published and may be the next in line for a key rollover

Finally, we always show the situation on both the source as well as the destination signer. The signer that is authoritatively serving the zone has thicker lines and a bold heading at the top of the diagram. To illustrate what these diagrams look like, we have included an example from later in the series below.

1 Comment to “Signer migration: our goals and assumptions”

  1. Matthijs Mekking says:

    It is not clear to me if the assumption:

    * The parent zone allows a single DS for a secure delegation

    excludes the possibility to have multiple DS records at the parent per delegation. If so, it should probably make it explicit: The parent zone allows _only_ a single DS for a secure delegation. If no, a signer migration might benefit from a Double DS rollover strategy.

    Looking forward to read the next parts of your signer migration.