Automatic DNSSEC Zone Signing Key rollover explained

Note that in later versions of BIND, a new feature, the Key and Signing Policy utility (KASP) improved automation of key rollovers.

BIND 9.7.0 introduced automatic in-server signature refreshing and automatic key rollover. This allows BIND, if provided with the DNSSEC private key files, to sign records as they are added to the zone, or as the signatures need to be refreshed. This refresh happens periodically to spread out the load on the server and to even out zone transfer load.

From BIND 9.7.2 (and all current production versions of BIND 9.7 and newer), when a new Zone Signing Key (ZSK) is being rolled to, BIND will manage a gradual transition of signatures from the old key to the new key.

Description of Key Timers

Before we dig too deeply into how a gradual key roll may occur, we need to describe the internal state BIND 9 maintains for a particular key. This is a description of how a Zone Signing Key (ZSK) is tracked within BIND 9.7. A similar method is used for Key Signing Keys but is not documented here.

In BIND 9.6, external tools were used to re-sign the zone, namely dnssec-signzone. The keys were managed externally to the server process, usually manually. Key management was performed by controlling which private keys the command line tool had access to when signing was performed. In BIND 9.7, management of keys has been moved into the server.

A ZSK changes states using defined points in time. These states are: Created, Publish, Activate, Inactive, and Delete. The private key file itself maintains these timers and they are set upon key creation or through a command line tool. Once specified, these timers trigger the necessary state changes. The key states are used by the server for key selection when signing and for determining which keys should be included in the zone's DNSKEY record set.

In Figure 1, the arrows represent events (blue) or times (yellow) when the key state changes. Between these events or times, the periods we are most concerned with inside BIND 9 are marked with the letters A, B, C, and D.

• A: The key is created and on disk, but not yet included in the zone file and not used to sign any records. Keys can be pre-created as early as desired.
• B: The key is published in the zone, but is not yet used to sign any records. The new key must be pre-published for at least as long as the TTL of the DNSKEY record plus any master-to-secondary transfer delays.
• C: The key is published in the zone, and is active for use in signing records. How long a key is used is a local policy decision. Recommendations range from rolling very frequently to five years (e.g. the nominal root zone KSK roll period) or more. Each has its merits, and they are not discussed here.
• D: The key is published in the zone, but is inactive and is no longer used to sign any records. How long a key remains in this state is dependent both on when it was last used and the TTL values in the zone.
• The last state (not shown in the figure) is removed. A key in this state is no longer used by BIND in any way. This state is terminal.

Section D is somewhat interesting because it has two components. At some point during this interval, BIND will remove all signatures made with this key as signatures are refreshed over time. This is the first part of this box. The second part of box D represents the maximum TTL value in use in the zone. The key cannot be removed from the zone until all records signed with this key have expired from caches. This is based on zone contents and is unchanged between server versions.

ZSK Rolling

Figure 2 depicts a typical series of ZSK rolls. Exactly one ZSK is active at all times. This is the form of key rolling that is expected to be used in production as it puts the least strain on resources by not having more than one signature on a particular record.

The rolling period dnssec-signzone uses is described by R. This is directly related to the zone's signature validity period. If signatures last 30 days, they must be refreshed before that 30 days have passed or they will become stale, and the zone will fail to validate. This typically happens sooner than strictly necessary, but it must occur (using 30 days as an example) at least (30 days - MaxTTL) to avoid problems.

When a ZSK becomes Inactive, the key would no longer be used to sign records. The new key would be used for all signatures, and this transition happens gradually as signatures are refreshed; if a key is Inactive, it does not mean no signatures exist for this key, only that no new ones will be created using this key.

Automatic re-signing behaviors during key rolling

In Figure 2, one key stops signing records at the exact moment another key begins signing. This is what is expected to be done with ZSKs in practice, as it eliminates the overhead of calculating, storing, and transmitting additional signatures.

Nothing currently in BIND disallows overlapping active regions. A record may be signed many times by many keys, and the overhead may be necessary at times for particular types of key rolling. However, it is critical that while active regions may overlap, they must never be disjoint. If at any time there is a gap between keys, BIND 9 cannot correctly maintain the zone and the zone will appear broken to validating resolvers.

Signatures will transition from old key to new key as the records' re-signing timers expire. Additionally, a key will not be removed from the zone until BIND 9 knows that all signatures using that key are removed from the zone and it is safe (based on TTL) to remove that key.

It is important that keys have sane timer values set or the zone may become broken when rolling to a new ZSK. BIND 9 may need to alter the administrator-supplied values for pre- and post-use publish in order to ensure the zone does not break. It may also be necessary for some keys to be used past their end date. An example of this would be if a key is added but no following key is provided. Rather than break the zone, the older key may continue to be used, with sufficient notification in the log files to indicate this is happening.

During the key rollover period there will be a difference in zone size as a result of the DNSKEY record set being larger for a longer period of time.