Hi, What do you have set as the run interval of the enforcer? (This is set in kasp.xml) The run interval needs to be short compared to your other timers or else you will get interactions between them.
Another way this sort of issue can be caused is having a key lifetime that is short compared to other timers; this makes it tricky to publish keys long enough in advance so that they are ready to take over. The other possibility is that the enforcer didn't run for some time and is now catching up; check your logs for any messages that may indicate issues. As you say, the ZSK listed in the middle will remain active until the published key is ready to take over; extending its lifetime. Sion On 16/05/14 11:00, Javier Jiménez Huedo wrote: > Thanks Sion, > > The information was very useful for my ;-) > > However, something strange is happening with the rollover times: > > > KSK active 2014-05-20 17:05:53 (retire) > KSK publish 2014-05-19 10:47:20 (ready) > > ZSK retire 2014-05-18 16:02:20 (dead) > ZSK active 2014-05-16 11:18:26 (retire) > ZSK publish 2014-05-18 19:14:46 (ready) > > > ZSK active key goes to "retire" status before the new ZSK key changes > to "ready" status… > > Something similar happens with the KSK key. > > I think the current active key must continue as "active" till the next > key can be "ready" ... Is that correct? > > Why these inconsistencies appear? > > I tried that new keys to be published several days before the rollover > takes place. The only way (I have found) to achieve that is by > modifying "PropagationDelay" parameter of the "zone" section for the > ZSK and the "Parent" for the KSK key. > > Is it correct? Does exists any other way to do that? > > Thank you very much > > > 2014-05-14 14:57 GMT+02:00 Sion Lloyd <[email protected] > <mailto:[email protected]>>: > > To paraphrase the key timings draft: > > * A key in the "publish" state moves into the "ready" state > when it has > * been published for at least: > * > * Ipc = TTLkeyc + Dpc +Sp > * > * ... where: > * > * TTLkeyc = TTL of the ZSK DNSKEY record > * Dpc = Propagation delay > * Sp = Publish Safety Margin > * > > OpenDNSSEC will attempt to publish a key at least this far ahead > of the previous ZSK's retire time. It is slightly complicated by > the run interval of the enforcer, so might be a bit earlier. > > Generation may be as required (i.e. it will be generated and > published at the same time) or you may generate a whole batch of > keys ahead of schedule. > > Sion > > ------------------------------------------------------------------------ > *From:* [email protected] > <mailto:[email protected]> > [[email protected] > <mailto:[email protected]>] on behalf > of Javier Jiménez Huedo [[email protected] <mailto:[email protected]>] > *Sent:* 13 May 2014 13:18 > *To:* [email protected] > <mailto:[email protected]> > *Subject:* [Opendnssec-user] How to calc new ZSK / KSK and > pre-publish date > > Dear OpenDNSSEC users, > > I am confused about the following behavior of openDNSSEC: > > I have the following ZSK active key: > > Key type State: Next transition: > ZSK active 2014-05-19 16:02:20 (retire) > > KSK Lifetime P20D > ZSK LifeTime P10D > > > How I can calculate the date of generation of the next ZSK key? > How I can calculate the date of pre-publication next ZSK key? > > Kasp.xml: > > <Signatures> > <Resign>PT5H</Resign> > <Refresh>P2D</Refresh> > <Validity> > <Default>P5D</Default> > <Denial>P5D</Denial> > </Validity> > <InceptionOffset>PT3600S</InceptionOffset> > ... > <Signatures> > > > <keys> > <TTL>PT3600S</TTL> > <PublishSafety>PT1H</PublishSafety> > ... > </keys> > <Zone> > <PropagationDelay>PT30S</PropagationDelay> > ... > </zone> > <parent> > <PropagationDelay>PT5H</PropagationDelay> > <DS><TTL>P1D</TTL></DS> > <SOA><TTL>P1D</TTL> <Minimum>P1D</Minimum></SOA> > </parent> > >
_______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
