[Opendnssec-user] rollover started automatically when ManualRollover set

[Emil Natan]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20170722/3d0410e4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kasp.xml.gz
Type: application/x-gzip
Size: 649 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20170722/3d0410e4/attachment.bin>