[Opendnssec-develop] KSK rollover

sion at nominet.org.uk sion at nominet.org.uk
Thu Feb 25 11:03:14 UTC 2010

> I'm trying to implement the DoubleDNSKEY scheme without changing the
> database. Here is a summary of how the scheme works
> IpubC == publication interval in child
> IpubP == publication interval in parent
> DoubleDNSKEY
> 1. pre-publish key (IpubC + IpubP) before retirement (double safety
> margin?)
>  new key in zone, used to sign
> 2. after IpubC prompt for DS to be submitted
> 3. wait for ds-seen to be issued
> 4. IpubP after (3) the rollover can occur (either manual or automatic)
>  old key in zone, not used
> 5. retired key can move to dead
>  old key removed
> I think that 4 and 5 occur at the same time... anyway; the issue is that
> have to wait after publication before we can submit the DS record, but we
> also have to wait after the DS is seen before we can safely roll the key.
> Currently, the key would go from published to ready at step 2, which
> we have no state to describe "waiting for DS seen". Ideally I would add
> columns "DS-PUBLISHED" and "DS-READY" or similar... Of course this breaks
> backwards compatibility.
> One alternative is to move the key into a new state of DS_PUBLISHED when
> the DS is seen and reuse the PUBLISHED timestamp, then DS_READY using the
> READY timestamp... The problem with this is that we lose information.
> The question is, do people prefer the slightly kludgy option or the
> changing option? (Note that we already need to update the database with
> RolloverScheme policy parameter, the difference there is that if that
> update is not run we can still operate, just with the default scheme.)

One further complication... Should we allow different DS_PUBLISHED and
DS_READY times for different zones sharing keys? Currently all times are
stored against the key, rather than the zones instance of a key. (I.e. in
the keypairs table, not the dnsseckeys table for those familiar with the
kasp schema.)

This would have implications for all subsequent events like rollovers...
Sounds like a new story to me.

More information about the Opendnssec-develop mailing list