On 11/6/18 9:52 AM, [email protected] wrote: > On Mon, Nov 05, 2018 at 10:19:03PM +0100, Michael Grimm wrote: >> On 5. Nov 2018, at 21:43, [email protected] wrote: >>> On Mon, Nov 05, 2018 at 07:44:58PM +0100, Michael Grimm wrote: >>>> On 5. Nov 2018, at 15:45, [email protected] 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 _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
