Hi Libor,
the requirement is definitely weird, I totally agree with you.
Thanks for the input, helps me a lot!
Thanks,
Thomas
On 10.08.20 12:58, libor.peltan wrote:
Hi Thomas,
first of all, your requirements seem pretty weird. The key management in
Knot mostly works "as needed", where precise scheduling is an unusual
demand.
However, with some computation, this can be achieved with automatic key
management.
For ZSKs, the period between two roll-overs is (zsk-lifetime +
propagation-delay + dnskey-ttl). All these values can be configured in
policy section so that the sum is your desired 24h.
KSKs are more complicated, but their behavior is also different, thus
the period between roll-overs is just ksk-lifetime. However, the
roll-over procedure itself can take various time (including infinity),
depending on key submission. For really predictible timings, you would
need to substitute parent DS checks with simple timeout (in submission
section, set timeout and unset parent), but take care of proper DS
submission to avoid broken trust chain.
Please also note that automatic key management performs only one key
roll-over at a time. If KSK is still rolling, ZSK roll-over will be
delayed (a vice versa). You need to somehow get to the state that ZSK
expires e.g. on 12am and KSK on 6pm...
The command `knotc zone-key-rollover` works with automatic key
management, and invokes immediate (that is, earlier than configured
lifetime) roll-over. So setting the lifetimes to infinity and reguralry
initiating roll-overs this way is also possible.
---
It's also possible to achieve the same with manual key management. With
keymgr, you can generate keys and assign them timers. Each timer means,
that the key shall enter the corresponding state at that time. 0 means
infinity, or "never". The key states are described here
https://www.knot-dns.cz/docs/2.9/singlehtml/index.html#dnssec-key-states
and they are more-or-less equivalent to RFC 6781. After each change to
any timers, don't forget to re-sign the zone with `knotc zone-sign`, so
that the running server notices the change in key set.
To get familiar with key timers, you might experiment with automatic key
management and watch with `keymgr
example.com. list` what the timers do.
---
I don't really understand what you really mean with "I need to
pre-generate the keys". Just an internal disclosure: the `knotc
zone-key-rollover` command works the way that it only generates a key in
"published" state and re-signs the zone. You might simulate this by
importing pre-generated key with keymgr, setting only its "publish"
timer to now. With automatic key management, normal roll-over will
follow. However, this is a trick that we will probably not support forever.
Hope this helps!
Libor
Dne 08.08.20 v 21:06 Thomas napsal(a):
> Hi,
>
> I have another requirement for a capability test.
>
> I need to perform ZSK and KSK rollovers on specific times. Something
> like KSK rollover after exactly 60 hours. Or ZSK rollover after exactly
> 24 hours and another one after another 24 hours. And so on...
>
> One additional requirement is that I need to pre-generate the keys.
>
> I was thinking of doing it with manual key management enabled and to use
> the keymgr tool for it.
>
> But I'm unsure about how to set the key attributes correctly an in what
> order. At what point I have to set the new key to active, and how can I
> remove the old key, and so on...
> I have never done it manually as I normally use Knots automatic key
> management.
>
> Is the "knotc zone-key-rollover" useful here, or is it only useful in an
> automatic key management set up?
>
> I really appreciate any help here!
>
>
> Thanks a lot,
> Thomas