[Opendnssec-user] Question about <ManualRollover/>

[Yuri Schaeffer]

Hi Jake,

> Should adding the <ManualRollover/> tag to both KSK and ZSK, then
> running “ods-ksmutil update kasp”, change the “Date of next transition”
> as reported by “ods-ksmutil key list –verbose”?

I'm not sure if it would change the date but it will hold of any
rollovers unless you specifically issue a 'key rollover' command.

> Does ods-enforcer’d need to be kill –HUP’d to make this change take effect?

If all is well ods-ksmutil will do the enforcer HUP for you.

> Am I right in understand that keys currently listed for rollover later
> in the month will in fact not be rolled over so long as the
> <ManualRollover/> tag is present?

Yes. Though it might be that the DNSKEY will still be introduced in the
zone. But these new keys will not be used for signing while the tag is
present.

> Will the old rollover dates still be listed in the kasp database?  Does
> this mean that upon removing <ManualRollover/> that enforcerd will
> immediately roll the keys?

Yes. It keeps track of the time the last key became active. The age of
the key will be
	D_age = T_now - T_active
If D_age > D_lifetime (from KASP) and automatic rollover is used the
enforcer will initiate a rollover.

> Are there any other negative side effects to using ManualRollover
> temporarily?

No. It should not affect the DNSSEC validity of your zone. The signer
will just keep refreshing signature. It should just work.

> Our use case:
>                 New TLD coming online as a customer – currently signed
>                 Need losing provider to publish and sign our DNSKEY’s
>                 ZSK DNSKEY is currently set to expire inside the DNS
> Operator transition window

That should be entirely possible.

Best regards,
Yuri Schaeffer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20161207/7f0ee018/attachment.bin>