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
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.
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.
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
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.