- knot-dns-users - lists.nic.cz

by Randy Bush

a bit confused here. knot package for bookworm does not seem to include kzonecheck. nor does knot-dnsutils. where/how to get? thanks randy

1 rok, 2 měsíce

2
2
0 0

AXFR sender FINs 10% of the way through transfer

by Randy Bush

debian 12 # uname -a Linux rip.psg.com 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux # knotc --version knotc (Knot DNS), version 3.2.6 AXFR of a 750k zone from seattle to, lebanon, europe, iceland, southern africa, ...) fails over v5 and v6, i.e. somewhat larger rtt same AXFR seattle seattle or seattle to ashburn works v4 and v6. seattle to dallas v4 good, v6 fails, but it smells of an HE.net hop. when it fails, it is always within a hundred or so mytes of the same place, approximately 10% through the file. pcap of seattle->beirut at https://archive.psg.com/240323.beirut.pcap the last payload is in frame 217. at 219, seattle (b) sends a FIN/PSH/ACK. then at 251, after acking everything, beirut (nabil) FIN/ACKs seattle's FIN and we're dead. i am not positive this is the key question as my tcp fu is a bit rusty. but why did seattle send the FIN at 219, 10% through the file? randy

1 rok, 3 měsíce

3
7
0 0

silly nit

by Randy Bush

in address: [185.91.97.18, 2a05:e380:2:4::2] # nabil.beirutix.net if this is a tab character ^ # knotc conf-check error: config, file '/etc/knot/knot.conf', line 324, item 'address', value '2a05:e380:2:4::2' (tabulator character is not allowed) blanks are ok # knotc --version knotc (Knot DNS), version 3.2.6 yes, that is the latest on debian 12 randy

1 rok, 3 měsíce

1
0
0 0

bitw signing as secondary

by Randy Bush

server runs a tld as primary, but slds are hidden primaries which the server pulls as a secondary, wants to sign bump-in-the-wire, and then make available to public secondaries. i think that the doc says this is doable, but instructions are insufficiently explicit for this idjit. i am fetching the slds into policy: - id: pol-256-256 algorithm: rsasha256 # was ecdsap256sha256 sra uses ecdsap384sha384 manual: on ... template: - id: signed storage: /var/lib/knot/sec-sign dnssec-signing: on dnssec-policy: pol-256-256 zonefile-sync: -1 zonefile-load: difference journal-content: all serial-policy: unixtime ... zone: - domain: sld.tld file: tld.sld # sorry, i like alpha sort in `ls` :) master: hidden-fetch template: signed acl: [allow-local, secondaries-push] the policy and template are those from signing primary zone; which i suspect is ill advised. i did generate keying as i would when signing a primary zone # keymgr sld.tld generate algorithm=rsasha256 ksk=yes zsk=yes 7a618eaf94ea1d903233cb547faa24bae8cb49a5 # knotc zone-reload sld.tld OK # keymgr sld.tld ds sld.tld. DS 63562 8 2 2d25e465f131900413d7e8a90ad1b96c75ba835de63dfee08610b113a779d41f sld.tld. DS 63562 8 4 ed9c31c495703ec354f1a1835c9878339224cc06ac3001151c2ebb89524b25190efa424348c999b0c4df940edffa8409 any kind soul(s) care to whack me with a clue bat? randy

1 rok, 3 měsíce

3
5
0 0

Possible signing bug? Missing wildcard NSEC for RCODE 3 subdomains

by Matthew Pounsett

I got a report of an NSEC error from someone who tried to connect to a mistyped hostname. I've done a bit of poking, and it looks like we're seeing a missing wildcard NSEC for domain names that are two subdomains down from the apex, but not for subdomains of the apex. Though, I admit I can't see the problem myself. Querying by hand I see what looks like an identical response, but resolvers and DNSViz report problems with the deeper name. For example, nonexistent.dns-oarc.net and nonexistent.sjc.dns-oarc.net ( sjc.dns-oarc.net is a real subdomain with hosts in it, not an ENT)... kdig output and DNSViz results below. We're running knot/unknown,now 3.3.5-cznic.1~bullseye from deb.knot-dns.cz, and this is the relevant policy statement for the zone: policy: - id: ecdsa algorithm: ecdsap256sha256 ksk-lifetime: 365d ksk-submission: parent_zone_sbm zsk-lifetime: 30d rrsig-lifetime: 14d rrsig-refresh: 7d We are mid-KSK-roll, waiting on the DS submission check. Have I misconfigured something here, or is there a signing bug, or is this something else? Thanks! Matt --- nonexistent.sjc.dns-oarc.net: DNSviz reports this is fine. <https://dnsviz.net/d/nonexistent.dns-oarc.net/ZfNH1w/dnssec/> ;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 9380 ;; Flags: qr aa; QUERY: 1; ANSWER: 0; AUTHORITY: 6; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; nonexistent.dns-oarc.net. IN A ;; AUTHORITY SECTION: dns-oarc.net. 3600 IN SOA ns1.dns-oarc.net. hostmaster.dns-oarc.net. 2024031400 300 60 604800 3600 nfsen.dns-oarc.net. 3600 IN NSEC ns.dns-oarc.net. A AAAA RRSIG NSEC dns-oarc.net. 3600 IN NSEC fs1.10g.dns-oarc.net. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY CDS CDNSKEY CAA dns-oarc.net. 3600 IN RRSIG SOA 13 2 14400 20240328021935 20240314004935 6048 dns-oarc.net. [omitted] nfsen.dns-oarc.net. 3600 IN RRSIG NSEC 13 3 3600 20240326215132 20240312202132 6048 dns-oarc.net. [omitted] dns-oarc.net. 3600 IN RRSIG NSEC 13 2 3600 20240322045130 20240308032130 6048 dns-oarc.net. [omitted] ;; Received 518 B ;; Time 2024-03-14 18:57:33 UTC ;; From 64.191.0.128@53(UDP) in 0.3 ms nonexistent.sjc.dns-oarc.net: resolvers and DNSViz report a missing wildcard NSEC <https://dnsviz.net/d/nonexistent.sjc.dns-oarc.net/ZfNH6w/dnssec/> ;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 660 ;; Flags: qr aa; QUERY: 1; ANSWER: 0; AUTHORITY: 6; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; nonexistent.sjc.dns-oarc.net. IN A ;; AUTHORITY SECTION: dns-oarc.net. 3600 IN SOA ns1.dns-oarc.net. hostmaster.dns-oarc.net. 2024031400 300 60 604800 3600 newmail.sjc.dns-oarc.net. 3600 IN NSEC pdu-7301.sjc.dns-oarc.net. A AAAA RRSIG NSEC shin-cubes.dns-oarc.net. 3600 IN NSEC an1.10g.sjc.dns-oarc.net. A AAAA RRSIG NSEC dns-oarc.net. 3600 IN RRSIG SOA 13 2 14400 20240328021935 20240314004935 6048 dns-oarc.net. [omitted] newmail.sjc.dns-oarc.net. 3600 IN RRSIG NSEC 13 4 3600 20240326215132 20240312202132 6048 dns-oarc.net. [omitted] shin-cubes.dns-oarc.net. 3600 IN RRSIG NSEC 13 3 3600 20240326215132 20240312202132 6048 dns-oarc.net. [omitted] ;; Received 544 B ;; Time 2024-03-14 18:57:33 UTC ;; From 64.191.0.128@53(UDP) in 0.3 ms

1 rok, 3 měsíce

4
4
0 0

Chained catalog zones

by Martin Huněk

Hi folks, Is it possible to chain multiple upstream catalog zones into one downstream one? I do have the following topology: Multiple DNS hidden masters <-> DNS signer / DNS master for public facing slaves <-> public facing slaves Can I define catalog zones on hidden masters and use them on public-facing signer/master to compose a catalog zone for the slaves? Best Regards, Martin Hunek Freenet Liberec, z.s.

1 rok, 3 měsíce

4
6
0 0

Knot DNS 3.3.5 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.5! This is a bugfix version with a few new features and enhancements. For those who use dnssec-validation, upgrade is recommended. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.3.5 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

1 rok, 3 měsíce

2
3
0 0

zone lost its KSK

by Bastien Durel

Hello, today I had a long power outage that stopped my primary server for a dozen hours When I re-started the server, some zones refused to start : Feb 12 21:55:17 arrakeen knotd[20728]: info: [geekwu.org.] DNSSEC, signing zone Feb 12 21:55:17 arrakeen knotd[20728]: error: [geekwu.org.] zone event 're-sign' failed (invalid parameter) the invalid parameter was there was no active KSK for these zones, as a keymgr list show b37b6c2[...] 39945 KSK ECDSAP384SHA384 publish=1636966605 active=1637053005 7cc8622[...] 20799 ZSK ECDSAP384SHA384 created=1706695010 After manually setting published & active status in keygmr, reloading these zones succeeded, and knot restarted to serve them. Do you know how these zone could has failed as this ? They run fine on auto-sign for years now. should I monitor closely the ones that need a re-sign tomorrow ? Regards, -- Bastien

1 rok, 4 měsíce

4
9
0 0

error: [ellael.org.] zone event 'refresh' failed (operation not supported)

by Michael Grimm

Hi, after successful migration of my hidden primary NSD and OpenDNSSEC signer to Knot DNS, I started to migrate my secondary NSDs to Knot DNS as well. Thanks to excellent documentation this migration went more or less flawless as well. BUT: I am somehow irritated about the following error messages at my hidden primary like: 2024-02-16T10:54:08+0100 debug: [ellael.org.] ACL, allowed, action transfer, remote 10.1.1.201@27919, key primary-secondary. 2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, outgoing, remote 10.1.1.201@27919 TCP, started, serial 2024021331 2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, outgoing, remote 10.1.1.201@27919 TCP, finished, 0.00 seconds, 1 messages, 7774 bytes 2024-02-16T10:54:09+0100 debug: [ellael.org.] ACL, allowed, action notify, remote 10.1.1.201@40884, key primary-secondary. 2024-02-16T10:54:09+0100 info: [ellael.org.] notify, incoming, remote 10.1.1.201@40884 TCP, serial 2024021331 >>>! 2024-02-16T10:54:09+0100 error: [ellael.org.] zone event 'refresh' failed (operation not supported) The log files at both secondary are identical, here one example: 2024-02-16T10:54:08+0100 info: [ellael.org.] AXFR, incoming, remote 10.2.2.203@5333 TCP, finished, 0.00 seconds, 1 messages, 7774 bytes 2024-02-16T10:54:08+0100 info: [ellael.org.] refresh, remote 10.2.2.203@5333, zone updated, 0.03 seconds, serial none -> 2024021331,\ expires in 1209600 seconds 2024-02-16T10:54:08+0100 info: [ellael.org.] zone file updated, serial 2024021331 >>>! 2024-02-16T10:54:09+0100 info: [ellael.org.] notify, outgoing, remote 10.2.2.203@5333 TCP, serial 2024021331 FYI: Those errors are only logged when a zone gets updated or using "knotc zone-notify" at the secondary site. Here are my essential config excerpts: Primary: acl: - id: aclTRANSACTIONS key: primary-secondary action: [notify, transfer] remote: - id: secondaryKBN key: primary-secondary address: 10.1.1.201 # KBN secondary via: 10.2.2.203 # outgoing interface Secondary: acl: - id: aclTRANSACTIONS key: primary-secondary action: [notify, transfer] remote: - id: primaryMWN key: primary-secondary address: 10.2.2.203@5333 # MWN hidden primary via: 10.2.2.201 # outgoing interface block-notify-after-transfer: on FYI: Only adding "block-notify-after-transfer: on" at secondary sites stopped those error messages. I found https://www.mail-archive.com/knot-dns-users@lists.nic.cz/msg01812.html : "I recommend not using this option unless you really know what you're doing and why this option is essential for you." Questions: #) I do have to admit, I don't understand what is going on without "block-notify-after-transfer: on"? #) Am I save in using "block-notify-after-transfer: on"? #) Or is the another config option? Thanks in advance and regards, Michael

1 rok, 4 měsíce

3
14
0 0

Secondary zones with some primary servers unreachable log interesting errors

by Juha Suhonen

Hello fellow Knot users, We're using Knot on some of our public authoritative servers. We operate a hidden primary configuration where there are two internal primary servers sending notifies to publicly accessible servers whenever zones change (ofc internal servers allow zone transfers & queries from the knot servers). By design, our hidden internal primary servers operate in a hot/cold setup - one of them is answering to zone transfers / sending out notifies and the other one is not (dns server software is not running on the cold server). This configuration causes knot to log alarming errors: Feb 1 17:28:45 ns2 knotd[624]: info: [zone.fi.] refresh, remote 10.54.54.1@8054, remote serial 2021083015, zone is up-to-date, expires in 864000 seconds Feb 1 17:28:45 ns2 knotd[624]: info: [zone.fi.] refresh, remote hidden-ns-2.internal, address 10.54.54.2@8054, failed (connection reset) Feb 1 17:28:45 ns2 knotd[624]: info: [zone.fi.] refresh, remote hidden-ns-2.internal, address [ipv6_address]@8054, failed (connection reset) Feb 1 17:28:45 ns2 knotd[624]: warning: [zone.fi.] refresh, remote hidden-ns-2.internal not usable Feb 1 17:28:45 ns2 knotd[624]: error: [zone.fi.] refresh, failed (no usable master), next retry at 2024-02-01T17:58:45+0200 Feb 1 17:28:45 ns2 knotd[624]: error: [zone.fi.] zone event 'refresh' failed (no usable master) Specifically, error "(no usable master)" is worrying - knot is able to reach hidden-ns-1.internal and verify that the zone it has is up-to-date. Also zone updates work normally and the zones don't seem to expire away (as zones should do if no master is reachable for an extended period of time). Looks like this error appeared in version 3.3.0. 3.2.9 did not log similar errors (except in cases where all primaries really were unreachable). Has there been some design change in 3.3.0 (ie is this intentional) or could this be a bug? Or could it be related to our configuration? Our configuration relies heavily on templates. These should be the important bits from knot's config, with ipv6 addresses hidden: acl: - id: "hidden-ns-1.internal" address: [ 10.54.54.1, ipv6_address ] action: notify - id: "hidden-ns-2.internal" address: [ 10.54.54.2, ipv6_address ] action: notify remote: - id: "hidden-ns-1.internal" address: [ 10.54.54.1@8054, ipv6_address@8054 ] via: [ x.x.x.x, ipv6_address ] - id: "hidden-ns-2.internal" address: [ 10.54.54.2@8054, ipv6_address@8054 ] via: [ x.x.x.x, ipv6_address ] template: - id: default storage: /var/lib/knot/zones master: hidden-ns-1.internal master: hidden-ns-2.internal acl: hidden-ns-1.internal acl: hidden-ns-2.internal semantic-checks: false global-module: mod-rrl/default zone: - domain: zone.fi -- Juha Suhonen Senior Systems Specialist CSC - Tieteen tietotekniikan keskus Oy juha.suhonen(a)csc.fi

1 rok, 4 měsíce

2
1
0 0

Set propagation-delay based on multiples of SOA TTL, doable?

by Michael Grimm

Hi, I wonder if it would be possible that one may use arithmetics in knot.conf such as: propagation-delay: 5 * dnskey-ttl I'd like to set a propagation-delay safety net during ZSK rotations depending on SOA TTL set for any given zone. As dnskey-ttl defaults to zone SOA TTL that would allow for propagation-delay definitions as multiples of SOA TTLs. As I couldn't find that in the documentation, I do assume that this cannot be done, right? Are there alternatives at hand I overlooked? Regards, Michael

1 rok, 4 měsíce

2
2
0 0

keymgr segmentation fault

by Erik P. Ostlyngen

Hi, I'm evaluating the Knot DNS server as a DNSSEC signer engine. I'm currently running version 3.2.6 together with SoftHSM version 2.6.1 on an Ubuntu 20.04 linux server. Now I have a problem with keymgr crashing with a segmentation fault and dumping core. This happens with some of the commands of keymgr, but not all (the command keymgr -l runs fine). The commands 'keymgr trondheim.no list' produces the correct output, but then crashes. /var/log/apport.log indicates that a dbus session is missing in the environment: ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: called for pid 811052, signal 11, core limit 0, dump mode 2 ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: not creating core for pid with dump mode of 2 ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: executable: /usr/sbin/keymgr (command line "keymgr trondheim.no list") ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment ERROR: apport (pid 811054) Tue Jun 13 07:56:00 2023: apport: report /var/crash/_usr_sbin_keymgr.0.crash already exists and unseen, skipping to avoid disk usage DoS Running the command as 'dbus-run-session keymgr trondheim.no list' gives: ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: called for pid 811173, signal 11, core limit 0, dump mode 2 ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: not creating core for pid with dump mode of 2 ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: executable: /usr/sbin/keymgr (command line "keymgr trondheim.no list") ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: is_closing_session(): Could not determine DBUS socket. ERROR: apport (pid 811174) Tue Jun 13 08:01:04 2023: apport: report /var/crash/_usr_sbin_keymgr.0.crash already exists and unseen, skipping to avoid disk usage DoS I've tried to run the command as root and as the knot user, and I have to admit that I'm not very familiar with how to manage dbus sessions. I want to run the keymgr command from cron or from some other system shell, for periodically monitoring the keys. However, I'm unsure why keymgr wants to communicate on the dbus. Is it possible to disable this? Regards, Erik Østlyngen

1 rok, 4 měsíce

2
2
0 0

DDNS not working as expected

by JeeF Software spol. s r.o.

Hi Knot-DNS Support, I'm trying simple DDNS scenario (no keys, no DNSSEC) with failing result. Knot-DNS is installed from docker image. Could you let me know what is the issue (NOAUTH) and how can I solve it or if this scenario is not supported what exactly is required by DDNS? ------------------------------------------- knot.conf: server: rundir: "/rundir" user: knot:knot automatic-acl: on listen: 0.0.0.0@53 log: - target: stdout server: debug zone: debug any: debug database: storage: "/storage" acl: - id: acl_update action: update - id: acl_transfer action: transfer template: - id: default storage: "/storage" file: "%s.zone" zone: # Primary zone - domain: example.com acl: [acl_update, acl_transfer] ---------------------------------------------- update: server 10.2.0.88 zone exmaple.com update add _acme-challenge.example.com. 300 TXT "aaaaa" send -------------------------------------------- knsupdate -d < update ;; DEBUG: cmd_server: lp='10.2.0.88' ;; DEBUG: parse_host: parsed addr: 10.2.0.88 ;; DEBUG: cmd_zone: lp='exmaple.com' ;; DEBUG: cmd_update: lp='add _acme-challenge.example.com. 300 TXT "aaaaa"' ;; DEBUG: cmd_add: lp='_acme-challenge.example.com. 300 TXT "aaaaa"' ;; DEBUG: cmd_send: lp='' ;; DEBUG: sending packet ;; DEBUG: pkt_sendrecv: send_msg = 3 ;; DEBUG: pkt_sendrecv: receive_msg = 29 ;; ->>HEADER<<- opcode: UPDATE; status: NOTAUTH; id: 27029 ;; Flags: qr; ZONE: 1; PREREQ: 0; UPDATE: 0; ADDITIONAL: 0 ;; ZONE SECTION: ;; exmaple.com. IN SOA ;; ERROR: update failed with error 'NOTAUTH' ;; DEBUG: operation 'send' failed (failed) on line 'send' ;; DEBUG: srv_info_free: null parameter ----------------------------------------- knotd log 2023-09-05T17:16:35+0000 info: Knot DNS 3.3.0 starting 2023-09-05T17:16:35+0000 info: loaded configuration file '/config/knot.conf', mapsize 500 MiB 2023-09-05T17:16:35+0000 info: using UDP reuseport, incoming TCP Fast Open 2023-09-05T17:16:35+0000 info: binding to interface 0.0.0.0@53 2023-09-05T17:16:35+0000 info: changing GID to 8521 2023-09-05T17:16:35+0000 info: changing UID to 9396 2023-09-05T17:16:35+0000 info: loading 1 zones 2023-09-05T17:16:35+0000 info: [example.com.] zone will be loaded 2023-09-05T17:16:35+0000 info: starting server 2023-09-05T17:16:35+0000 info: [example.com.] zone file parsed, serial 2010111213 2023-09-05T17:16:35+0000 info: [example.com.] loaded, serial none -> 2010111213, 465 bytes 2023-09-05T17:16:35+0000 info: control, binding to '/rundir/knot.sock' 2023-09-05T17:16:35+0000 info: server started in the foreground, PID 8 2023-09-05T17:18:03+0000 info: [example.com.] control, received command 'zone-status' 2023-09-05T17:18:40+0000 info: [example.com.] control, received command 'zone-sign' 2023-09-05T17:18:40+0000 error: [example.com.] control, error (operation not supported) 2023-09-05T17:18:52+0000 info: [example.com.] control, received command 'zone-read' 2023-09-05T17:18:56+0000 info: [example.com.] control, received command 'zone-read' 2023-09-05T17:18:56+0000 error: [example.com.] control, error (no such node in zone found) 2023-09-05T17:19:00+0000 info: [example.com.] control, received command 'zone-read' 2023-09-05T17:19:45+0000 info: [example.com.] control, received command 'zone-set' 2023-09-05T17:19:45+0000 error: [example.com.] control, error (no active transaction) 2023-09-05T17:22:57+0000 info: [example.com.] control, received command 'zone-set' 2023-09-05T17:22:57+0000 error: [example.com.] control, error (no active transaction) 2023-09-05T17:23:49+0000 info: [example.com.] control, received command 'zone-begin' 2023-09-05T17:23:54+0000 info: [example.com.] control, received command 'zone-set' 2023-09-05T17:24:02+0000 info: [example.com.] control, received command 'zone-commit' 2023-09-05T17:24:02+0000 info: [example.com.] zone file updated, serial 2010111213 -> 2010111214 btw. no info positive/negative regarding the DDNS -------------------------------------- example.com.zone example.com. 3600 SOA dns1.example.com. hostmaster.example.com. 2010111214 21600 3600 604800 86400 example.com. 3600 A 1.2.3.4 example.com. 3600 NS dns1.example.com. example.com. 3600 NS dns2.example.com. example.com. 3600 MX 10 mail.example.com. dns1.example.com. 3600 A 192.0.2.1 dns1.example.com. 3600 AAAA 2001:db8::1 dns2.example.com. 3600 A 192.0.2.2 dns2.example.com. 3600 AAAA 2001:db8::2 mail.example.com. 3600 A 192.0.2.3 mail.example.com. 3600 AAAA 2001:db8::3 Thanks. Best Regards, JohnF

1 rok, 4 měsíce

2
1
0 0

NSEC3 RR not generated, dunno why.

by Michael Grimm

Hi, I am still very new to knot ;-) FYI: This is Knot DNS 3.3.3 because 3.3.4 hasn't been shown up in FreeBSD's ports collectioon, yet. Here are my settings regarding dnssec policy: policy: - id: ecdsa algorithm: ecdsap256sha256 ksk-lifetime: 3650d zsk-lifetime: 330d propagation-delay: 1d nsec3: on cds-cdnskey-publish: rollover Whatever I tell nsec3, either "on" or "true", only NSEC RR are generated, no NSEC3. dns> grep -i nsec3 zones/ellael.org dns> dns> grep -i nsec zones/ellael.org 3600 IN RRSIG NSEC 13 2 3600 20240226084528 20240212071528 9562 ellael.org. fkpFcgkVq8ZRZT0GX5kVcfPZBB5S/2Gvh4XqrkrywbZXFKiCttYqCX7rBdJSbyem5G8Bxg1LKaxu7LrIoxtyVA== 3600 IN NSEC _dmarc.ellael.org. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY CAA 3600 IN RRSIG NSEC 13 3 3600 20240226084528 20240212071528 9562 ellael.org. R7Pz2JuKi7vQDe0KMt29NHGtKvuEnH2LPKcxTWLP9HyfuMxJx4BEyPE6i+JAw8RxfSIqWAcV/KMyCHaLgFtXXw== 3600 IN NSEC _token._dnswl.ellael.org. TXT RRSIG NSEC 3600 IN RRSIG NSEC 13 4 3600 20240226084528 20240212071528 9562 ellael.org. 3oUCWWTH2s9oH/Ea0b+MDrrQcOEuTbwx1iEuXaLq7wFribrnIGY8JeeiE3TO59n1lckKm4hia+2ox324xoxCzA== [snip] What am I doing wrong? Thanks in advance and kind regards, Michael

1 rok, 4 měsíce

2
4
0 0

How to check for next KSK or ZSK rollover dates?

by Michael Grimm

Hi, I am very new to Knot [1]. Excerpts from my knot.conf: policy: ... ksk-lifetime: 3650d zsk-lifetime: 330d propagation-delay: 1d ... dns> knotc zone-status ellael.org [ellael.org.] role: master | serial: 2024021201 | re-sign: +12D8h42m21s I am a bit puzzled by that "re-sign: +12D8h42m21s". Does that mean "time until newly issued signatures" and becomes triggered by default "rrsig-lifetime: 14d" value? If so, I am very much relieved, if not, what is going on, then? Here is my question: How can I find out the dates for upcoming KSK or ZSK rollovers? This I couldn't find in the documentation, sorry. Thanks and regards, Michael [1] I've been bitten by that subtle bug in mailing list processing system ;-) My questions regarding migration strategy has become obsolete in the meantime, because I managed to migrate successfully. Thanks to the great documentation of Knot I could help myself ;-)

1 rok, 4 měsíce

2
2
0 0

GUI Frontends for Knot DNS Server

by Turritopsis Dohrnii Teo En Ming

Subject: GUI Frontends for Knot DNS Server Good day from Singapore, Are there any GUI frontends for configuring Knot DNS Server? I prefer GUI configuration interface. It is more efficient than command line interface (CLI). Thank you. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com

1 rok, 4 měsíce

2
1
0 0

kresd not starting with lua error

by Mike Wright

Hello, Running knot-resolver 5.6.0-1 amd64 (latest available via apt) on debian-12 bookworm, fully upgraded. systemctl start kresd@1 fails to run. systemctl status kresd@1 shows the following errors: [system] error while loading config: ...b/x86_64-linux-gnu/knot-resolver/kres_modules/policy.lua:378: bad argument #1 to 'create' (table expected, got nil) (workdir '/var/lib/knot-resolver') Here is my kresd.conf. It had been running ok for a long time ( I don't recall making any changes) : - Default empty Knot DNS Resolver configuration in -*- lua -*- -- Bind ports as privileged user (root) -- net = { '127.0.53.0' } -- Switch to unprivileged user -- user('knot-resolver','knot-resolver') -- Unprivileged -- cache.size = 100*MB policy.add(policy.suffix(policy.FLAGS({'NO_CACHE'}), internalDomains)) policy.add(policy.suffix(policy.STUB({'127.53.0.0'}), internalDomains)) policy.TLS_FORWARD({ -- multiple servers can be specified for a single slice -- the one with lowest round-trip time will be used {'9.9.9.9', hostname='dns.quad9.net'}, {'149.112.112.112', hostname='dns.quad9.net'}, }) All help is greatly appreciated, Mike Wright

1 rok, 4 měsíce

2
1
0 0

warning - a few lost e-mails to the mailing list

by David Vasek

Dear mailing list subscribers, due to a subtle bug in our mailing list processing system, a few emails sent to the mailing list <knot-dns-users(a)lists.nic.cz> over the past two years were blocked and awaiting approval without our knowledge. After filtering out spam, we will review what we believe is still relevant and reach out to the senders directly in the coming days. If your email did not pass through the moderation phase, please resend it to the list after the middle of next week. We are sorry for this issue. Our thanks go to Juha Suhonen who helped us discover the problem by pointing out that his email is still waiting. Thank you, Juha. Best regards, David Vašek, Knot DNS team

1 rok, 4 měsíce

1
0
0 0

Knot DNS 3.3.4 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.4! This is a bugfix version with some enhancements. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.3.4 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

1 rok, 5 měsíců

1
0
0 0

TSIG key in remote and acl

by Einar Bjarni Halldórsson

Hi, I’m updating our config files and I’m wondering if we need to set ‘key’ in remotes section, and in acl section? If I have this in my config: remote: - id: remote01 address: 127.0.0.1 key: my_key acl: - id: allow_transfer address: 127.0.0.1 key: my_key action: transfer zone: - domain: example.com acl: [ allow_transfer ] notify: [ remote01 ] Couldn’t I just remove key attribute from the remote, since the acl declares the address and key that are allowed to transfer the zone? .einar

1 rok, 5 měsíců

4
6
0 0

Knot DNS 3.2.12 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.12! This version only backports some fixes from 3.3.3. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.2.12 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

1 rok, 6 měsíců

1
0
0 0

Knot DNS 3.3.3 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.3! This is mostly a bugfix version. Upgrade is recommended for QUIC and TCP/XDP users. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.3.3 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

1 rok, 6 měsíců

1
0
0 0

Knot DNS 3.2.11 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.11! This version only backports some fixes from 3.3.2. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.2.11 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

1 rok, 7 měsíců

1
0
0 0

Message compression (was: Re: Knot DNS 3.3.2 release)

by Robert Edmonds

Daniel Salzman wrote: > Hello Knot DNS users, > > CZ.NIC has released Knot DNS 3.3.2! > > This version fixes various issues and introduces some features regarding IXFR. > Users of PKCS #11 keystore might appreciate improved signing performance using more thread. > > Note that the offline KSK mode requires explicit setting of `rrsig-refresh` on the KSK side! > > Changelog: > https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.3.2/NEWS Hi, I'm interested in this change: - knotd: failed to sign RRSet that fits to 64k only if compressed Which seems to be this commit: https://gitlab.nic.cz/knot/knot-dns/-/commit/f55037f6f39d0ddf6debac47fe168d… "libknot/knot: allow uncompressed wire conversion of rrset that fits to 64k only when compressed" It's not totally clear to me, but it seems like this would allow an RRset (or individual RR, if the number of RRs in the RRset is 1?) that, exceeds 64K, if name compression would reduce the size on the wire to <64K? (And the 64K isn't measured by just the RDATA/RDLEN fields, but rather the whole wire serialization of the record set, including owner name, type, class, TTL, etc.) If so, is this a safe and/or interoperable thing to do? DNS implementations are required to implement decompression, but compression is optional (RFC 1035 § 4.1.4). So a resolver might receive a compressed RRset, decompress it, and then be unable to represent that RRset to clients if it doesn't implement compression, or, more likely, implements compression but uses an algorithm that generates less optimal compression targets than the one used by the original nameserver. Or am I misunderstanding what this commit is doing? Thanks! -- Robert Edmonds edmonds(a)debian.org

1 rok, 8 měsíců

2
1
0 0

Knot DNS 3.3.2 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.2! This version fixes various issues and introduces some features regarding IXFR. Users of PKCS #11 keystore might appreciate improved signing performance using more thread. Note that the offline KSK mode requires explicit setting of `rrsig-refresh` on the KSK side! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.3.2/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

1 rok, 8 měsíců

1
0
0 0

Knot DNS 3.3.1 and 3.2.10 releases

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.1 and 3.2.10! These versions fix several bugs. Upgrade is recommended. Changelogs: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.3.1/NEWS https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.10/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

1 rok, 9 měsíců

1
0
0 0

Knot DNS 3.3.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.0! This version brings full DNS/XFR over QUIC support, multi-signer operation mode, and many more. See the changelog. Debian and Ubuntu users can download the packages from a new repository https://pkg.labs.nic.cz/doc/?project=knot-dns This repository is common to both distributions and Knot versions (older versions must be pinned). Additionally, the repository will contain some historical Knot versions. Prometheus exporter https://github.com/salzmdan/knot_exporter (a fork of https://github.com/ghedo/knot_exporter) has been replaced with https://pypi.org/project/knot-exporter/ and distribution package knot-exporter (currently for Debian and Ubuntu). Today Knot DNS 3.1 reached its End-of-life! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.3.0/NEWS Migration: https://www.knot-dns.cz/docs/latest/html/migration.html#upgrade-3-2-x-to-3-… Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

1 rok, 9 měsíců

3
3
0 0

Understanding block-notify-after-transfer

by Jan-Piet Mens

Hello! I have a Knot 3.2.5 server running here which, for most zones, acts as a bump-in-the-wire signer, and it's doing exactly what I expect it to do. The same server carries a few secondary zones which are not signed, and I notice that when Knot transfers these zones in, it doesn't NOTIFY its secondaries, something which works fine for DNSSEC signed zones. The following configuration is in place: remote: - id: pdns address: 192.168.25.45@53 key: dsupload block-notify-after-transfer: on # <------- automatic-acl: on template: - id: default zonefile-load: difference file: "%s" serial-policy: dateserial master: pdns catalog-role: member catalog-zone: katz1 acl: [ xfr, notify_from_pdns, xfer_to_bind ] notify: [ s1, s2, s3 ] policy: - id: manualHSM manual: on keystore: thales cds-cdnskey-publish: rollover ksk-submission: ds_checker ds-push: pdns zone: - domain: sig.example dnssec-policy: manualHSM dnssec-signing: on - domain: notsig.example dnssec-signing: off When sig.example is transferred in, Knot signs it, NOTIFYs its secondaries (s1--s3), they XFR the zone and all's well. When the unsigned notsig.example is transferred in, the logs indicate Knot is seeing the new serial, and that's it; the secondaries are not NOTIFYd. (I can manually `knotc notify', but that's not the point.) Setting `block-notify-after-transfer: off' on the remote remediates this. Knot then does NOTIFY its secondaries for the unsigned zone (and for the signed zone). The documentation states: "When incoming AXFR/IXFR from this remote (as a primary server), suppress sending NOTIFY messages to all configured secondary servers." However, if I swich it off (i.e. enable notification), I do not see the NOTIFY when knot initially transfers the unsigned zone which is then signed and hence then notified. Is this behavior expected, and have I interpreted it correctly? Thanks & best regards, -JP

1 rok, 10 měsíců

2
2
0 0

Knot DNS 3.2.9 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.9! This is a bug fix version. Upgrade is recommended. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.9/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

1 rok, 11 měsíců

1
0
0 0

Is it safe to alter dnssec-policy for a zone?

by Jan-Piet Mens

I have a zone for which I'd like to ensure an admin cannot mistakenly kick off a KSK rollover, so I am considering setting configuring its dnssec-policy to one with `manual: on' which prevents even a `knotc zone-key-rollover' on it. I have experimented with switching `manual: on' to `manual: off', and the idea seems to work. I have also apparently successfully been able to alter `ksk-lifetime', and have not noticed anything going wrong. Based on this, I wish to know if it is considered safe to alter many (all?) of a policy's settings, as long as neither algorithm nor key sizes are changed, and whether it is safe to alter the policy itself (i.e. also change a policy name for a zone). ksk-lifetime, delays, rrsig-lifetimes, ksk-submission, etc.: can all these be changed without breaking signing of a zone? Thank you & regards, -JP

1 rok, 11 měsíců

2
2
0 0

zone event 'flush' on catalog?

by Jan-Piet Mens

Hello! I have here a catalog zone with roughly 230 member zones in it, and I occasionally see the following warning/error in the log: 2023-07-12T18:01:17+0200 warning: [k-catalog.] failed to update zone file (operation not permitted) 2023-07-12T18:01:17+0200 error: [k-catalog.] zone event 'flush' failed (operation not permitted) The catalog itself appears to work correctly; it's transferred to secondary BIND servers and they correctly process member zones. template: - id: default storage: "..." zonefile-load: difference file: "%s" serial-policy: dateserial master: pdns catalog-role: member catalog-zone: k-catalog acl: [ xfr, notify_from_pdns, xfer_to_bind ] - id: catzonetemplate catalog-role: generate acl: xfer_to_bind zone: - domain: k-catalog semantic-checks: off template: catzonetemplate journal-content: none acl: [ xfr, xfer_to_bind ] While pasting the configuration it occurs to me it might be due to there not being a 'backing' file for the catalog. Is that the problem? Is it even possible on a catalog-role:generate to have a file? Thanks for your help. -JP

1 rok, 11 měsíců

2
2
0 0

catalog-role:interpret broken since upgrade to knot 3.2.6

by Daniel Gröber

Hi Knotty people, I've started uprading my infrastructure to Debian 12 which comes with knot 3.2.6 (instead of 3.0.5) and since the upgrade my catalog zone configuration doesn't seem to work anymore. I have this in knot.conf: zone: - domain: dxld.catalog catalog-role: interpret catalog-template: dxld-master template: dxld-master dxld.catalog gets loaded properly, `knotc zone-read dxld.catalog`: [dxld.catalog.] dxld.catalog. 0 SOA ns0.dxld.at. hostmaster.dxld.at. 2023070601 900 300 86400 300 [dxld.catalog.] version.dxld.catalog. 0 TXT "2" [dxld.catalog.] zones.dxld.catalog. 0 PTR dxld.at. [dxld.catalog.] zones.dxld.catalog. 0 PTR dxld.net. [dxld.catalog.] zones.dxld.catalog. 0 PTR darkboxed.org. but the zones pointed to don't get instantiated (as seen by `knotc zone-status`). Any ideas what could have changed to break this? Thanks, --Daniel

1 rok, 11 měsíců

4
5
0 0

Knot DNS 3.2.8 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.8! This is a bug fix version. Upgrade is recommended for users of version 3.2.7 with journal enabled. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.8/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

1 rok, 12 měsíců

1
0
0 0

Failed to load journal (loop detected)

by Ondřej Caletka

Hey, after an (unattended) upgrade to 3.2,7, one of my zones (the one that does rapid KSK rollovers) failed to load. Trying ro reload emits these errors in the log: info: [83.204.91.in-addr.arpa.] zone file parsed, serial 1622013488 error: [83.204.91.in-addr.arpa.] failed to apply journal changes, serial 1622013488 -> 1686209286 (loop detected) 2023-06-23T12:11:57+0200 error: [83.204.91.in-addr.arpa.] failed to apply journal changes, serial 1622013488 -> 1686209286 (loop detected) warning: [83.204.91.in-addr.arpa.] failed to load journal (loop detected) 2023-06-23T12:11:57+0200 warning: [83.204.91.in-addr.arpa.] failed to load journal (loop detected) info: [83.204.91.in-addr.arpa.] zone not found error: [83.204.91.in-addr.arpa.] zone event 'load' failed (not exists) 2023-06-23T12:11:57+0200 error: [83.204.91.in-addr.arpa.] zone event 'load' failed (not exists) Calling `kjournalprint 83.204.91.in-addr.arpa` yields 600 lines of journal full of both additions and deletions, nothing seems particularly wrong. Is there anything I should try before purging the journal and starting from scratch? There are other zones on the same server with similar config that just work normally, so I guess this is somehow related to the size of the journal for this zone, which rotates DNSSEC keys very often. -- Cheers, Ondřej Caletka

2 roky

2
1
0 0

TCP requirement for catalog zones breaks interoperability

by Matthew Pounsett

The 3.0 documentation for catalog zones says the following: «The difference is that standard DNS queries to a catalog zone are answered with REFUSED as though the zone doesn’t exist, unless querying over TCP from an address with transfers enabled by ACL.» This seems like an odd requirement, and it breaks interoperability with other vendors' authoritative servers. BIND, for example, does not send the SOA check for a zone transfer over TCP, and so it's impossible to use a Knot primary and BIND secondary with catalog zones. Is there some way to work around this?

2 roky

2
2
0 0

Knot DNS 3.2.7 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.7! This is a bugfix version with some improvements. Please note that the 3.3.0 version will be released in August and the 3.1 branch will no longer be officially supported. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.7/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

2 roky

1
0
0 0

Monitor journal usage

by Einar Bjarni Halldórsson

Hi, Yesterday we got hit by the per-zone journal becoming full [1] As a result we're looking into how we can monitor the status to warn us if we're near the journal limits, but I can't find a way to report the currant journal usage (global and per-zone). Any ideas? [1] https://gitlab.nic.cz/knot/knot-dns/-/issues/842

2 roky, 1 měsíc

3
4
0 0

Knot DNS 3.2.6 release

by Daniel Salzman

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

2 roky, 2 měsíce

1
0
0 0

kresd 5.4.4 socket bug

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

2 roky, 3 měsíce

1
0
0 0

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

2 roky, 4 měsíce

4
14
0 0

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

2 roky, 4 měsíce

1
0
0 0

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

2 roky, 4 měsíce

2
7
0 0

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

2 roky, 6 měsíců

1
0
0 0

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

2 roky, 7 měsíců

1
0
0 0

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

2 roky, 7 měsíců

2
2
0 0

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

2 roky, 7 měsíců

1
0
0 0

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

2 roky, 9 měsíců

1
0
0 0

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é

2 roky, 9 měsíců

3
6
0 0

knot 3.2 fails to access HSM key

by Bastien Durel

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

2 roky, 10 měsíců

2
9
0 0

Knot DNS 3.2.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.2.0! This version brings various XDP-related features and improvements (namely QUIC and TCP) and many more. See the changelog. As usual, today Knot DNS 3.0 reached its End-of-life. The official repositories are being updated this way: current stable -> 3.2.0, previous stable -> 3.1.9. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.0/NEWS Migration: https://www.knot-dns.cz/docs/3.1/html/migration.html#upgrade-3-1-x-to-3-2-x 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

2 roky, 10 měsíců

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users