14 Čec
2020
14 Čec
'20
14:23
Hi Jean-Piet!
Thanks much for your feature suggestion.
The truth is, that Knot DNS has not been RFC5011-aware at all.
I'm open to implement this for the next version, at least for the manual
key management, as you suggested.
I'm tentative for enabling this with automatic key management, since
it's quite complicated, and with algorithm rollover maybe even fragile:
https://tools.ietf.org/html/rfc6781.html#section-4.1.4.2
Anyway, I'd like to ask you for an operational opinion: for how long
period would you publish the old KSK with 'revoked' flag before deleting
it (comparing to DNSKEY TTL, zone maximal TTL, propagation delay etc)?
To the side note: well, this is something between a bug and a feature :)
For the sake of simplicity, when manual key management is enabled, knotd
is simply not allowed to modify the keyset in any way, including final
deletion of keys marked as deleted (with automatic key management
however, the deleted keys really disappear).
Hearty regards,
Libor
Dne 14.07.20 v 09:37 Jan-Piet Mens napsal(a):
Hello!
first of all, thank you for a wonderful authoritative DNS server; as
mentioned a while back, I'm loving the automatic key management and DS
push; both work a treat.
I have a requirement for manual key management and that is to be able
to roll KSK keys a la RFC 5011 for both BIND and Unbound instances to
automatically change their trust anchors.
In Knot I can retire a key and subsequently have it removed, but the
key isn't revoked (a.k.a. key flags 257+128 == 385).
keymgr . set 41155 active=+1mi retire=+5mi remove=+60mi
As such, BIND will, when this particular KSK is removed from the
DNSKEY RRset, (rightly) complain:
managed-keys-zone: Active key 41155 for zone . unexpectedly
missing
managed-keys-zone: Key 30377 for zone . is now trusted
(acceptance timer complete)
I've not found the word 'revoke' in the documentation, and no flags I
can set with keymgr(8) seem to indicate that I can revoke a key. Can
you help me, please?
As an aside, I've noticed that when keymgr's `remove' time is reached,
the key is removed from the zone (which is expected), however the key
itself remains in the key store. From there, I can delete it, but I
can also set flags on it in such a way as that it's brought *back*
into the zone. Is that expected behaviour? It's not a problem per se,
I'd just like to know whether I've understood the system.
Thank you and kind regards,
-JP