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

[Berry A.W. van Halderen]

On 11/6/18 9:52 AM, list-opendnssec-user at jyborn.se wrote:
> On Mon, Nov 05, 2018 at 10:19:03PM +0100, Michael Grimm wrote:
>> On 5. Nov 2018, at 21:43, list-opendnssec-user at jyborn.se wrote:
>>> On Mon, Nov 05, 2018 at 07:44:58PM +0100, Michael Grimm wrote:
>>>> On 5. Nov 2018, at 15:45, list-opendnssec-user at jyborn.se wrote:
>>
>>>>> I'm wondering if P10Y is too long to be accepted, and
>>>>> because of that OpenDNSSEC somehow decided to default
>>>>> to the same Lifetime for KSK as for ZSK?
>>>>
>>>> Yes, 10 years should work. I do have the same settings regarding KSK:
>>
>> [snip]
>>
>>> $ 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. 
>>
>>> Do you see differing next transition dates for KSK and ZSK
>>> with that command?
>>
>> Try 'ods-enforcer rollover list'. Starting 2.x reporting of those date has changed in a way that is very irritating, indeed. I have learned to live with it, but I have to admit that the 1.x reporting has been much more intuitive IMHO
> 
> Great, ods-enforcer rollover list shows a KSK date ten years
> into the future, so now I'm at ease with my configuration.
> 

Haven't really tested 10Y, but there is no inherit limit, times
should all be measured in time_t.  The confusion comes from the
term "date of next transition",  which isn't the next transition
of the key (state), but of the entire key set. OpenDNSSEC will
determin the earliest time there could be a change, and plans to
inspect and possibly change the keys at that time.

So it is the entire key set, and it is the time it will try to
make a change, not necessarily make a visible change.

We had been working on a feature to predict (if no other changes are
made) when possible actions are taken.  Although a bit human digestible,
I would like to see a good administer tool to lay out a roll-over
schedule.
OpenDNSSEC 2.x has flexible approach to roll-over schedules, where 1.4
was way too limited.  There are however also situations where you want
to fixate a schedule, and stick with the dates of a transition (or
abort and make a new schedule).
How and when finish this functionality, I cannot give a time estimate
on, it is pending current development.

It is definitely true that the key list command isn't giving the
information we should.  Problem is that the basic key list command tries
to give compatible information as for 1.4, but (especially the "state")
there isn't really good mapping between 1.4 and 2.x.  IMO backwards
compatibility could have better been broken here, but there has not been
make a good implementation proposal.
We will probably replan features after next release, these are candidates.

Try the -d and/or -v options with the key list command to get
more in depth information, that the date of next transition won't be
different here.  It is basically a not very helpful piece of information
while rollover list will give you the info.
And the "key rollover list" indeed gives more useful information.

With kind regards,
\Berry