[Opendnssec-develop] v1.1 RC1
Stephen.Morris at nominet.org.uk
Stephen.Morris at nominet.org.uk
Wed Mar 31 12:45:01 UTC 2010
Matthijs Mekking <matthijs at NLnetLabs.nl> wrote on 31/03/2010 11:07:40:
> Rickard Bellgrim wrote:
> > * We are still struggling with dropped signatures during key rollover.
> Currently a key rollover is done this way:
> 1. K1[a] -> K1[ac], K2[p] -> K1[p], K2[a] -> K2[a]
> Where a is active and p is publish.
To avoid confusion, can I suggest that we use the term "retired" when a
key is replaced. The sequence then becomes:
1. K1[a] -> K1[a], K2[p] -> K1[r], K2[a] -> K2[a]
Where a is active, p is publish and r is retired.
When a key moves to the retired state, no new signatures are created with
it; it is only published in the zone to cope with RRSIGs created by it
that may still be in the zone file or in caches.
> 2. If such a change happens in the enforcer, the signer will be
> notified: ods-signer update <zone>
> 3. The signer will resign when there is a change in the key set.
> 4. Because the signer has no knowledge of key rollovers, it just follows
> orders that are given in the signconf file, it will drop all
> signatures when K1 transitions to published state. It will create all
> new signatures with K2, because it just became active.
The key timing draft (
this into account by stating that the old key needs to be retained in the
zone for a period of time equal to:
Dsgn + Dprp + TTLsig
Dsgn is the time taken to re-sign the zone, i.e. the interval between the
time the new key becomes active and the time that the last signature
created with the old key is replaced.
Dprp is the propagation delay, the time taken for any change to the zone
to reach all slave servers.
TTLsig is the TTL of the RRSIG record, the time taken for an RRSIG to
expire from a resolver cache.
In step 4 above, when a new key becomes active, the next run of the signer
drops all RRSIGs created by the old key and replaces them with RRSIGs
created with the new key. This is effectively setting Dsgn to 0; the old
key needs to be retained for as long as it takes for the new signatures to
reach all slave servers and then replace any cached signatures.
> I hear that there is a need between a smooth transition between step 2
> and 3 of the key rollover process. However, this requires a new state:
> 'publish, but pre-generate signatures with this key if there are no
> fresh signatures for current active keys, but don't publish those
> signatures yet'. This will replace the publish state in the above
The drawback of replacing signatures all at once is that if it is a large
zone with a lot of signatures, the time taken to re-sign the zone may
become significant. This can be overcome by creating the signatures over
a period of time. The obvious approach being to replace the signatures
only as they approach their expiry time. This fits in with the existing
algorithm: in this case, Dsgn (the time taken to re-sign the zone) is
non-zero, being equal to (signature validity period - refresh interval).
The penalty is that the second key, K2, is in the zone for longer than it
would otherwise be. However, implementation of this option may be simpler
than the option suggested above, i.e. generating (but not publishing)
signatures when the new key appears.
> When the old key becomes inactive (but still is post-published), I think
> we should drop all old signatures, regardless of the freshness of these
> signatures, as they should not be propagated anymore towards the caches.
If we can do this within time constraints, this is simpler still.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Opendnssec-develop