[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
we
> 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
means
> we have no state to describe "waiting for DS seen". Ideally I would add
new
> 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
schema
> changing option? (Note that we already need to update the database with
the
> 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