[Opendnssec-user] Is KSK Lifetime 10Y too long to be accepted in OpenDNSSEC 2.1.3?

[Roger Murray]

Hey All! 

Hope the information below sheds some light on the subject. 


> On 06 Nov 2018, at 05:48, Havard Eidnes <he at uninett.no> wrote:
> 
>>> That is almost exactly the same Keys config as I have
>>> in kasp.xml. Only differences are that my ZSK Lifetime
>>> is P90D and my ZSK Algorithm length is 1024.
>>> 
>>> The strange thing is that my KSK keys only have 90 days 
>>> until next transition from when they were created, as shown
>>> with this command (output somewhat edited):
>>> 
>>> $ ods-enforcer key list -v
>>> Keys:
>>> Zone:   Keytype: State:  Date of next transition: Size: Algorithm:
>>> xxx.se  KSK      active  2019-01-03 13:35:10      2048  8
>>> xxx.se  ZSK      active  2019-01-03 13:35:10      1024  8
>>> yyy.se  KSK      active  2019-01-03 14:38:48      2048  8
>>> yyy.se  ZSK      active  2019-01-03 14:38:48      1024  8
>> 
>> Sigh. That is very irritating, yes. That command shows the
>> comparable dates in my case as well.
> 
> Wow!  That's just Wrong.

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

————————————————— %< CUT ———————————————————————————————

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.

ODS developer: This artefact is a remnant of ODS 1.4. in ODS 2 a rollover is much
looser defined and it doesn't have the information in its database when
a transition will happen. Rather each time it runs it assesses the
situation and moves to a better state DNSSEC-wise.

ODS developer: Currently the value displayed there is just the time at which the zone
is re-evaluated and thus the same for all keys in the zone. I always
pondered if we could get the enforcer return a string which describes
what it expects to do next. Maybe I should make so time doing that...

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? 

ODS developer:  I'm afraid there isn't at the moment. But it happens that I'm working on
that just *now*. I've just finished a rather large project of better
compartmentalizing logic and database access.

————————————————— %<  CUT ————————————————————————————————————
> 
> Anyone care to defend this behaviour?

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.

Regards,
Roger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20181106/d6162887/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4156 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20181106/d6162887/attachment.bin>