12 Kvě
2022
12 Kvě
'22
14:46
The documentation for `keymgr' says that the subcommand `del-all-old' is
related to offline KSK, but it also seems to work for online KSK.
Moments ago I had the following keys of which e381* had just been marked as
removed:
$ keymgr -c knot.conf tm list -b iso
e381198aea254a1dbceb3c5b153cbefaa98c959a 31943 KSK ECDSAP256SHA256
publish=2022-05-12T11:43:56Z ready=2022-05-12T11:43:56Z active=2022-05-12T11:43:56Z
retire=2022-05-12T12:35:42Z revoke=2022-05-12T12:33:42Z remove=2022-05-12T12:37:42Z
d68e6803daa3e3ee34dd07d6966df0c402594fb2 26288 ZSK ECDSAP256SHA256
publish=2022-05-12T12:28:18Z active=2022-05-12T12:28:18Z
b0cc879e9b9f5faae647c7019a12821e62150378 62610 KSK ECDSAP256SHA256
publish=2022-05-12T12:30:49Z ready=2022-05-12T12:30:49Z active=2022-05-12T12:30:49Z
$ keymgr -c knot.conf tm del-all-old
OK
$ keymgr -c knot.conf tm list -b iso
d68e6803daa3e3ee34dd07d6966df0c402594fb2 26288 ZSK ECDSAP256SHA256
publish=2022-05-12T12:28:18Z active=2022-05-12T12:28:18Z
b0cc879e9b9f5faae647c7019a12821e62150378 62610 KSK ECDSAP256SHA256
publish=2022-05-12T12:30:49Z ready=2022-05-12T12:30:49Z active=2022-05-12T12:30:49Z
and the PEM key file has also been removed.
Is this to be expected? Would it be a good idea to add a note to the
documentation clarifying this?
Best regards,
-JP
12 Kvě
12 Kvě
18:05
Hi Jan-Piet,
thanks much for your point.
You're correct, the del-all-old command works in general, even without
Offline KSK feature. The same is actually true for pregenerate command.
However, we're just not motivated to encourage the users to use them.
Anyway, with automatic key management, the keys are normally deleted
automatically.
Could you share your setup design with us? We love any feedback, in
order to have an overview of how people are using Knot.
Thank you,
Libor
Dne 12. 05. 22 v 14:46 Jan-Piet Mens napsal(a):
The documentation for `keymgr' says that the
subcommand `del-all-old' is
related to offline KSK, but it also seems to work for online KSK.
Moments ago I had the following keys of which e381* had just been
marked as
removed:
$ keymgr -c knot.conf tm list -b iso
e381198aea254a1dbceb3c5b153cbefaa98c959a 31943 KSK ECDSAP256SHA256
publish=2022-05-12T11:43:56Z ready=2022-05-12T11:43:56Z
active=2022-05-12T11:43:56Z retire=2022-05-12T12:35:42Z
revoke=2022-05-12T12:33:42Z remove=2022-05-12T12:37:42Z
d68e6803daa3e3ee34dd07d6966df0c402594fb2 26288 ZSK ECDSAP256SHA256
publish=2022-05-12T12:28:18Z active=2022-05-12T12:28:18Z
b0cc879e9b9f5faae647c7019a12821e62150378 62610 KSK ECDSAP256SHA256
publish=2022-05-12T12:30:49Z ready=2022-05-12T12:30:49Z
active=2022-05-12T12:30:49Z
$ keymgr -c knot.conf tm del-all-old
OK
$ keymgr -c knot.conf tm list -b iso
d68e6803daa3e3ee34dd07d6966df0c402594fb2 26288 ZSK ECDSAP256SHA256
publish=2022-05-12T12:28:18Z active=2022-05-12T12:28:18Z
b0cc879e9b9f5faae647c7019a12821e62150378 62610 KSK ECDSAP256SHA256
publish=2022-05-12T12:30:49Z ready=2022-05-12T12:30:49Z
active=2022-05-12T12:30:49Z
and the PEM key file has also been removed.
Is this to be expected? Would it be a good idea to add a note to the
documentation clarifying this?
Best regards,
-JP
--
19:56
Could you share your setup design with us?
Knot will be a bump-in-the-wire signer (in current BIND terminology this would
be an inline-signer) which transfers zones from a hidden PowerDNS primary. All
but one zone will be signed with multiple keys and automatic KSK and ZSK
rollovers. All keys generated/stored/obtained on/from Thales nCipher HSMs
accessed via PKCS#11.
There is one internal TLD which requires special behavior: it requires
automatic ZSK rollovers, but the KSK must not roll until Knot is specifically
instructed to roll it, and when that happens, it must be rolled with RFC5011
semantics (except that the standby times will be 60 and not the default of 30
days). It is perfectly ok to execute this procedure "manually" by issuing
`keymgr' commands; further automation is not required.
I don't think there's anything particularly special about this setup other than
the requirement for the one zone.
You might have inferred from previous communication that this setup is
(finally!) replacing a bunch of OpenDNSSEC signers; we feel Knot is far more
reliable and stable than that software ever was.
Best regards,
-JP
721
days inactive
721
days old
2 comments
2 participants
participants (2)
-
Jan-Piet Mens -
libor.peltan