Knowledge Base ISC Main Website Ask a Question/Contact ISC
Automatic DNSSEC Zone Signing Key rollover explained
Author: Michael Graff Reference Number: AA-00822 Views: 2976 Created: 2012-10-26 15:19 Last Updated: 2015-09-17 14:53 0 Rating/ Voters

This article is derived from a Blog post on our website that introduced the 9.7.2 changes in automatic in-server key rollover.

BIND 9.7.0 introduced automatic in-server signature re-freshing 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 to the new key.

Description of Key Timers

Before we can dig too deeply in how a gradual key roll may occur, I need to describe the internal state BIND 9 maintains on 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, Published, Active, Inactive, and Removed. 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 which to include in the zone DNSKEY record set.

Figure 1: ZSK Timer Relationships

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 on 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 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. It 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 describes what is a typical ZSK roll. 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.

Figure 2: ZSK Transitions

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 happens as signatures are refreshed.  This does not mean no signatures exist for this key, only that no new ones will be created using that key.

Automatic re-signing behaviours 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 minimizes all overhead of storing and transmitting two 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 timer expires. 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 the 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 short-term difference in zone size as a result of the DNSKEY record set being larger for a longer period of time.

© 2001-2017 Internet Systems Consortium

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Feedback 4
  • #
    [David Cashion]: Broken link 2013-07-23 15:33

    The link this article points to is broken:

  • #
    [Cathy Almond]: Re: Broken link 2013-08-12 12:47

    Hi David - thanks for pointing this out - the link is now fixed.

  • #
    [David Cashion]: Figures do not show up anymore 2013-07-23 15:32

    Appears the figures do not show up?

  • #
    [Cathy Almond]: Re: Figures do not show up anymore 2013-08-12 12:20

    Thanks for bringing this to our attention. The links to the figures were lost during the recent upgrade of our website. I've re-added them temporarily by uploading smaller-resolution image files. I'll provide better-resolution versions as soon as I have the originals.

Quick Jump Menu