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 -- https://lists.nic.cz/mailman/listinfo/knot-dns-users
