knot-dns-users

knot-dns-users@lists.nic.cz

4 participants
761 discussions

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

2 roky, 2 měsíce

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

2 roky, 3 měsíce

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.

2 roky, 3 měsíce

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

2 roky, 3 měsíce

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

2 roky, 3 měsíce

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

2 roky, 3 měsíce

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

2 roky, 4 měsíce

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

2 roky, 4 měsíce

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

2 roky, 4 měsíce

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

2 roky, 4 měsíce

← Newer
1
...
6
7
8
9
10
11
12
...
77
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users