I note that the key label is not set when Knot generates new keys via PKCS#11.
Invoking `p11tool --list-all' shows a key as
Object 449:
URL: pkcs11:model=;manufacturer=nCipher%20Corp.%20Ltd;serial=xxx;\
token=YYY;\
id=%04%66%D0%9C%0D%9E%24%D9%79%0A%17%D3%5D%A0%CC%5A%3F%E2%A3%26;\
type=public
Type: Public key (RSA-2048)
Label:
ID: 04:66:d0:9c:0d:9e:24:d9:79:0a:17:d3:5d:a0:cc:5a:3f:e2:a3:26
The ID is that which `keymgr list' displays (with colons in it), but the label
is empty.
Is this by design? Would it be possible for Knot to actually set the label
(e.g. zone name - key type: example.com-ksk)?
Best regards,
-JP
Hello,
Since I upgraded to 3.2.2-cznic.1~bullseye, my scripts using knsupdate
fails, on every machine they run on.
I can reproduce this with gdb, here is the trace I get in this case :
Starting program: /usr/bin/knsupdate -k
/etc/letsencrypt.sh/hooks/tsig.key /tmp/tmp.17EBRdeI8j
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x000055555556161c in net_send (net=net@entry=0x7ffffffcbb80,
buf=0x555555592a10 "\345\327(", buf_len=196)
at utils/common/netio.c:587
587 utils/common/netio.c: No such file or directory.
(gdb) where
#0 0x000055555556161c in net_send (net=net@entry=0x7ffffffcbb80,
buf=0x555555592a10 "\345\327(", buf_len=196)
at utils/common/netio.c:587
#1 0x000055555555adee in pkt_sendrecv
(params=params@entry=0x7ffffffcbdd0) at utils/knsupdate/knsupdate_exec.c:456
#2 0x000055555555ba01 in cmd_send (lp=<optimized out>,
params=0x7ffffffcbdd0)
at utils/knsupdate/knsupdate_exec.c:851
#3 0x000055555555b3e6 in knsupdate_process_line
(line=line@entry=0x5555555755e0 "send",
params=params@entry=0x7ffffffcbdd0) at
utils/knsupdate/knsupdate_exec.c:498
#4 0x000055555555b5ed in knsupdate_process_line (params=0x7ffffffcbdd0,
line=0x5555555755e0 "send")
at utils/knsupdate/knsupdate_exec.c:486
#5 process_lines (params=params@entry=0x7ffffffcbdd0,
input=input@entry=0x5555555910f0)
at utils/knsupdate/knsupdate_exec.c:527
#6 0x000055555555bd3e in knsupdate_exec
(params=params@entry=0x7ffffffcbdd0)
at utils/knsupdate/knsupdate_exec.c:575
#7 0x0000555555559dc9 in main (argc=<optimized out>,
argv=0x7fffffffe548) at utils/knsupdate/knsupdate_main.c:35
The nsupdate script (/tmp/tmp.17EBRdeI8j) is here (with truncated TXT) :
server 10.42.42.21
zone durel.eu.
origin durel.eu.
ttl 600
add _acme-challenge.ns.durel.eu. 600 in TXT "qLH_KkbQ_IUVr[...]7rs-iUE"
send
quit
As I can reproduce this with any tsig key, I can provide a core if you
need it.
--
Bastien Durel
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
