Good morning,
In Knot 3.2.0 the rrsig-refresh default changed, excerpt changlog:
knotd: default value for 'policy.rrsig-refresh' is propagation delay +
zone maximum TTL
I'd like to understand the rationale behind this change and whether or
not we should tune this parameter in our deployment.
We currently have monitoring in place to ensure that we always serve
valid signatures. In my understanding with the old defaults < 3.2.0 of
rrsig-refresh of 7d and rrsig-lifetime of 14d, we always ended up with
signatures that were at least valid for 7 days. As I understand, with
the new defaults, signatures might be refreshed way closer to their
expiry date. This makes me a bit uneasy, as if there are issues with
signing this gives us hardly any time to react and fix potential issues
before the current signatures expire.
I assume setting rrsig-refresh explicitly to 7d would restore the old
behavior, but I'm wondering if this is somehow bad practice and if we
are overly paranoid with our monitoring.
How do other people handle this? Are there any downsides of setting a
higher value of rrsig-refresh that we are not aware of?
Regards
André
Hello,
I tried to upgrade to knot 3.2 using the debian packages
from https://deb.knot-dns.cz/knot-latest bullseye/main, but the server
does not use my HSM anymore. All zones fails with :
août 22 14:38:13 arrakeen knotd[1285865]: info: [durel.org.] zone file parsed, serial 2021120479
août 22 14:38:13 arrakeen knotd[1285865]: error: [durel.org.] DNSSEC, failed to initialize signing context (PKCS #11 token not available)
août 22 14:38:13 arrakeen knotd[1285865]: 2022-08-22T14:38:13+0200 error: [durel.org.] DNSSEC, failed to initialize signing context (PKCS #11 token not available)
août 22 14:38:13 arrakeen knotd[1285865]: 2022-08-22T14:38:13+0200 error: [durel.org.] zone event 'load' failed (PKCS #11 token not available)
août 22 14:38:13 arrakeen knotd[1285865]: error: [durel.org.] zone event 'load' failed (PKCS #11 token not available)
debug log does not seems to print more details about error
keystore is defined as :
keystore:
- id: hsmkey
backend: pkcs11
config: "pkcs11:pin-value=REDACTED /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so"
The HSM itself is an USB key from CardContact.de
Downgrading to 3.1.9-cznic.1~bullseye re-enable signing
Is there anything I can do to debug/solves this problem ?
Regards,
--
Bastien
Hi,
thank you for contacting us with your issues with Knot DNS. However, you
have hit wrong channel: knot-resolver-users mailing-list is intended for
users of Knot Resolver. I'm sending this reply already to proper channel.
You correctly pointed out that Knot did not delete old key after the
delete-delay period.
This seems to be an effect of an actually intentional, but perhaps
tricky feature: Knot postpones this (relatively unnecessary) key
deletion until next signing process. The point is, that initializing the
whole "signing machinery" just in order to purge a deleted (marked as
such) key might be an overkill (mostly on configurations with many many
zones).
You can see the next planned singing event when calling `knotc
zone-status` or when inspecting the logfile for logs of the previous
signing event. Please let me know if the deleted key disappears once the
zone is re-signed. I guess it might take up to a week, since this long
it takes between RRSIGs re-creation according to your configuration.
If you need to delete the key immediately, you can use keymgr utility,
or it might be also done with `knotc zone-keys-load` (basically
triggering the zone signing process out of schedule).
Thank you,
Libor
Hi,
my knot installation (3.0.5) gives me this notice:
notice: config, non-default 'template[default].storage' detected, please
configure also 'db.storage' to avoid compatibility issues with future
versions
I have searched the docs to find out what I have to do, but did not find
any specific information. Can you give me a hint what needs to be done here?
Thanks a lot,
Thomas
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
Hello,
I'd like to be able to do automatic ZSK and manual KSK rollovers. Basically the
KSK should have an endless validity but I might want to roll it with
(manually-trigerred) RFC 5011 semantics.
It it permissible to have a policy such as shown below and then explicitly
use `keymgr' commands to generate new keys and set `revoke', `retire' and
`remove' timers on the older key?
Testing indicates that it works as desired, I'm just unsure whether key
manipulation is permitted.
policy:
- id: autoHSM
keystore: pemstore
single-type-signing: off
manual: off
ksk-shared: off
ksk-lifetime: 0
zsk-lifetime: 30d
cds-cdnskey-publish: rollover
Thank you,
-JP
Hello,
keymgr(8) lists keys in plain text which is fine for processing with awk(1)
et.al. Are there any plans to make it output JSON? I'm thinking along the lines
of making parsing future-proof:
[
{
"id": "a982d72174a48a3ef083a97e5aae02cc47f58762",
"ksk": true,
"zsk": false,
"key_tag": 61676,
"algo": 8,
"size": 2048,
"public-only": false,
"pre-active": 0,
"publish": 1652161461,
"ready": 1652161581,
"active": 1652161642,
"retire-active": 1652168902,
"retire": 0,
"post-active": 0,
"revoke": 0,
"remove": 1652168962
}
]
keymgr_list_keys() calls either of print_key_full() / print_key_brief() to do
the work, and I think it would be quite easy to add support for JSON.
Is this something I should make happen?
-JP
Hello,
I need to migrate away from an HSM-backed OpenDNSSEC installation which uses a
Thales nCipher for key storage and am experimenting with Knot DNS 3.1.8 (on
CentOS 7, FWIW).
I've compiled Knot, and it is able to access said HSM via PKCS#11. I have
configured a zone with a manual policy.
policy:
- id: manualHSM
keystore: thales
single-type-signing: on
manual: on
After importing keys from the HSM with `keymgr import-kcs11', knotd launches
and signs the zone with KSK/ZSK as expected.
What I would then like to have happen is to have periodic ZSK rollovers as well
as periodic KSK rollovers. In order to accomplish this I have changed the
zone's policy to
policy:
- id: autoHSM
keystore: thales
single-type-signing: off
manual: off
algorithm: rsasha256
ksk-size: 2048
zsk-size: 1024
zone-max-ttl: 60
dnskey-ttl: 60
propagation-delay: 60
nsec3: on
nsec3-iterations: 0
nsec3-salt-length: 0
nsec3-salt-lifetime: 0
ksk-lifetime: 7200
zsk-lifetime: 3600
A restart of knotd then begins by creating a new ZSK and rolling it, and the
KSK is rolled automatically after 7200 seconds. (These timers are for testing
only.)
So far no complaints whatsoever -- this is working exactly as I had hoped it
would. I am assuming that it is permissible to change a zone's policy in flight.
What I'd like is confirmation that the KSK roll will actually never occur
immediately, but only after a first period has elapsed.
Can I rely on this behavior, i.e. that the first KSK roll will occur only after
a first `ksk-lifetime' period?
Best regards,
-JP
