[Opendnssec-user] rollover started automatically when ManualRollover set

Emil Natan shlyoko at gmail.com
Mon Jul 24 11:56:32 UTC 2017


Hi Hoda,

Unfortunately that does not help either (tried).
And this is what the manual says about purge:
If <Purge> is present, keys marked as dead will be automatically purged
from the database after this interval.

In my case the key is state retire and is not affected by Purge.

Thank you.

Emil

On Mon, Jul 24, 2017 at 2:46 PM, Hoda Rohani <hoda at nlnetlabs.nl> wrote:

> Hi Emil,
>
> I guess now decreasing the value 'Purge' in kasp will resolve the issue.
> Ods waits for Purge time before removing the
> key. It seems that your key is now in this state.
>
> Hope that works for you.
>
> Regards,
> Hoda
>
>
>
> On 24-07-17 13:29, Emil Natan wrote:
> > Hi Hoda,
> >
> > There are no signatures created/remaining in the signed zone with the
> > retired key and it's completely redundant it's kept in the zonefile for
> so
> > long.
> >
>
>
>
> > Unfortunately the proposed fix does not work. It affects the active key,
> > but not the retired key which I want to remove from the DNSKEY RRset.
> >
> > #### with original ZSK Lifetime value of 4 months
> > # ods-ksmutil key list -z example.com -v
> > Keys:
> > Zone:                           Keytype:      State:    Date of next
> > transition (to):  Size:   Algorithm:  CKA_ID:
> > Repository:                       Keytag:
> > example.com                          ZSK           retire    2017-08-23
> > 13:50:48 (dead)     2048    8           6b5c0df9591dac52e2fdabbc7cf89b89
> >  Keyper                            25365
> > example.com                          KSK           active    2018-07-23
> > 11:08:58 (retire)   2048    8           7e664b28619e580963c9fb6e0ee98a96
> >  Keyper                            58744
> > example.com                         ZSK           active    2017-11-24
> > 13:48:48 (retire)   2048    8           096ace586ef8102d694cac0f58642460
> >  Keyper                            19239
> >
> > ### lifetime decreased to 2 months
> > Keys:
> > Zone:                           Keytype:      State:    Date of next
> > transition (to):  Size:   Algorithm:  CKA_ID:
> > Repository:                       Keytag:
> > example.com                          ZSK           retire    2017-08-23
> > 13:50:48 (dead)     2048    8           6b5c0df9591dac52e2fdabbc7cf89b89
> >  Keyper                            25365
> > example.com                          KSK           active    2018-07-23
> > 11:08:58 (retire)   2048    8           7e664b28619e580963c9fb6e0ee98a96
> >  Keyper                            58744
> > example.com                          ZSK           active    2017-09-23
> > 13:48:48 (retire)   2048    8           096ace586ef8102d694cac0f58642460
> >  Keyper                            19239
> >
> > ### lifetime decreased to 1 month
> > Keys:
> > Zone:                           Keytype:      State:    Date of next
> > transition (to):  Size:   Algorithm:  CKA_ID:
> > Repository:                       Keytag:
> > example.com                          ZSK           retire    2017-08-23
> > 13:50:48 (dead)     2048    8           6b5c0df9591dac52e2fdabbc7cf89b89
> >  Keyper                            25365
> > example.com                         KSK           active    2018-07-23
> > 11:08:58 (retire)   2048    8           7e664b28619e580963c9fb6e0ee98a96
> >  Keyper                            58744
> > example.com                          ZSK           active    2017-08-23
> > 13:48:48 (retire)   2048    8           096ace586ef8102d694cac0f58642460
> >  Keyper                            19239
> >
> > ### lifetime decreased to 10 days
> > Keys:
> > Zone:                           Keytype:      State:    Date of next
> > transition (to):  Size:   Algorithm:  CKA_ID:
> > Repository:                       Keytag:
> > example.com                          ZSK           retire    2017-08-23
> > 13:50:48 (dead)     2048    8           6b5c0df9591dac52e2fdabbc7cf89b89
> >  Keyper                            25365
> > example.com                          KSK           active    2018-07-23
> > 11:08:58 (retire)   2048    8           7e664b28619e580963c9fb6e0ee98a96
> >  Keyper                            58744
> > example.com                          ZSK           active    2017-08-02
> > 13:48:48 (retire)   2048    8           096ace586ef8102d694cac0f58642460
> >  Keyper                            19239
> >
> > Emil
> >
> > On Mon, Jul 24, 2017 at 12:52 PM, Hoda Rohani <hoda at nlnetlabs.nl> wrote:
> >
> >> Hello Email,
> >>
> >>
> >> On 23-07-17 15:24, Emil Natan wrote:
> >>> I tried to decrease various values set in the kasp.xml file, most
> notably
> >>> validity default and denial, publish and retire safety, propagation
> delay
> >>> for the zone and the parent zone and TTLs. While that affected the key
> >>> state is some cases, it did not affect the ZSK in retire state which I
> >> want
> >>> to remove from the zone.
> >>>
> >>
> >> I think reducing the Life time value of ZSK would help you. You should
> run
> >> 'ods-ksmutil policy import' after decreasing
> >> the Life time to see the result.
> >> After the old ZSK is completely removed you can modify the ZSK Lifetime
> >> again to have the main value.
> >>
> >>
> >>> I also tried to force deletion of that key with ods-ksmutil key delete
> >> but
> >>> the action was rejected by the enforcerd since it considers the key to
> be
> >>> in use.
> >>>
> >>
> >> Actually it seems that this key is still being used for signatures and
> >> cannot be deleted.
> >>
> >>> I believe it's possible to manually change the value of next transition
> >> for
> >>> that key in the database, but that I really consider last resort.
> >>>
> >>
> >> Please let us know if you still have the problem.
> >>
> >>> Emil
> >>
> >> Regards,
> >> Hoda Rohani
> >>
> >>>
> >>> On Sat, Jul 22, 2017 at 5:02 PM, Emil Natan <shlyoko at gmail.com> wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> opendnssec version 1.4.13, kasp.xml attached.
> >>>>
> >>>> We have all keys (KSK and ZSK) for the next 5 years pregenerated on
> the
> >>>> HSM.
> >>>>
> >>>> <ManualRollover/> is set for the KSK.
> >>>>
> >>>> Yet yesterday, on the day the KSK rollover was scheduled for, it just
> >>>> happened.
> >>>>
> >>>> Jul 20 03:47:15 signer001 ods-enforcerd: Zone example.com found.
> >>>> Jul 20 03:47:15 signer001 ods-enforcerd: Policy for example.com set
> to
> >> 1.
> >>>> Jul 20 03:47:15 signer001 ods-enforcerd: Policy 1 found in DB.
> >>>> Jul 20 03:47:15 signer001 ods-enforcerd: Config will be output to
> >>>> /ods-data/var/opendnssec/signconf/example.com.xml.
> >>>> Jul 20 03:47:15 signer001 ods-enforcerd: KSK key allocation for zone
> >>>> example.com: 1 key(s) allocated
> >>>>
> >>>> The new KSK was introduced into the zone and DNSKEY signed with both
> new
> >>>> and old KSK. What makes it even more annoying is that the ZSK was
> >> rolled at
> >>>> the same time (as expected), so now we ended having pretty big DNSKEY
> +
> >>>> RRSIG response.
> >>>>
> >>>> One of the checks on the signed zonefiles stopped it from being
> >> published
> >>>> and now we have to decide either to publish the zonefile that way or
> >> force
> >>>> the ZSK rollover to finish faster than it should if we wait for it to
> >>>> happen automatically and then publish the zonefile. Because of the
> >>>> signature validity set to 31 days, it's scheduled to happen on
> >> 2017-08-20.
> >>>> The DNSKEY RRset has a TTL of one hour and we publish the zone every
> day
> >>>> and it spreads instantly, so it's already safe to do so. I see the
> >>>> ods-ksmutil provides option to retire KSK (ksk-retire), but I do not
> see
> >>>> such option for ZSK. Any ideas if and how it can be done?
> >>>>
> >>>> Thanks
> >>>> Emil
> >>>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Opendnssec-user mailing list
> >>> Opendnssec-user at lists.opendnssec.org
> >>> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
> >>>
> >>
> >
> >
> >
> > _______________________________________________
> > Opendnssec-user mailing list
> > Opendnssec-user at lists.opendnssec.org
> > https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20170724/51d96f5d/attachment.htm>


More information about the Opendnssec-user mailing list