Functionality:
- conf: added an option for swiching manual(=none)/automatic KSK rollover; and policy options for KSK lifetime
- with automatic KSK rollover enabled, the server performs similar rollover like for ZSK
- when the parent zone's DS record will to be updated, proper CDS&CDNSKEY records will be published and one of following options apply:
- periodical check for DS at specified parent zone's authoritative server (if more specified, all of them must be updated)
- manual confirmation by user via knotc
- (also a warning-timeout is possible to warn the user that KSK is nearing lifetime end and parent zone handling is urgently needed)
- when we know that the DS is updated, we hide the CDS&CDNSKEY records and finalize the rollover
Internals:
- one more key state must be introduced: KEY_STATE_READY (between KEY_STATE_PUBLISHED and KEY_STATE_ACTIVE). This will be done already as part of KASP refactoring because of KASP db structure etc.
New configuration options:
- policy/rollover-mode = manual | zsk_auto | full_auto (deprecates policy/manual, transition smooth)
- policy/ksk-lifetime
- policy/ksk-submission-check (list of links to "remote" sections)
- (policy/ksk-submition-check-interval) - for now we just check at every zone re-sign to simplify conf
Edit: instead of policy enum (manual, zsk_auto, full_auto), we just use the same as for now (policy/manual: true|false), and ksk_lifetime can have infinite value (moreover, this will be default), so as a result, zsk-only automatic rollover applies with infinite ksk_lifetime.
Idea: there is a proposal of a way to wake up a user-custom script in some cases, for now in case of KSK submittion. There will be another socket file which will be filled with a line when this event occurs. The script shall read this socket and with the line read, it can do whatever.
Design of shared KSK rollover:
It is difficult to design automatic rollover of a KSK shared between more zones. The key timers are shared, so all zones must make a consensus to allow a rollover step for this key. This is mostly to check the submittion (all zones must their parents' DS records updated), but also helps to determine which of the sharing zones performs the action.
It is creepy that during the "voting" in progress, the number of zones can decrease. In this case, Knot will not know if the zone removed voted already, or not. Solving this has to be thought of.