knot-dns-users

knot-dns-users@lists.nic.cz

4 participants
786 discussions

by Mike Wright

Hi, Just upgraded knot-resolver on ubuntu-22.04. It installs and runs but shows that the socket is not where it thinks it is. Socket is at /run/knot-resolver/control@1 but the new version is looking for it at /run/knot-resolver/control/1 systemctl status is available here: https://pastebin.com/56g22e2a Thanks for the great software! Mike Wright

3 roky, 8 měsíců

Why does knot need so much prodding to XFR and sign my zones?

by Jan-Piet Mens

Hello! Knot 3.2.0 with a Thales HSM configured this way: (btw, I am not obfuscating addresses or zone names -- these are actual testing names :) keystore: - id: thales backend: pkcs11 config: "pkcs11:token=XX;pin-value=XXX /opt/nfast/toolkits/pkcs11/libcknfast.so" key-label: on policy: - id: manualHSM keystore: thales single-type-signing: off manual: on zone: - domain: tt05 dnssec-signing: on dnssec-policy: manualHSM master: pdns acl: [ xfr, notify_from_pdns ] The zone `tt05' exists on the primary and can be transferred, as the following logs will show. I start off by generating a KSK and a ZSK, and verify that the keys are actually on the HSM: $ keymgr tt05 generate algorithm=8 size=2048 ksk=yes zsk=no 579f877d1739efb7bcf551e41c8777e965f8416f $ keymgr tt05 generate algorithm=8 size=2048 ksk=no zsk=yes eb8ef53ebffbd9950bfa914f7f2b0f1cd43bbe63 $ cklist -n | grep tt05 CKA_LABEL "tt05. KSK" CKA_LABEL "tt05. ZSK" I now reload Knot, and at this point I am actually expecting the server to "see" the new zone, get the keys, perform the transfer (XFR) and sign the zone. But all that doesn't happen: $ knotc reload Reloaded 2023-02-09T12:10:10+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started 2023-02-09T12:10:10+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished, 0.00 seconds, 3 messages, 377 bytes 2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK, public, active 2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256, public, active 2023-02-09T12:10:10+0100 error: [tt05.] DNSSEC, failed to load private keys (not exists) 2023-02-09T12:10:10+0100 error: [tt05.] DNSSEC, failed to load keys (not exists) 2023-02-09T12:10:10+0100 info: [tt05.] DNSSEC, next signing at 2023-02-09T13:10:10+0100 2023-02-09T12:10:10+0100 error: [tt05.] refresh, failed (not exists) 2023-02-09T12:10:10+0100 error: [tt05.] zone event 'refresh' failed (not exists) In the above, I don't understand why it's failed to load the keys. My _assumption_ is that the server has enumerated the keys from the HSM but did that before the two keys for this zone were created. Invoking `knotc zone-keys-load' doesn't alter the situation. I do understand the 'refresh' failing, as the zone tt05 doesn't as yet exist on this knot secondary. So I initiate a zone transfer: $ knotc zone-retransfer tt05 OK 2023-02-09T12:11:04+0100 info: [tt05.] control, received command 'zone-retransfer' 2023-02-09T12:11:04+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started 2023-02-09T12:11:04+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished, 0.00 seconds, 3 messages, 377 bytes 2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK, public, active 2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256, public, active 2023-02-09T12:11:04+0100 error: [tt05.] DNSSEC, failed to load private keys (not exists) 2023-02-09T12:11:04+0100 error: [tt05.] DNSSEC, failed to load keys (not exists) 2023-02-09T12:11:04+0100 info: [tt05.] DNSSEC, next signing at 2023-02-09T13:11:04+0100 2023-02-09T12:11:04+0100 error: [tt05.] refresh, failed (not exists) 2023-02-09T12:11:04+0100 error: [tt05.] zone event 'refresh' failed (not exists) It is clear that the transfer succeeds (the logs on the primary corroborate this), and knot apparently knows the correct keys to use for the zone. Why is it not signing it? $ knotc zone-sign tt05 OK 2023-02-09T12:11:38+0100 info: [tt05.] control, received command 'zone-sign' 2023-02-09T12:11:38+0100 info: [tt05.] DNSSEC, dropping previous signatures, re-signing zone 2023-02-09T12:11:38+0100 error: [tt05.] zone event 're-sign' failed (invalid parameter) I now restart the server: # <restart knotd> 2023-02-09T12:12:16+0100 info: Knot DNS 3.2.0 starting 2023-02-09T12:12:16+0100 info: loaded configuration file '/etc/knot.conf', mapsize 500 MiB 2023-02-09T12:12:16+0100 info: using UDP reuseport, incoming TCP Fast Open 2023-02-09T12:12:16+0100 info: binding to interface 10.24.34.16@5353 2023-02-09T12:12:16+0100 info: changed directory to / 2023-02-09T12:12:16+0100 info: loading 7 zones 2023-02-09T12:12:16+0100 info: [tt05.] zone will be loaded 2023-02-09T12:12:16+0100 info: starting server 2023-02-09T12:12:18+0100 info: [tt05.] failed to parse zone file '/var/zones/tt05' (not exists) Here again, I understand it cannot parse the zone, because the transfer hasn't actually been comitted to disk. So I manually transfer: $ knotc zone-retransfer tt05 OK 2023-02-09T12:13:23+0100 info: [tt05.] control, received command 'zone-retransfer' 2023-02-09T12:13:23+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, started 2023-02-09T12:13:23+0100 info: [tt05.] AXFR, incoming, remote 192.168.33.31@53, finished, 0.00 seconds, 3 messages, 377 bytes 2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, key, tag 38930, algorithm RSASHA256, KSK, public, active 2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, key, tag 511, algorithm RSASHA256, public, active 2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, signing started 2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, successfully signed 2023-02-09T12:13:23+0100 info: [tt05.] DNSSEC, next signing at 2023-02-23T11:13:24+0100 2023-02-09T12:13:23+0100 info: [tt05.] refresh, remote 192.168.33.31@53, zone updated, 0.44 seconds, serial none -> 2023010100, remote serial 2023010100, expires in 604800 seconds 2023-02-09T12:13:23+0100 info: [tt05.] zone file updated, serial 2023010100 And now the zone is signed. Is there some way to 'streamline' this? :-) Or am I just doing something wrong or being too impatient? Best regards, -JP

3 roky, 9 měsíců

Knot DNS 3.2.5 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.5! This is mostly a bugfix version. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.5/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

3 roky, 9 měsíců

PKCS#11 label is not set on keys created by Knot

by Jan-Piet Mens

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

3 roky, 9 měsíců

Knot DNS 3.2.4 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.4! This version improves catalog zone performance and fixes some issues mostly related to zone transfers. Update from previous 3.2.x versions is recommended if primary nameserver isn't Knot DNS. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.4/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

3 roky, 11 měsíců

Knot DNS 3.2.3 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.3! This version fixes broken knsupdate and some QUIC-related issues. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.3/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

3 roky, 11 měsíců

knsupdate Segmentation fault

by Bastien Durel

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

4 roky

Knot DNS 3.2.2 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.2! This version brings a few new features and some fixes. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.2/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Donation: https://donations.nic.cz/donate/?project=knot-dns Regards, Daniel

4 roky

Knot DNS 3.2.1 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.1! This version adds compatibility with libbpf 1.0 and fixes mostly XDP-related issues. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.1/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Donation: https://donations.nic.cz/donate/?project=knot-dns Regards, Daniel

4 roky, 2 měsíce

policy.rrsig-refresh in Knot 3.2.0

by André Keller

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é

4 roky, 2 měsíce

← Newer
1
...
12
13
14
15
16
17
18
...
79
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users