<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hey All! <div class=""><br class=""></div><div class="">Hope the information below sheds some light on the subject. </div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 06 Nov 2018, at 05:48, Havard Eidnes <<a href="mailto:he@uninett.no" class="">he@uninett.no</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">That is almost exactly the same Keys config as I have<br class="">in kasp.xml. Only differences are that my ZSK Lifetime<br class="">is P90D and my ZSK Algorithm length is 1024.<br class=""><br class="">The strange thing is that my KSK keys only have 90 days <br class="">until next transition from when they were created, as shown<br class="">with this command (output somewhat edited):<br class=""><br class="">$ ods-enforcer key list -v<br class="">Keys:<br class="">Zone:   Keytype: State:  Date of next transition: Size: Algorithm:<br class=""><a href="http://xxx.se" class="">xxx.se</a>  KSK      active  2019-01-03 13:35:10      2048  8<br class=""><a href="http://xxx.se" class="">xxx.se</a>  ZSK      active  2019-01-03 13:35:10      1024  8<br class=""><a href="http://yyy.se" class="">yyy.se</a>  KSK      active  2019-01-03 14:38:48      2048  8<br class=""><a href="http://yyy.se" class="">yyy.se</a>  ZSK      active  2019-01-03 14:38:48      1024  8<br class=""></blockquote><br class="">Sigh. That is very irritating, yes. That command shows the<br class="">comparable dates in my case as well.<br class=""></blockquote><br class="">Wow!  That's just Wrong.<br class=""></div></blockquote><div><br class=""></div><div>It is my understanding that it is the Label “Date of next transition” that is the problem. It is in effect when OpenDNSSEC will re-evaluate the zone, not when it will actually do something. It might do something, it might not. We had a conversation with the OpenDNSSEC developers when we were moving to OpenDNSSEC 2.x last year</div><div><br class=""></div><div>————————————————— %< CUT ———————————————————————————————</div><div><div><br class=""></div><div>IIS: One of the things that puzzles me is that although all the values (inception, lifetime etc) seems to be in order in the kasp database, when I run ods-enforcer key list -v the time for next transition is the same for all keys. Also it's really close in time (15 minutes or so), when it should be weeks or years away, and no clue is gives as to what the transition is to (which ODS 1.4 stated). After reaching that point in time, the date and time for next transition changes to early November. Nothing else seemed to happen to keys and signatures from what I could tell and the date/time was still the same for all keys.</div><div><br class=""></div><div>ODS developer: This artefact is a remnant of ODS 1.4. in ODS 2 a rollover is much</div><div>looser defined and it doesn't have the information in its database when</div><div>a transition will happen. Rather each time it runs it assesses the</div><div>situation and moves to a better state DNSSEC-wise.</div><div><br class=""></div><div>ODS developer: Currently the value displayed there is just the time at which the zone</div><div>is re-evaluated and thus the same for all keys in the zone. I always</div><div>pondered if we could get the enforcer return a string which describes</div><div>what it expects to do next. Maybe I should make so time doing that...</div><div><br class=""></div><div>IIS: Is there a way to tell what ODS is doing? I guess it changes some state, but how do you tell which, where it's at and where it's going? </div><div><br class=""></div><div>ODS developer:  I'm afraid there isn't at the moment. But it happens that I'm working on</div><div>that just *now*. I've just finished a rather large project of better</div><div>compartmentalizing logic and database access.</div></div><div><br class=""></div><div><div>————————————————— %<  CUT ————————————————————————————————————</div><div></div></div><blockquote type="cite" class=""><br class="">Anyone care to defend this behaviour?<br class=""></blockquote><div><br class=""></div>No, not me. This behaviour is really annoying and makes Key Rollover timing more difficult. It would be really great if OpenDNSSEC would prioritise this issue. I can recommend testing a lot. It really helps get a handle on when OpenDNSSEC is going to do what.</div><div><br class=""></div><div>Regards,</div><div>Roger</div></div><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div></div></div></div></body></html>