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

by Michael Grimm

Hi, until now I had 3 secondaries running and a hidden primary. This ran perfectly well. Now, I'd like to add some fallback functionality to deal with a potential longer downtime of my hidden primary. Thus I added two more hidden primaries such that now every host (3) has a hidden primary that can serve every secondary at all hosts. But: Only one should be active! Zone and database data will frequently be rsynced to both inactive primaries. If there would be a downtime I will have to start one of the others to continue. According to my understanding of https://www.knot-dns.cz/docs/3.5/html/configuration.html#secondary-slave-zo… I have been in the naive understanding that a configuration like ... remote: - id: primaryMWN # MWN hidden primary (running) address: 10.0.1.203@5333 - id: primaryKBN # KBN hidden primary (not running, standby) address: 10.0.2.203@5333 - id: primaryEDN # EDN hidden primary (not running, standby) address: 10.0.3.203@5333 template: - id: default master: [primaryMWN, primaryKBN, primaryEDN] # queried in that order … would work, because of: "Note that the master option accepts a list of remotes, which are queried for a zone refresh sequentially in the specified order. When the server receives a zone change notification from a listed remote, only that remote is used for a subsequent zone transfer." But I do get error massages like: edn.ellael.lan (ns3) knot[29856]: warning: [ellael.org.] refresh, remote primaryKBN not usable edn.ellael.lan (ns3) knot[29856]: info: [ellael.org.] refresh, remote primaryEDN, address 10.0.3.203@5333, failed (connection reset) edn.ellael.lan (ns3) knot[29856]: warning: [ellael.org.] refresh, remote primaryEDN not usable edn.ellael.lan (ns3) knot[29856]: error: [ellael.org.] refresh, failed (no usable master), next retry at 2026-04-27T19:03:03+0200, expires in 1119353 seconds edn.ellael.lan (ns3) knot[29856]: error: [ellael.org.] zone event 'refresh' failed (no usable master) If I do use "master: primaryMWN" only, everything runs as expected. I must have misunderstood something ... Ok, I will have to modify all remaining secondary's knot.conf files if desaster strikes and another primary has to take over. BTW: I wanted to omit a multi primary setup as mentioned in https://www.knot-dns.cz/docs/3.5/singlehtml/#multi-primary because I do have the feeling that this is some sort of overkill for hosting 5 domains, only ;-) Are there other ways to achieve my goal? ;-) Thanks and regards, Michael

1 měsíc

3
7
0 0

Knot DNS 3.5.4 and 3.4.10 releases

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.5.4. This is a bug fix version with some improvements. Upgrade is recommended, especially for those who use the module for online DNSSEC signing (mod-onlinesign)! Version 3.4.10 backports some of the bug fixes. Changelogs: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.5.4/NEWS https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.4.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 měsíc

2
3
0 0

Adding ALIAS local resolution to knot-dns

by brong＠fastmailteam.com

Hi, Fastmail has been running Knot for a few years now. Thank you for such excellent software! I'm new to this list, and new to the Knot codebase, but I'm an experienced C developer and have been working on Cyrus IMAPd (a mostly C codebase) for many years. We have hundreds of thousands of domains, and currently they all have the same set of service IPs compiled into them. This has generally been fine - setting up a new server takes an hour or so to build all the domains, but we just wait until it's done then bring it into rotation. Our current challenge -- we want to be able to transfer everything to a new IP range quickly for datacenter failover. Rebuilding every zone is too expensive for this. I looked at a few different issues and (along with Claude) figured that it wasn't much work to extend the ALIAS type to follow the pointer to another zone inside the same server and return the records from that. I have an initial pass at: https://github.com/fastmail/knot-dns/tree/local-alias-synth For now I've kept it as separate commits showing the evolution of the idea as I've tested it more and thought through how I want it to interact (basically any ALIAS get substituted with the contents of the name it points to, so you can mix and match them all sorts of ways). I'm very happy to engage on testing and modifying this code to match what the upstream project wants; or revisit the approach if this doesn't match your vision. I just need something that has these properties, and this seemed a good way to get there. Thanks, Bron.

1 měsíc, 1 týden

4
7
0 0

Seeking signing stats with significant speed

by Leo Vandewoestijne

Hello, In this other use-case, described in the thread "IXFR commit time scaling", there was a reply refering to https://www.knot-dns.cz/docs/3.5/singlehtml/#signing-threads and https://www.knot-dns.cz/docs/3.5/singlehtml/#adjust-threads Which made me wonder... a] you can have an external networked HSM, which sounds promising to speed up signing a lot... b] nowadays you also have even 128 core processers, even mutiple CPU slots, which sounds as a immense boost for co-proccesing... c] you could combine those... Clinical data would propably be hard, but hypothetical/esitimated; what would be wise/pointless/smart/insane to increase signing of large zones? I'd expect that RAM speed is a major factor also. What would be an ideal setup today? -- With kind regards, Met vriendelijke groet, Mit freundlichen Grüß, Leo Vandewoestijne <***(a)dns.company> <www.dns.company>

2 měsíce, 2 týdny

2
1
0 0

IXFR commit time scaling

by Jonathan Reed

Hi Knot team, I'm running Knot as an Auth secondary receiving IXFR from a BIND 9 primary. To isolate bottlenecks I've stripped the config down as far as I know how. Here's what I'm using. zonefile-sync: -1 zonefile-load: none journal-content: none There is no DNSSEC or any downstream IXFR serving happening. Logs are confirming that it is genuine IXFR and no signs of any AXFR fallback. "semantic-checks" is off, and knotd is linked against jemalloc. I'm really trying to make this as quick as possible by avoiding the disk. The pattern: IXFR processing time scales roughly proportionally with total zone size, even when the changeset is small, for example, a few hundred RRs out of several hundred thousand. There is what appears to be a full zone walk on every IXFR commit in the adjust logic, with single threaded execution due to parent befroe child ordering requirements. Although I'd want your confirmation before reading too much into it. Questions: 1. With journal-content: none, does IXFR apply trigger a full in-memory tree walk of the QP-trie, rather than an isolated incremental record-level update? If so, is that a necessary consequence of running without a journal to maintain state? 2. For a secondary with no NSEC/NSEC3, no wildcards or any downstream IXFR'ing, could a "lightweight secondary" mode bypass post-apply bookkeeping that might only be targetted to primaries and signers? 3. Could it rewalk only subtrees where adds or removes happen to their ancestors, rather than the full zone? If NSEC is absent, is the prev pointer chain actually used at query time, or can it be skipped entirely? Our use case is secondary-only, with large zones and high frequency updates. We're hoping there is something on the configuration or roadmap side that might help, and ultimately not sure if we're just bumping up against a realistic constraint. Thanks for the great software btw, loving it. Thanks!

2 měsíce, 2 týdny

2
4
0 0

How to trigger catalog zone generation

by Billiam Crashkopf

Hi all, I just set up catalog zones for the first time. I'm using a conf file with my list of zones. After creating a catalog zone and adding member zones to it, I executed 'knotc reload'. The catalog zone then appeared in the output of 'zone-status', and member zones were listed with the catalog zone name. However, 'zone-read <catalog.zone>' showed no PTR records. I tried 'zone-reload <catalog.zone>', updated serials on the member zones and such, but the catalog zone remained empty until knotd was restarted. I saw this behavior on both 3.4.4 and 3.5.2. Is this the intended behavior? Is there a way to generate the catalog without restarting knotd? Thanks in advance, Bill

4 měsíce

2
1
0 0

Knot DNS 3.5.3 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.5.3! This version brings some improvements and a few bug fixes. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.5.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

4 měsíce, 2 týdny

1
0
0 0

[help] about zone transfer via QUIC

by SUN Guonian

Greetings, I have tried to use QUIC in zone transfering, I met one error in on bigger zone, from master's log, it displayed, 2026-01-04T17:32:19+0800 debug: [foo.] ACL, allowed, action transfer, remote 10.0.0.147@60880 QUIC cert-key xJKsDkUqpl6orXeTwsrDgDvgZ/PiYxOSVlOkVdn5EOU= 2026-01-04T17:32:19+0800 info: [foo.] IXFR, outgoing, remote 10.0.0.147@60880 QUIC, incomplete history, serial 2026010403, fallback to AXFR 2026-01-04T17:32:19+0800 debug: [foo.] ACL, allowed, action transfer, remote 10.0.0.147@60880 QUIC cert-key xJKsDkUqpl6orXeTwsrDgDvgZ/PiYxOSVlOkVdn5EOU= 2026-01-04T17:32:19+0800 info: [foo.] AXFR, outgoing, remote 10.0.0.147@60880 QUIC, started, serial 2026010404 2026-01-04T17:32:20+0800 info: [foo.] AXFR, outgoing, remote 10.0.0.147@60880 QUIC, buffering finished, 0.87 seconds, 7390 messages, 124493148 bytes 2026-01-04T17:32:20+0800 notice: QUIC, terminated connections, outbuf limit 1 on the slave side, I got log as, 2026-01-04T17:32:18+0800 info: [foo.] zone file loaded, serial 2026010403 2026-01-04T17:32:19+0800 info: [foo.] loaded, serial none -> 2026010403, 92000117 bytes 2026-01-04T17:32:19+0800 info: [foo.] refresh, remote 10.0.0.151@853, remote serial 2026010404, zone is outdated 2026-01-04T17:32:19+0800 info: server started (and, the knotd on slave will down without log.) Thanks in advance. My testing environment is, the zone size is 1,000,000 x ( 2 NS + 2 A ), such as, domain00000000 3600 NS ns1.domain00000000 3600 NS ns2.domain00000000 ns1.domain00000000 3600 A 10.0.0.1 ns2.domain00000000 3600 A 10.0.0.2 ... domain00999999 3600 NS ns1.domain00999999 3600 NS ns2.domain00999999 ns1.domain00999999 3600 A 10.0.0.1 ns2.domain00999999 3600 A 10.0.0.2 If I decrease the record number to 500,000 x ( 2 NS + 2 A ), the zone could be transfer with QUIC successfully. For traditional TCP and TLS, the zone transfer is processed without error, even for more large size. Version in master and slave are both 3.5.2, installed from copr. OS in both side is Rocky9 x86_64. Best Regards, SUN Guonian

4 měsíce, 3 týdny

2
9
0 0

Usage about notify, how to define notify behaviour

by SUN Guonian

Greetings, If I do not configure a "notify" statement in the zone section, I notice that Knot DNS still sends NOTIFY messages to all servers in the NS records. How can I disable NOTIFY messages on a server that is at the end of the zone transfer link (e.g., a stealth or receiving-only secondary)? Best Regards, SUN Guonian

5 měsíců

3
3
0 0

TCP Fast Open deprecation

by Daniel Salzman

Hello Knot DNS users, Knot DNS supports TCP Fast Open (when configured) in both the server and client roles for several years. However, we have not observed any performance or other improvements from this technology so far. Since removing it would simplify the code, I'm considering dropping the support for it. Is there anyone who would miss TFO in Knot DNS? For better XFR efficiency between Knots, https://www.knot-dns.cz/docs/latest/singlehtml/index.html#remote-pool-limit works much better. Thanks, Daniel

5 měsíců, 3 týdny

4
3
0 0

zone-ksk-submitted

by Einar Bjarni Halldórsson

Greetings, One thing I’m not sure about is exactly what happens when we run `knotc zone-ksk-submitted`? Our parent zones don’t support CDS/CDNSKEY, so we manually update DS records and then run `knotc zone-ksk-submitted`. It seems to me that as soon as we run it, the retiring of the outgoing KSK key starts and it’s removed from the DNSKEY RRset. Is that correct? I’d like to be sure, because as it is, I wait at least the TTL of the DS record before running zone-ksk-submitted, if I run it right away and knot removes the key immediately from the DNSKEY RRset, then caching resolvers will invalidate the zone. The docs for knotc say: Use when the zone's KSK rollover is in submission phase. By calling this command the user confirms manually that the parent zone contains DS record for the new KSK in submission phase and the old KSK can be retired. (#) Reading the docs, I would think I should run zone-ksk-submitted as soon as the new DS record has been published in the parent, but then knot would need to know to wait for the TTL of the DS record before removing the key. Should I wait before running zone-ksk-submitted, or is there a config option I’m missing to tell knot the ds ttl? .einar

5 měsíců, 3 týdny

4
4
0 0

ACL issues

by DiffieHellman

Hi, I'm having issues with ACL's and DNS updates and multiple DNS servers. I use DNS-01 for TLS letsencrypt and AXFR between the servers, but for some reason acme.sh is not working for a new server with "NOTAUTH" failures. (I give acme.sh export KNOT_SERVER='souseiseki.middlendian.com' so that it uses the master and that works fine on the master and another server, but for some reason on the new one there is an ACL related failure?); [Thu 04 Dec 2025 21:53:49 AEDT] Adding _acme-challenge.middlendian.com. 60 TXT "<snip>" ;; ->>HEADER<<- opcode: UPDATE; status: NOTAUTH; id: 42945 ;; Flags: qr; ZONE: 1; PREREQ: 0; UPDATE: 0; ADDITIONAL: 1 ;; ZONE SECTION: ;; middlendian.com. IN SOA ;; ADDITIONAL DATA: ;; TSIG PSEUDOSECTION: acme_key. 0 ANY TSIG hmac-sha512. 1764845629 300 64 <snip> 42945 NOERROR 0 ;; ERROR: update failed with error 'NOTAUTH' knsupdate works with the set key to the master; knsupdate knsupdate> server souseiseki.middlendian.com knsupdate> key hmac-sha512:acme_key:<snip> knsupdate> zone middlendian.com. knsupdate> add test.middlendian.com. 300 TXT test knsupdate> send knsupdate> answer But, the ACL seems to have problems, as DNS updates fail if attempted via any secondary server?; knsupdate knsupdate> server hinaichigo.middlendian.com knsupdate> key hmac-sha512:acme_key:<snip> knsupdate> zone middlendian.com. knsupdate> del test.middlendian.com TXT knsupdate> send ;; ->>HEADER<<- opcode: UPDATE; status: NOTAUTH; id: 14970 ;; Flags: qr; ZONE: 1; PREREQ: 0; UPDATE: 0; ADDITIONAL: 1 ;; ZONE SECTION: ;; middlendian.com. IN SOA ;; ADDITIONAL DATA: ;; TSIG PSEUDOSECTION: acme_key. 0 ANY TSIG hmac-sha512. 1764844872 300 64 <snip> 14970 NOERROR 0 ;; ERROR: update failed with error 'NOTAUTH' Knot on souseiseki outputs an error to syslog; "ACL, denied, action update, remote 125.63.60.124@38966 TCP" but that isn't helpful debug output, as it does not say why the ACL was denied. IP address related matching could be a problem, but reviewing the documentation, it seems to state that IP addresses are not considered in ACL's unless listed in the ACL? Does anyone know what the issue is and otherwise how do I debug it? All the servers have the same ACL key set; /etc/knot/acme.key; key: - id: acme_key algorithm: hmac-sha512 secret: <snip> souseiseki (master); remote: - id: suigintou address: [ 180.150.27.133@53, 2403:5806:e8d0::dead:beef:cafe@53 ] - id: hinaichigo address: 125.63.60.124@53 include: "/etc/knot/acme.key" acl: - id: acme_acl key: acme_key action: update zone: - domain: middlendian.com dnssec-signing: on acl: acme_acl notify: [ suigintou, hinaichigo ] hinaichigo (secondary); remote: - id: master address: 144.6.197.157@53 acl: - id: acme_acl key: acme_key action: [update, notify] zone: - domain: middlendian.com master: master acl: acme_acl -- Kind Regards, DiffieHellman

5 měsíců, 4 týdny

2
7
0 0

restore, key copy failed (already exists)

by Einar Bjarni Halldórsson

Hi, In our setup, we have one active signer and one backup signer. Both use softhsm, but only the active signer does automatic key management. There is an hourly cron job that syncs keys from active to backup signer. It runs knotc zone-backup on the active signer, only backing up the kaspdb. It then syncs the files over to the secondary and runs knotc zone-restore. This has been running for a few years now without problems. These last two weeks we’ve been performing algorithm rollovers for some of our zones, and after we run `knotc zone-ksk-submitted nic.is` we start seeing these errors when the zone-restore is run on the backup: error: [nic.is.] zone event 'backup/restore' failed (already exists) warning: [nic.is.] zone restore failed (already exists) warning: [nic.is.] restore, key copy failed (already exists) I searched the knot dns source code, but couldn't find where these errors are output. Like I said, we’ve been running like this for a few years, doing regular ZSK rollovers, and a few KSK rollovers, without problems. There’s something about the algorithm rollover that causes this problem with our setup. I assume I can just delete the keys on the secondary and sync again, but I want to understand what causes these errors so we can avoid them or at best document them in our process. .einar

6 měsíců

4
12
0 0

Knot DNS 3.5.2 and 3.4.9 releases

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.5.2. This is a bug fix version with some improvements. Version 3.4.9 backports several bug fixes. Note that the previous Debian repositories https://deb.knot-dns.cz/knot-latest/ and https://deb.knot-dns.cz/knot/ will no longer be updated and you should use https://pkg.labs.nic.cz/ instead. Changelogs: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.5.2/NEWS https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.4.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

6 měsíců

1
0
0 0

cache problem

by Randy Bush

debian 12 knot 5 so i believe i have a server with antique data in cache. the net of a million lies says use `kresctl clear foo` but i can not find kresctl. clue bat please randy

6 měsíců, 2 týdny

1
1
0 0

pkcs11 broken after upgrade to trixie

by Bastien Durel

Hello, I upgraded my signing server to Debian 13, but I have a problem with my HSM : Oct 15 21:09:18 arrakeen knotd[29552]: error: [durel.org.] zone event 'load' failed (PKCS #11 token not available) Oct 15 21:09:18 arrakeen knotd[29552]: error: [geekwu.org.] zone event 'load' failed (PKCS #11 token not available) keymgr gives me the same error : # keymgr geekwu.org list error: failed to initialize KASP (PKCS #11 token not available) despite hsmwiz being able to access the key : # hsmwiz identify Using reader with a card: Nitrokey Nitrokey HSM (DENK01067960000 ) 00 00 Version : 3.4 Config options : User PIN reset with SO-PIN enabled SO-PIN tries left : 15 User PIN tries left : 3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Default SO-PIN: 3537363231383830 Default PIN: 648219 Now executing: pkcs15-tool --dump Using reader with a card: Nitrokey Nitrokey HSM (DENK01067960000 ) 00 00 PKCS#15 Card [knot]: Version : 0 Serial number : DENK0106796 Manufacturer ID: www.CardContact.de Flags : PRN generation[...] Public EC Key [Private Key] Object Flags : [0x00] Usage : [0x140], verify, derive Access Flags : [0x02], extract FieldLength : 384 Key ref : 0 (0x00) Native : no ID : 74f59bc17317bfccc5806108d84df1abd275faef DirectValue : <present> Knot is using this keystore : keystore: - id: nitrokey backend: pkcs11 config: "pkcs11:pin-value=*** /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so" I verified /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so still exists, and ldd doesn't report any missing dependency strace let me see communication with pcscd, whose logs have these : Oct 15 21:20:14 arrakeen systemd[1]: Started pcscd.service - PC/SC Smart Card Daemon. Oct 15 21:20:20 arrakeen pcscd[33186]: 00000000 ../src/auth.c:166:IsClientAuthorized() Process 33204 (user: 134) is NOT authorized for action: access_pcsc Oct 15 21:20:20 arrakeen pcscd[33186]: 00000071 ../src/winscard_svc.c:357:ContextThread() Rejected unauthorized PC/SC client After a bit of digging, I found it's controlled by polkit, and added a brutal rule : cat /etc/polkit-1/rules.d/pcsc.rules /* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */ polkit.addRule(function(action, subject) { if (subject.isInGroup("pcsc")) { return polkit.Result.YES; } }) with knot added to the pcsc group, it can access the HSM again. Do you know of a better way to configure ? NB: I'm using another account, as I began to write this with no DNS server running Regards, -- Bastien Durel

7 měsíců, 2 týdny

3
2
0 0

Knot DNS 3.5.1 release

by Daniel Salzman

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

7 měsíců, 2 týdny

1
1
0 0

knot 3.5.0 conf-set include not working correctly

by Robert Mueller

Hi We recently tried to upgrade to knot 3.5.0, but ran into a problem. It appears zones added via `conf-set include` are not working until knot is reloaded. So to reduce calls to knotc when inserting a number of domains, we build a config fragment and then use `knotc conf-set include fragment.conf` to load it With 3.4.8 this worked fine. For example: # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock status version 3.4.8 # dig +short foo.com @10.37.129.215 SOA # cat > /local/knot_dns/zones/foo.com.zone <<EOF foo.com. 3600 IN SOA ( ns1.fastmaildev.com. postmaster.fastmaildev.com. 2025091802 ;serial 86133 ;refresh 600 ;retry 1209600 ;expire 3600 ;minimum ) foo.com. 3600 IN NS ns1.fastmaildev.com. foo.com. 3600 IN NS ns2.fastmaildev.com. EOF # cat > /tmp/zone.conf <<EOF zone: - domain: foo.com template: "default" EOF # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-begin OK # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-set include /tmp/zone.conf OK # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-commit OK # dig +short foo.com @10.37.129.215 SOA ns1.fastmaildev.com. postmaster.fastmaildev.com. 2025091802 86133 600 1209600 3600 As you can see, immediately after the `conf-commit`, the zone can be queried via dig. However this doesn't work in 3.5.0. # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock status version 3.5.0 # dig +short foo2.com @10.37.129.215 SOA # cat > /local/knot_dns/zones/foo2.com.zone <<EOF foo2.com. 3600 IN SOA ( ns1.fastmaildev.com. postmaster.fastmaildev.com. 2025091802 ;serial 86133 ;refresh 600 ;retry 1209600 ;expire 3600 ;minimum ) foo2.com. 3600 IN NS ns1.fastmaildev.com. foo2.com. 3600 IN NS ns2.fastmaildev.com. EOF # cat > /tmp/zone.conf <<EOF zone: - domain: foo2.com template: "default" EOF # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-begin OK # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-set include /tmp/zone.conf OK # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock conf-commit OK # dig +short foo2.com @10.37.129.215 SOA # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock zone-status foo2.com error: [foo2.com] (no such zone found) # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock zone-reload foo2.com error: [foo2.com] (no such zone found) # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock zone-check foo2.com # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock reload Reloaded # dig +short foo2.com @10.37.129.215 SOA ns1.fastmaildev.com. postmaster.fastmaildev.com. 2025091802 86133 600 1209600 3600 # /opt/knot/sbin/knotc -C /local/knot_dns/conf/ -s /run/knot_dns/knot_dns.sock zone-status foo2.com [foo2.com.] role: master | serial: 2025091802 As you can see, after the `conf-commit` the zone isn't visible in knot at all, either via dig or even via knotc commands `zone-status` or `zone-reload`. However immediately after a knot server `reload`, it does become visible. This feels like a bug and regression in 3.5.0 to me, or am I holding something wrong? Rob Mueller robm(a)fastmail.com

8 měsíců

2
3
0 0

Yubikey HSM

by Ulrich Wisser

Hello! Has anybody here got knot to sign with a Yubikey HSM? Asking for a friend! :-) /Ulrich

8 měsíců

2
1
0 0

Knot DNS 3.5.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.5.0! This version introduces support for a database zone backend using Redis/Valkey, external zone validation, multiple control sockets, various optimizations, and much more. See the changelog. Today Knot DNS 3.3 has reached its end of life! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.5.0/NEWS Migration: https://www.knot-dns.cz/docs/latest/html/migration.html#upgrade-3-4-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

8 měsíců, 2 týdny

1
0
0 0

Re: Catalog zones when secondary to other servers

by Chris Wopat

I am definitely interested in examples! Reading up on groups, is it that 'group A' may represent 'customer A' and have a specific set of Primary/Master nameservers, Group B == Customer B, different Primary, and so on? (also fixed to be plain text - hope this is more legible in the archives) --Chris

10 měsíců

2
4
0 0

Catalog zones when secondary to other servers

by Chris Wopat

Hello DNS people, I am exploring migrating from PowerDNS where we have a hidden primary (ns0) and two public resolvers (ns1/ns2) using SQL replication, to instead use Knot DNS for ns1/ns2 and Catalog zones to update them. ns0 would remain Powerdns (frontend, zone edits for customers, etc). We are looking at changing due to performance issues - "dns water torture" or "random subdomain attacks" or whatever we're calling this these days. Our test environment is more or less setup as listed here: * https://nick.bouwhuis.net/posts/2024-12-31-catalog-zones-powerdns-knot/ This is similar to the architectured listed here: * https://indico.dns-oarc.net/event/47/contributions/1008/attachments/963/185… (Klaus from nic.at) For some zones, we're secondary to a customer's zone. In this case the Primariy IPs are listed in PowerDNS metadata. I am trying to wrap my head around how this could work seamlessly, where we keep the same workflow - add the zone to PowerDNS, then it gets replicated with catalog zone to ns1/ns2 (knot). Does anyone have this working? Secondary is mentioned in the PDF above but no details about that are listed. The issues appear to be at least these two things: 1) How to tell ns1/ns2 (knot) which IP's are its primaries in these zones? The only thing I can think of is a separate script to generate a knot config file with this info - effectively the same as "back in the day" with BIND. This completely negates the function of catalog zones that are secondaries. rfc9432 does address this: "Catalog zones on secondary name servers would have to be set up manually, perhaps as static configuration, similar to how ordinary DNS zones are configured when catalog zones or another automatic configuration mechanism are not in place. " That RFC then says you still have to keep it in the catalog anyhow - it's not immediately clear to me how/why - and how it could be configured per the lasts sentence (manually in knot conf) as well as in the catalog - wouldn't this be two declarations of the same zone? "Additionally, the secondary needs to be configured as a catalog consumer for the catalog zone to enable processing of the member zones in the catalog, such as automatic synchronization of the member zones for secondary service" 2) How would NOTIFY work? our hidden ns0 (powerdns) runs a copy of the zones, but ns1/ns2 would be notified from the actual primary, and our ns0 would become out of date. Does knot have something like also-notify to always notify that server? This may or may not be a problem, but the zone data would completely become stale without this. Some customers log into our web portal to view records of their secondaries and expect them to match. If anyone has operational experience with this or just a big cluebat to hit me with - let me know. Cheers, Chris

10 měsíců

2
1
0 0

Slow performance adding or deleting zones with large-ish (>480k) zones database

by robm＠fastmail.com

Hi We're noticing that as our list of zones gets larger (about 480k right now), adding a new zone or deleting an existing zone seems to continue to get slower. We are always doing our modifications as part of a transaction, and the time appears to occur in the commit phase. An example timing. # time /opt/knot/sbin/knotc ... conf-begin OK real 0m0.010s user 0m0.000s sys 0m0.010s # time /opt/knot/sbin/knotc ... conf-unset zone.domain example.com OK real 0m0.010s user 0m0.000s sys 0m0.010s # time /opt/knot/sbin/knotc ... conf-commit OK real 0m2.330s user 0m0.000s sys 0m0.009s # As you can see, it took > 2 seconds to commit the transaction that removes just the example.com zone. Similarly, it takes > 2 seconds to commit the transaction that adds the zone back. Given the time is real time and not sys/user, I presume knotc is waiting on knotd to complete the work. I used perf to record a CPU profile of knotd while the commit was running, but nothing hugely stuck out at me. 10.75% knotd libc.so.6 [.] __memcmp_avx2_movbe ◆ 6.03% knotd knotd [.] __popcountdi2 ▒ 5.89% knotd knotd [.] ns_first_leaf ▒ 5.25% knotd libc.so.6 [.] pthread_mutex_lock@@GLIBC_2.2.5 ▒ 3.85% knotd liblmdb.so.0.0.0 [.] 0x0000000000003706 ▒ 3.72% knotd knotd [.] ns_find_branch.part.0 ▒ 2.76% knotd knotd [.] trie_get_try ▒ 2.63% knotd liblmdb.so.0.0.0 [.] 0x00000000000069d2 ▒ 2.34% knotd libknot.so.14.0.0 [.] knot_dname_lf ▒ 1.92% knotd liblmdb.so.0.0.0 [.] mdb_cursor_get ▒ 1.72% knotd knotd [.] create_zonedb ▒ 1.68% knotd knotd [.] twigbit.isra.0 ▒ 1.68% knotd knotd [.] catalogs_generate ▒ 1.36% knotd knotd [.] twigoff.isra.0 ▒ 1.28% knotd knotd [.] hastwig.isra.0 ▒ 1.28% knotd knotd [.] db_code ▒ 1.27% knotd libknot.so.14.0.0 [.] find_item ▒ 1.11% knotd libknot.so.14.0.0 [.] knot_dname_size ▒ 1.04% knotd knotd [.] zonedb_reload ▒ 0.99% knotd libc.so.6 [.] _int_free ▒ 0.99% knotd liblmdb.so.0.0.0 [.] 0x0000000000003ce8 ▒ 0.96% knotd liblmdb.so.0.0.0 [.] memcmp@plt ▒ 0.95% knotd liblmdb.so.0.0.0 [.] mdb_cursor_open ▒ 0.88% knotd libc.so.6 [.] malloc ▒ 0.88% knotd knotd [.] conf_db_get ▒ 0.87% knotd knotd [.] ns_next_leaf ▒ 0.82% knotd libknot.so.14.0.0 [.] iter_set ▒ 0.75% knotd knotd [.] evsched_cancel ▒ 0.73% knotd libknot.so.14.0.0 [.] find ▒ ... Our config is pretty simple, conf-export looks like: server: rundir: "/local/knot_dns/run/" user: "nobody" pidfile: "/local/knot_dns/run/knot.pid" listen: [ ... ] log: - target: "syslog" any: "info" statistics: timer: "10" file: "/tmpfs/knot_dns_stats.yaml" database: storage: "/local/knot_dns/data" mod-stats: - id: "default" request-protocol: "on" server-operation: "on" request-bytes: "on" response-bytes: "on" edns-presence: "on" flag-presence: "on" response-code: "on" request-edns-option: "on" response-edns-option: "on" reply-nodata: "on" query-type: "on" query-size: "on" reply-size: "on" template: - id: "default" global-module: "mod-stats/default" storage: "/local/knot_dns/zones/" zone: - domain: "example.com." template: "default" ... 478,000 more domains all the same ... Current files on disk are: # ls -l /local/knot_dns/data/* /local/knot_dns/data/catalog: total 0 /local/knot_dns/data/journal: total 0 /local/knot_dns/data/keys: total 0 /local/knot_dns/data/timers: total 75880 -rw-rw---- 1 root root 77697024 Jun 24 09:26 data.mdb -rw-rw---- 1 root root 2432 Jul 17 01:05 lock.mdb /local/knot_dns/data/timing: total 0 This machine is not slow or constrained in any way. It's 24 core, 3.6Ghz, 64Gb, NVMe drives, etc. Load is very low (<1) with plenty of free resources. So what I'm wondering is: 1. Is this normal? It doesn't feel right that adding/removing a single domain takes > 2 seconds regardless of the size of the existing zone database 2. Is there any way to improve this? Doing multiple adds/deletes at once within a transaction works and we do that where we can, but there are cases where we can't do that and I'd really like to understand why this is as slow as it is. Thanks in advance Rob

10 měsíců, 1 týden

5
9
0 0

Knot DNS 3.4.8 release

by Daniel Salzman

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

10 měsíců, 1 týden

1
0
0 0

Knot Resolver 6.X : split config.yaml in several files ?

by Stéphane Paillet

Hello, I'm not sure I'm posting in the right place. Don't hesitate to tell me if it's not. I began to test the use of Knot Resolver 6.x for a future project (deploying a DNS resolver with blocked domains lists). I would like to know if it's possible to split the config.yaml in several files (the main config in one file, acl and views section in another, data-local section with rpz lists and tags to rely acl lists to blocklists in another), and if the answer is yes, how can I do ? Thank you for your help. Regards, Stephane

11 měsíců, 1 týden

2
1
0 0

KDIG RFC 4892 Chaos query

by lathama＠gmail.com

I ultimately found that I needed to use a CH in KDIG but wonder how I/We could update the documentation or add an alias for chaos. Working Example: dig +short @<dns server> version.bind chaos txt dig +short @<dns server> version.bind CH txt kdig +short @<dns server> version.bind CH txt Problem Example: kdig +short @<dns server> version.bind chaos txt I had to read source code to find the answer in a speedy timeframe.

11 měsíců, 3 týdny

5
7
0 0

Knot DNS 3.4.7 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.7! This is mostly a feature version wit some bugfixes. Note that Ubuntu 20.04 is EOL, and Launchpad no longer builds packages for it. Therefore, we no longer provide updated packages for this version either. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.4.7 Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

12 měsíců

2
1
0 0

Signing Benchmark

by Thomas Küchenthal

Hi, for benchmark purpose I need to find out how log it takes to sign zone files in different sizes with different hardware. What is the best way to find out the exact time the signing process takes? Thanks! BR Thomas

1 rok

2
1
0 0

zone event 're-sign' failed (not enough space provided)

by Thomas Küchenthal

Hi, when signing a zone file I receive this error in the log: "zone event 're-sign' failed (not enough space provided)" Can you tell me what is the limiting factor here? Thanks! BR Thomas

1 rok

2
1
0 0

Trigger zone transfer from the master that sent NOTIFY

by Alexandr Basov

Hello, Could you please clarify whether Knot can perform a zone transfer not from the first master listed, but from the one that sent the NOTIFY? The masters are configured in the following order: remote: - id: master address: [ "192.168.58.151", "192.168.58.134" ] When a NOTIFY is sent from |192.168.58.134|, the zone transfer is still performed from |192.168.58.151|. Here are the relevant log entries: Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] notify, incoming, remote 192.168.58.134@32888 TCP, serial 2006 Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] refresh, remote 192.168.58.151@53, remote serial 2006, zone is outdated Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] IXFR, incoming, remote 192.168.58.151@53 TCP, receiving AXFR-style IXFR Apr 25 19:09:25 ubuntu knotd[2065]: info: [chacha.com.] AXFR, incoming, remote 192.168.58.151@53 TCP, started Thank you for your product and for your help! *Best regards,* *A.A. Basov*

1 rok, 1 měsíc

4
4
0 0

CDS/CDNSKEY issue

by Michael Grimm

Hi, this happened to me for the second time, that https://dnsviz.net <https://dnsviz.net/> tells me: | enfer-du-nord.net/CDNSKEY: The CDNSKEY RRset must be signed with a key that is represented in both the | current DNSKEY and the current DS RRset. See RFC 7344, Sec. 4.1. | enfer-du-nord.net/CDS: The CDS RRset must be signed with a key that is represented in both the current | DNSKEY and the current DS RRset. See RFC 7344, Sec. 4.1. I do not understand what that means. #) I haven't modified my KSK for some time now #) I did notify my parent zone about a modified list of nameservers (via registrar's web portal) I am not absolutely sure if the latter is the cause for these error messages. I 'fixed' that issue by re-uploading my unmodified KSK DNSKEY (via registrar's web portal). Hmm, how can I fix that issue the right way? Any hints are highly welcome, Michael

1 rok, 1 měsíc

4
6
0 0

What is mod-synthrecord used for?

by Michael Grimm

Hi, given the case that a ip6/xy block might be delegated to me by my ISP, I began investigating Knot DNS' functionality with regard to ip6.arpa. Hereby I stumbled over the module synthrecord and do not really understand what it is used for. From https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#synthrecord-automati… "Records are synthesized only if the query can't be satisfied from the zone." Please excuse my ignorance, but why would/should/must one return something else than the following for hosts not in the zone? kbn> host 2001:dead:beef::1 Host 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.e.e.b.d.a.e.d.1.0.0.2.ip6.arpa not found: 3(NXDOMAIN) Any feedback is highly appreciated, thanks. Regards, Michael

1 rok, 1 měsíc

4
12
0 0

Seperate config for zones

by Einar Bjarni Halldórsson

Hi, This is just a possible feature request. We’re planning on using Knot for user hosted domains. To do that we’ll have to add and remove zones dynamically, so we’ve enabled the config db. What surprised us is that this means that the config file isn’t used at all anymore (except you can use it to prime the config db). As it is, we’ll have to embrace the config db, which makes our ansible playbook more complicated. It’s easy to add a config file template in ansible, it’s more complicated to issue `knotc conf-begin; knotc conf-set; knotc conf-commit` logic. I wish knot was more like nsd, where you have the config file nsd.conf, but if you add zones with `nsd-control addzone ….` it gets added to a seperate zonelist file, which nsd reads on startup. It means we can have a static config file, but still be able to add and delete zones dynamically. nsd doesn’t have automatic DNSSEC key management and catalog zones in knot are really easy to use, which is why we’re going with knot for this project. I just wanted to lay it out there as an idea for the future :) .einar

1 rok, 1 měsíc

4
5
0 0

Knot DNS 3.4.6 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.6! This is a bugfix version. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.4.6 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, 1 měsíc

1
0
0 0

Re: Configuration database vs file questions

by Daniel Salzman

Hi Bill, You can't mix a configuration database and a configuration file. You can initialize a database with `knotc conf-init` or `knotc conf-import`. Then if you start knotd, the database will be used for reading and persistent writing. The configuration database format is a custom format using LMDB. It's not intended to be accessed externally! Daniel On 3/29/25 19:56, Billiam Crashkopf wrote: > Hi all, > > I'm running Knot 3.4.4 on FreeBSD 14.2, installed from the distribution package repository. > > I'm trying to understand, is there a way to configure knotd using both the configuration file and the database? For example, can I use the configuration file for directives like listen and template, then use the configuration database for storing individual zone settings? So far, it appears that knotd only uses one or the other. Furthermore, there doesn't seem to be any command to explicitly load or flush configuration from the database. If I start with the config file, I can initialize the database, but upon stopping knotd nothing seems to be saved to the database. I also don't see any documentation on tooling to inspect the database on disk. What is the file format of the database? > > If anybody can help me to know more about how it works I would be most appreciative. > > Thanks, > > Bill >

1 rok, 2 měsíce

2
1
0 0

HSM keystore-bench

by Jan-Piet Mens

Hello! In July 2024, in the Knot-DNS 3.3.8 release message, Daniel writes: >I would like to ask users with hardware HSMs to send us the output of `keymgr <hsm_keystore_id> keystore-test` >This will allow us to update https://www.knot-dns.cz/docs/latest/html/appendices.html#compatible-pkcs-11… We're now running Knot 3.4.4 against a Thales HSM (I have no details of the actual device/model in use at this time) and I see the following data: $ keymgr -c etc/knot.conf thales keystore-bench Keystore id 'thales', type PKCS #11, threads 1 Algorithm Sigs/sec RSASHA256 33 ECDSAP256SHA256 27 ED25519 n/a ED448 n/a My first reaction was "hmm, that's slow". Is there a list (above URL isn't it) of comparable results which I could show the HSM operators and/or is anybody willing to share their data? Thanks & regards, -JP

1 rok, 2 měsíce

2
3
0 0

Knot DNS 3.4.5 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.5! This is mostly a feature release. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.4.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, 2 měsíce

1
0
0 0

Re: Knot compliance with

by Henry Birge-Lee

Hi Vladimir, I appreciate your response and it's great to know you validate by default. I apologize for posting to the wrong list. Best, Henry On Wed, Mar 12, 2025 at 9:14 AM Vladimír Čunát <vladimir.cunat(a)nic.cz> wrote: > Hello. > On 10/03/2025 17.01, birgelee--- via knot-dns-users wrote: > > This ballot requires compliance with RFCs 4035 (specifically an implementation of a "security-aware" resolver as defined in Section 4) and 6840. To the best of my knowledge Knot would be a viable choice for conforming to this ballot particularly since there is a reference to RFCs 4035 in the config documentation and 6840 implements several key features of modern DNSSEC. Given the need for documentable compliance by CAs, a statement of intended support from the Knot team would be extremely helpful. > > This is about resolvers apparently, so we're slightly off-topic here, as > we have a split knot-resolver-users(a)lists.nic.cz - but I expect this > thread to be very short. > > Knot Resolver *does support* modern DNSSEC validation, as described in RFC > 4035, 6840, and some others. And we validate by default, etc. > > --Vladimir >

1 rok, 2 měsíce

1
0
0 0

Knot compliance with

by birgelee＠princeton.edu

Hi all, I know this topic has been dead for a bit, but I did want to specifically find out if Knot is intended to be compliant with DNSSEC RFCs 4035 and 6840. I ask because I am computer security researcher and I do a lot of work with the CA/Browser Froum. I recently proposed a draft ballot that would mandate all publicly-trusted web CAs validate DNSSEC: https://github.com/cabforum/servercert/pull/571 This ballot requires compliance with RFCs 4035 (specifically an implementation of a "security-aware" resolver as defined in Section 4) and 6840. To the best of my knowledge Knot would be a viable choice for conforming to this ballot particularly since there is a reference to RFCs 4035 in the config documentation and 6840 implements several key features of modern DNSSEC. Given the need for documentable compliance by CAs, a statement of intended support from the Knot team would be extremely helpful. Best, Henry https://henrybirgelee.com/

1 rok, 2 měsíce

2
1
0 0

mod-rrl

by Randy Bush

is there any guidance on using mod-rrl on a public server with a moderate load, say 6kqps? we have rtfm, and remain unsure of what we are doing. we want cookies, and therefore need to turn rrl on. but with it turned on, we seem to drop a *lot* of replies, a lot. mod-rrl: - id: default rate-limit: 200 slip: 2 randy

1 rok, 2 měsíce

4
5
0 0

IXFR versions journaling without using file

by Jeremy C. Reed

I have static zones that are regenerated continually (every few seconds) with a knotc zone-reload _zonename_ after. Doing dig queries using ixfr= always used AXFR until I enabled per-zone zonefile-load: difference We saw logs periodically like: warning: [foo.bar.example.com.] failed to update zone file (operation not permitted) This is because the files created are a different user than the knotd. We are not doing automated signing nor dynamic updates. This is with Knot 3.2.6. 1) Why would it try writing to the source zone file? Anyways, we got rid of that warning with zonefile-sync: -1 And the time to between the zone-reload and serving the new zone data improved too. I noticed with experimenting with journal-db-max-size and journal-max-size the data.mdb was around 80% larger than the defined size. As I removed and added records, the number of differences reduced and I couldn't do IXFRs for many versions behind which I assume is default journal-max-depth: 20. I believe this means the journaling was dropping versions and does not require keeping at least 20 versions (not a "minimum". I am fine with that. I was able to trigger error like error: [foo.bar.example.com.] zone event 'load' failed (not enough space provided) which I assume was due to journaling even when dropping old versions still doesn't have enough space for most recent changes. We are experimenting with increasing journal-max-size to work around this. It appears that the differences are fully handled in memory first before updating to the journal file. I also see the journal file have large jump in file size and never small increments. 2) Since I have no purpose to reuse a journal file for system restart or recovery -- since I am building new zone files frequently, is there any way to not use a journal file and just have knotd do this all in memory? That way it is never writing to the journal every few seconds while I continue to offer IXFR out support? If not, maybe I will use memory file system for the journal files. By the way, this is for around ten zones varying from around 1000 records to over 8 million records for the larger zones, They are changing from a few records every few seconds to maybe a thousand records every 30 seconds. Thanks

1 rok, 2 měsíce

2
1
0 0

IXFR response has interspersed IXFR and OPT records and more

by Jeremy C. Reed

I am testing IXFR for servers I did not install nor have easy access to. version.server. says it is 3.2.6. I know there are IXFR changes since then per the NEWS file and from git log. I don't see same behavior on my different version different systems but they are also configured differently. The knot.conf zones are not configured with "zonefile-load: difference" and the response effectively has the entire zone as if was AXFR and not the changes. If I pass the IXFR SOA SERIAL to latest it has no changes (answer has has the SOA only with same serial). I used dnspython to output the response from doing IXFR queries (IXFR question with SOA authoritative set with the serial in the query). I noticed the output abruptly stops when "dig" doesn't stop. So I used tcpdump many times to compare knot, named, and my other knot. I found an odd behavior in this knot 3.2.6 response which dig ignores and my dnspython fails. After the expect record it has 1) OPT record with the requestors pay load size (class 1232) and edns rcode and flags (all zeros ttl), then 00 rdlength and 00 rdata field. 2) then 28 bytes I don't understand such as: 40 11be dc80 0000 0101 fa00 0000 01 or 40 20be dc80 0000 0102 0300 0000 01 or 40 0fe1 6a81 0000 0102 0500 0000 00 or 12 8de1 6a81 0000 0100 9200 0000 00 3) then an IXFR record following other labels ... 0363 6f6d 00 three characters "com" and end of domain 00 fb IXFR record type 00 01 INternet class and then ends there, with NO ttl, rdlength, nor rdata. 4) followed by next label length, label ... etc with rrtype, class, ttl, rdlength, rdata and so on. This odd OPT, bytes I don't know, partial/broken IXFR record, may be repeated a few times. I assume these were interspersed where IXFR's SOA records should be. I couldn't find an RFC that suggested using interspersed OPT nor IXFR records. I find it odd that OPT record is in my ANSWER section. I find it odd that the IXFR record is incomplete. And I don't know what the other bytes are in-between. This recognizable to anyone? The IXFR works fine as seen with dig or when I use named as my secondary but I assume the named is ignoring the junk parts too.

1 rok, 3 měsíce

2
3
0 0

mod-onlinesign: extra DNSKEY causes double signatures

by Peter Thomassen

Hi, Consider a zonefile with @ DNSKEY 257 3 13 ZAtZvaK2/uVw+LG2AA12Dt/ZZ+YN0IF3pFwjfBp8Jd2DXjVU0cdxfpkY StUdbFu24Js6T5uROHo8lSG9rhgduw== and configuration zone: - domain: example.com storage: /config/ file: example.com.zone module: mod-onlinesign -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Möckernstraße 74 10965 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525

1 rok, 3 měsíce

2
3
0 0

Dynamic update fails after zone creation via catalog

by Daniel Gröber

Hi Knots, I use catalog zones to sync the set of zones my (hidden)master and slaves handle. I'm trying to stop messing with zone files on my master, instead switching exclusively to nsupdate (along with Tony Finch's nsdiff). In my testing it seems updating the zone after adding it via a catalog is not possible: $ knotc zone-status dxld.at [dxld.at.] role: master | serial: - | catalog: dxld.catalog. | re-sign: +9D15h6m14s Yet the update fails: $ knsupdate -y $SECRET <<EOF > server ns0.dxld.at. > zone dxld.at. > add dxld.at. 3600 IN SOA ns0.dxld.at. hostmaster.dxld.at. 1 2m 5m 1w 5m > send update failed: SERVFAIL Nothing is logged with `logging: any: debug` except a "ACL, allowed, action update". As soon as I create the zone on the server with zone{-begin,-set,-commit} it starts working ofc. I guess this is just not supported, but is there a good reason? I would find it quite convenient to do all my DNS ops over port 53 without touching ssh ;-) Thanks, --Daniel

1 rok, 3 měsíce

5
9
0 0

Issue - trailing data

by Артём Палецкий

Hello! I have an issue. Knot is configured as a secondary server, and when receiving a zone, a "trailing data" error occurs, preventing the zone from being loaded from the primary server. ``` Jan 30 11:03:40 hostname knotd[5407]: info: [domain.com.] refresh, remote 50788646-db98-4caa-b26e-95b30a470796, address 1.2.3.4@53, failed (trailing data) ``` The same warning appears when using the `kdig` utility: ```bash kdig @1.2.3.4 domain.com AXFR > /tmp/domain.com ;; WARNING: malformed reply packet (trailing data) ;; WARNING: malformed reply packet (trailing data) ``` The issue occurs specifically with large zones. If the zone requires 2 messages to be received (e.g., `Received 32720 B (2 messages, 442 records)`), one warning appears. If it requires 3 messages (e.g., `Received 49083 B (3 messages, 878 records)`), two warnings appear. However, if I place this zone (`/tmp/domain.com`) into `/var/lib/knot` and then execute: ```bash knotc reload knotc zone-refresh domain.com ``` Knot successfully loads the zone. Unfortunately, due to confidentiality, I cannot share the contents of the zone. Additionally, I do not have precise information about the software installed on the primary server. However, if BIND is used as the secondary server, there are no issues. A regular `dig` command also does not return any errors. Is there any way to make Knot ignore the "trailing data" error and successfully load the zone? Thank you for your help!

1 rok, 4 měsíce

4
3
0 0

Knot DNS 3.4.4 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.4! This is a bugfix version with some improvements. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.4.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, 4 měsíce

1
0
0 0

knotc issue since 3.4.1

by Jean-Daniel Dupas

Hello, I have an issue with a behaviour change in knot 3.4.1. Before 3.4.1, trying to send a conf-abort command using knotc to knot when there was no pending transaction properly returned an error, but since 3.4.1, instead of receiving an error, the connection hangs, and failed after a timeout. Some digging shows that this is due to a change in commit 69328dd7799253978605f7dac29175945971e63f Instead of returning and error as it should, ctl_process skip the command processing when it does not expect a conf-abort command. Is this a bug, or is this behaviour intended ? Just to give you some context about my use case, I wrote a daemon that is using libknot to sync the dns configuration, and as knot does not supports multiple transaction, it has to make sure there is no dangling transaction before trying to apply changes (in case the daemon did crash while applying a previous change). Until 3.4.1, it did that by simply sending a conf-abort before starting the new transaction. Thanks

1 rok, 4 měsíce

3
3
0 0

HSM support

by Thomas Kuechenthal

Hi Guys, a happy new year to all of you! Due to policy reasons we need to make knot use a HSM in the future. Is anybody successfully using some cloud based HSM services like Google Cloud HSM for DNSSEC signing? Any information is helpful, thanks! BR Thomas

1 rok, 4 měsíce

4
3
0 0

Knot DNS 3.3.10 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.10! This version backports some fixes and improvements from 3.4. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.3.10 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

Change of default nsec3-salt-length

by Erwan David

Hello, My knot 3.4.3 gives me following notice : notice: config, policy 'rail_policy' depends on default nsec3-salt-length=8, since version 3.5 the default becomes 0 In order to avoid problems when .5 will arrive, I see 2 possibilities: * add an explicit nsec3-salt-length=8 to my policy * add an explicit nsec3-salt-length=0 to my policy and resign the zone. From https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec3-guidance-10.html#nam… I understand that 0 should be the new configuration, but what are the risks (considering eg. DNS caches) if I change the policy of the zone? I only have small zones, with very few dynamic changes, which I can delay for the time of the TTL if needed. -- Erwan David

1 rok, 5 měsíců

2
1
0 0

Knot DNS 3.4.3 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.3! This is a bugfix version with some improvements. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.4.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, 5 měsíců

1
0
0 0

Starting and stopping knotd

by Erik P. Ostlyngen

Hi, I'm running an instance of knotd for testing. It is installed with the official ubuntu debian package from kont-dns.cz. When I start the knot service, using systemctl, it takes a very long time to start up (sometimes 30 min). This seems to be related to the systemd unit which is set to type 'notify', and the fact that knot after starting up wants to re-sign all the zones which needs that before notifying. If I change the type to 'simple' or 'forked' (together with the knotd -d option), the start command returns more immediately. My test system has about 800 zonefiles in it. A large number of them want to be re-signed after each startup. My question is, what is the recommended way to start, stop and restart the server? Also, after starting I cannot find the /run/knot/knot.sock file, which is needed when stopping the service with 'knotc stop'. Knot version: 3.4.1-cznic.1~focal (debian package from knot-dns.cz) OS: Linux 5.4.0/Ubuntu 20.04 Focal amd64. Kind regards, Erik Østlyngen Norid

1 rok, 6 měsíců

2
4
0 0

EPEL Packages

by Günther J. Niederwimmer

Hello Daniel, Are the EPEL packages no longer available (?), I'm stuck at 3.3.9. There have been no updates since then. Or can you download the .rpm from somewhere else now? -- mit freundlichen Grüßen / best regards Günther J. Niederwimmer

1 rok, 7 měsíců

4
7
0 0

Knot DNS 3.4.2 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.2! This is a bugfix version with a few improvements. Upgrade from 3.4.0 and 3.4.1 is recommended. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.4.2 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

Knot DNS 3.4.1 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.1! This is a bugfix version with some new features. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.4.1 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

Knot DNS 3.4.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.4.0! This version brings DNS/XFR over TLS, DDNS over QUIC and TLS, continuous DNSSEC zone validation, XDP improvements, enhanced RRL, partially asynchronous processing of control commands, and more. See the changelog. Today, Knot DNS 3.2 reached its end-of-life! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.4.0/NEWS Migration: https://www.knot-dns.cz/docs/latest/html/migration.html#upgrade-3-3-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, 8 měsíců

5
10
0 0

Deny dynamic updates for certain owners/names

by Conrad Hoffmann

Hi all, we are using dynamic updates for solving ACME challenges. My goal is to restrict the key used for this as much as possible. However, I find it a bit difficult to do so while keeping the required flexibility. Maybe someone has some good recommendations for this? The key is already restricted to TXT records, so that's good. In a nutshell, I'd like to allow only "_acme-challenge.example.com" and "_acme-challenge.*.example.com". However, the latter cannot be expressed in the current config format. I would be fine allowing "*.example.com", if I could just deny a select few names (SPF, DKIM). But AFAICT, the "deny" option only works on action, key, and address, now owner matching. Is there any other way to achieve something like this? Thanks a lot, Conrad

1 rok, 9 měsíců

2
3
0 0

Knot DNS 3.3.9 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.9! This is a bugfix version with a few improvements. Since version 3.3.4, there has been a bug in 'keymgr pregenerate', where future timestamps of existing keys are cleared and new overlapping keys are generated instead. An upgrade is recommended if you use this function or offline KSK. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.3.9 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

$TTL default setting ignored for resource records without explicit TTL set

by Michael Grimm

Hi, I do have the following example zone files definitions: $ORIGIN example.tld. $INCLUDE ___TTL_SOA___ and so on My ___TTL_SOA___ looks as follows: $TTL 30m ; default expiration time of all resource records without their own TTL value ; @ IN SOA ns1.example.tld. hostmaster.example.tld. ( 2024042100 ; serial (increase after each change) 4h ; refresh (recommended >= 4h) 1h ; retry (recommended >= 1h) 14d ; expire (recommended between 7d and 14d) 600 ; negative caching (former minimum, recommended between 5m and 1d) ) Note: All of my subsequent $INCLUDDE files do *not* have TTL values set explicitly! But: I do end up in a mix of TTL values of 1800 and 3600 for my resource records. You can check that using my domain in my email address. I found the following thread about this issue at https://gitlab.nic.cz/knot/knot-dns/-/issues/751 and https://datatracker.ietf.org/doc/html/rfc2308#section-4 cited therein: "All resource records appearing after the directive, and which do not explicitly include a TTL value, have their TTL set to the TTL given in the $TTL directive." In my understanding Knot's behaviour has been set to follow this standard track. Thus, I do expect that all of my resource records should have a TTL set to my $TTL directive of 1800 seconds. I might have well overlooked something, though. Any feedback is highly appreciated, Michael

1 rok, 10 měsíců

5
13
0 0

Knot DNS 3.3.8 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.8! This version fixes a few bugs and brings some features. I would like to ask users with hardware HSMs to send us the output of `keymgr <hsm_keystore_id> keystore-test` along with a description of the HSM. This will allow us to update https://www.knot-dns.cz/docs/latest/html/appendices.html#compatible-pkcs-11… Thank you! Note that it's no longer possible to build packages for CentOS 7 using Copr! Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.3.8 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, 10 měsíců

1
0
0 0

address lists

by Randy Bush

as yaml seems to vary widely, i worry that i may have over-induced knot yaml re address lists, see https://www.knot-dns.cz/docs/3.3/singlehtml/index.html#description remote: - id: foo address: 1.2.3.4 address: 2.3.4.5 address: 3.4.5.6 address: 6.7.8.9 is said to be the same as remote: - id: bar address: [1.2.3.4, 2.3.4.5, 3.4.5.6, 6.7.8.9] but is it also the same as remote: - id: feen address: [1.2.3.4, 2.3.4.5] address: [3.4.5.6, 6.7.8.9] feen does not result in a `knotc conf-check` syntax error, so i hope it is indeed equivalent. randy

1 rok, 10 měsíců

2
1
0 0

kasp database: how to find orphaned keys?

by Michael Grimm

Hi, is there a functionality that identifies orphaned key in the kasp database and optionally deletes those? I had had a couple of orphaned pem files. I managed to identify and remove those with the help of 'keymgr' and Unix little helpers, though. Thus I am asking just out of curiosity, because I might have missed such a functionality. Thanks and regards, Michael

1 rok, 10 měsíců

2
2
0 0

idn in axfr

by Randy Bush

knot fails to keep this zone updated. so i tested by hand ``` rip.psg.com:/home/randy# dig f.e.e.b.d.a.e.d.1.3.0.0.8.9.8.0.2.0.a.2.ip6.arpa @94.142.241.91 axfr ; <<>> DiG 9.18.24-1-Debian <<>> f.e.e.b.d.a.e.d.1.3.0.0.8.9.8.0.2.0.a.2.ip6.arpa @94.142.241.91 axfr ;; global options: +cmd ;; Warning: cannot represent 'xn--center-dla.test.globnix.net.' in the current localedig: Cannot represent 'xn--ls8h.test.globnix.net.' in the current locale nor ascii (string contains a disallowed character), use +noidnout or a different locale ``` `+noidnout` does fix it, but i am not sure i can get knot's axfr to do that the owner of the primary says Okay, this is the zone with a whole bunch of records designed to stress-test DNS implementations with things which are technically allowed in DNS at the protocol level but which apps might not handle well. Zonefile top comment: ; This is the /80 reverse DNS used for test entries which should never be ; assigned to hosts. This is </48-prefix>:DEAD:BEEF::/80 Those particular records were added on 2013-04-05 per `git blame`: 233c7992 (Phil Pennock 2013-04-05 00:08:22 +0000 64) 0.6 PTR mid\194\183dle.test.globnix.net. 233c7992 (Phil Pennock 2013-04-05 00:08:22 +0000 65) 1.6 PTR xn--center-dla.test.globnix.net. 233c7992 (Phil Pennock 2013-04-05 00:08:22 +0000 66) 2.6 PTR \240\159\146\169.test.globnix.net. 233c7992 (Phil Pennock 2013-04-05 00:08:22 +0000 67) 3.6 PTR xn--ls8h.test.globnix.net. so, `noidnout` is not in knot doc html file. clue bat, please. randy

1 rok, 11 měsíců

4
5
0 0

Knot DNS 3.3.7 and 3.2.13 releases

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.7 This version primarily fixes an old bug in the journal where some SOA serial values are incorrectly evaluated, which can corrupt the journal. Upgrade is recommended. Version 3.2.13 backports this and some older bug fixes. Changelogs: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.3.7/NEWS https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.2.13/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ů

3
5
0 0

question about unixtime

by Randy Bush

i have had a fun day chasing diags of the form ``` 2024-06-22T18:32:57.305472+00:00 ns knotd[24354]: info: [foo.com.] control, received command 'zone-reload' 2024-06-22T18:32:57.307532+00:00 ns knotd[24354]: info: [foo.com.] zone file parsed, serial 1719081134 2024-06-22T18:32:57.307669+00:00 ns knotd[24354]: warning: [foo.com.] zone file changed with decreased SOA serial 2024-06-22T18:32:57.307828+00:00 ns knotd[24354]: error: [foo.com.] zone event 'load' failed (value is out of range) ``` i have the following hypothesis: - `serial-policy: unixtime` is configured in `/etc/knot/knot.conf`. - emacs dns-mode sets the SOA serial to the current unixtime when one saves the zone file - a few seconds later, i do `knotc zone sign` and `knotc zone-reload` - knot then says "you have manually specified a new serial, but it is less than the current unixtime; i.e. you are trying to go backward. bad geek!" - i.e. knot did not like me mucking with the SOA serial in the zone file when `serial-policy: unixtime` was configured. i tested this hypothesis by putting the serial from the server's current SOA in the zone file and doing sign & reload. it succeeded, and the new zone in all servers is the unixtime of the signing, not of the zone file. my current conclusion is: do not have both emacs dns-mode with `serial-policy: unixtime`; use only one or t'other. especially if doing RFC 1982 serial stepping, remember to first turn off `serial-policy: unixtime` and `knotc reload`. does this make sense? randy

1 rok, 11 měsíců

2
3
0 0

tcp ddos

by Randy Bush

so, school is out and the children are on the loose 2024-06-10T21:27:24.199750+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 2620:171:c2::49@33322 2024-06-10T21:27:24.200561+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 167.99.160.10@14871 2024-06-10T21:27:24.200642+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 34.223.46.240@53392 2024-06-10T21:27:24.201218+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 167.99.160.10@2011 2024-06-10T21:27:24.201422+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 81.106.125.151@54192 2024-06-10T21:27:24.203263+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 34.223.46.240@53398 2024-06-10T21:27:24.203643+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 139.99.166.37@42942 2024-06-10T21:27:25.199585+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 3.228.173.229@34084 2024-06-10T21:27:25.199678+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 76.93.200.106@10371 2024-06-10T21:27:25.200951+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 2a02:6b8:c04:262:0:433f:1:3@33586 2024-06-10T21:27:25.201029+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 2600:3c09::f03c:93ff:fea9:4de0@54166 2024-06-10T21:27:25.201207+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 118.99.2.29@33170 2024-06-10T21:27:25.201385+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 213.187.92.252@40559 2024-06-10T21:27:26.200340+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 2a02:6b8:c04:262:0:433f:1:3@33594 2024-06-10T21:27:26.200529+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 40.79.144.82@59683 2024-06-10T21:27:26.203837+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 103.85.93.93@60578 2024-06-10T21:27:26.205102+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 13.244.33.51@33812 2024-06-10T21:27:27.208589+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 18.139.204.179@46824 2024-06-10T21:27:27.210062+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 20.125.201.35@63627 2024-06-10T21:27:27.331742+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 172.217.37.144@64719 2024-06-10T21:27:27.332050+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 191.233.201.73@61718 2024-06-10T21:27:27.391797+00:00 rip knotd[1389]: notice: TCP, terminated inactive client, address 81.106.125.151@50624 like tens of thousands. some children are like that. so, we take this as an opportunity to learn a bit more about knot tuning we shortened `tcp-idle-timeout: 2` we set `tcp-max-clients: 20` rate limiting seems unlikely to improve things as it is many sources, a DDos what else are we missing? btw, it also whacked knot enough that it failed a resign cycle and we had to add `unsafe-operation: no-check-keyset` to get back to signing. clues appreciated. this can't be the only neighborhood with children. randy

1 rok, 11 měsíců

6
16
0 0

DNSSEC debugging help wanted

by Korry Luke

Hi folks, Forwarding on behalf of Randy Bush since his mail server/DNS are being DDoSed right now. Trying to troubleshoot, but any knot DNS expertise would be greatly appreciated. Regards > debian 12 > knotc (Knot DNS), version 3.2.6 > (aside: the server is under serious TCP and UDP DDoS) > > all looks reasonable > > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] control, received command 'zone-sign' > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, dropping previous signatures, re-signing zone > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, key, tag 53567, algorithm RSASHA256, KSK, public, active > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, key, tag 25843, algorithm RSASHA256 > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, key, tag 59161, algorithm RSASHA256 > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, key, tag 5489, algorithm RSASHA256, KSK, public, active+ > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, key, tag 22090, algorithm RSASHA256, public > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, signing started > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, successfully signed > Jun 12 03:36:17 rip.psg.com knotd[22495]: info: [psg.com.] DNSSEC, next signing at 2024-06-25T02:36:17+0000 > > # keymgr psg.com list > 649b0d43d1493dd4ad30f8043ca4561c33c38b5a 53567 KSK RSASHA256/2048 publish=1078099200 active=1078099200 > 173597db4b4f2f072b568cb637710e891ac52246 25843 ZSK RSASHA256/2048 publish=1709251200 active=1709251200 retire=1717977600 remove=1717977600 > 3194d896f2a64f10b103991e5018b72cd3f1cd28 59161 ZSK RSASHA256/2048 publish=1709251200 active=1709251200 retire=1717977600 remove=1717977600 > 7b1bf414b34f605c68f9ddb7b52c32c6b53da8d3 5489 KSK RSASHA256/2048 publish=1718161132 > 902b8e02a5e75754bd69791735e76cb11c3e37af 22090 ZSK RSASHA256/2048 publish=1718161132 > > > but no rrsig > > # dig @localhost +vc +dnssec +norec -t dnskey psg.com > > ; <<>> DiG 9.18.24-1-Debian <<>> @localhost +vc +dnssec +norec -t dnskey psg.com > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42269 > ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1232 > ; COOKIE: 7f45da4f7305fdd5010000006669234c9ce14bdf78917f58 (good) > ;; QUESTION SECTION: > ;psg.com. IN DNSKEY > > ;; ANSWER SECTION: > psg.com. 86400 IN DNSKEY 256 3 8 AwEAAZfG8Y++ZmGXwa1sgmHpruUSPljDwMR2pY5bUjjOaJNyUBeLlEAP Fyya3MNAKryW26yTxFmwYmyt0UtXyc4L7Ib5/J/Ew+putYpjRfslwPlS 5TWblvnbiqGcY/ZMuGrtLeZkvK/o39vXM+Hy5y3xbG4Qu4ySiuW03xMM pN50cr8+VcM2RDQn6/W6kESdiY8WaXyD1DT9eIgIyi5zTaOfhSB7u/g7 H+7LltCAiCZIcIF08CGbS1VEh0YUyw3Th1I6jiQmYeGG6OSGaci5SkjV fGTDpHrJOjFlCnUVfg+cYc1YPEojbmo90qO/nG+VB5I+qDYtkU1IR8EB +qXNi7ZbBt8= > psg.com. 86400 IN DNSKEY 257 3 8 AwEAAaCgMhvfatdo1jeqr0AsHJY+QB/QVv2O+9W62Sfj+xKCbV5nGgvu XqPq2A8tXKT1lG1YF0pe3/ABH2iYNZs7v/a6QAb1wEAYasNz6ZlvRca2 bDs6KXz/n2B/Oeb2JoWBJ6OqdNtzkDl6CYEOkQoDWRnbR9jlyINOQ0mN xfTu2wbXMngSIz78yTadpieyuG/B/TsLQ1SlTUSf436G5NMdxzQ8r7j4 5nW7mEORzvvk5Z1mGtfX8v8taw4qFfoIlaf226N06lZ90jpnEHTOGSTA T/ii5WVqjBZGFWFYWrNcHR51zHm4QAGKlZ5hzr6lrGZaXqgY7jE3GaOc 86mZhSlyYIs= > psg.com. 86400 IN DNSKEY 257 3 8 AwEAAcXR1VhQRarToAaewor9xoQhrXbmUd9Ob0ruqOpDs5TO/jZLTOFE W/g4V1yllr9t7tyLVJWA5jdZyJZO3otyu6S+OKvSLD8er3alStkgqI2Q bLF3gUjtGxmcd/yIci4srWj401tv/6uWigN50+9Df0ClgUpmdjQ/ePq8 51DKtK51qGgc4vHwSYoWKQaGTofELiMDDXpzZSkQqAUveZYRzVTScUCQ woVjQANSmio/u6JZtkwRnnUF9bChN51ydUY+uVH9NuoY6jEKJ27ZlIAP 4UgQ0h9epWy5JYV9bNQlhV+qpW1G3Zg/l58Yz5mWwh107HQIUefCgVP+ TTIusTwWH0E= > > ;; Query time: 0 msec > ;; SERVER: ::1#53(localhost) (TCP) > ;; WHEN: Wed Jun 12 04:25:48 UTC 2024 > ;; MSG SIZE rcvd: 892 > > maybe 35 zones with same policy and tenplate. one has RRSIGs no others > do. > > mod-rrl: > - id: default > rate-limit: 12 # Allow 200 resp/s for each flow > slip: 2 # Approximately every other response slips > table-size: 900241 > > mod-cookies: > - id: default > secret-lifetime: 30h > badcookie-slip: 6 > Wrong Cookie > > Policy: > - Id: Pol-256-256 > Algorithm: Rsasha256 # Was Ecdsap256sha256 Sra Uses Ecdsap384sha384 > Manual: On > Delete-Delay: 30d > Unsafe-Operation: No-Check-Keyset > ... > template: > - id: default > storage: /var/lib/knot/primary > semantic-checks: on > file: %s > global-module: mod-rrl/default > global-module: mod-cookies/default > - id: signed > storage: /var/lib/knot/signed > dnssec-signing: on > dnssec-policy: pol-256-256 > semantic-checks: on > zonefile-sync: -1 > zonefile-load: difference > journal-content: all > serial-policy: unixtime > > sra and i have been beating our heads on this for two days. and there > are significant zones breaking > > randy -- Korry Luke ルーク,　コリー koluke(a)wide.ad.jp Graduate School of Media and Governance Keio University Shonan Fujisawa Campus 慶應義塾大学湘南藤沢キャンパス政策・メディア研究科

1 rok, 11 měsíců

3
3
0 0

Knot DNS 3.3.6 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.3.6! This is mostly a maintenance version with some improvements. Please note that Knot DNS 3.3 is the last major version officially supported on CentOS 7 (and similar), Debian 10, and Ubuntu 18.04. Version 3.4.0, which will be released in August, will not support them. Changelog: https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.3.6 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

Knot DNS serverupgrade tool (2.2.x->3.3.x)

by Josef Karliak

Good morning, is there some tool to migrate configuration from Knot 2.2 to actual 3.3.x ? There are some configuration changes, they're so far so good, but I'm stuck on migrating DNSSEC keys now. Thanks and best regards. J.Karliak

1 rok, 12 měsíců

2
1
0 0

install package to freebsd

by André Cruz

Hi, When i try to install knot via ports as your documentation sayshttps://www.knot-dns.cz/docs/2.4/html/installation.html [cid:f31a0a83-7640-46e7-8586-d353f8c3d8f0] it points me to a verison of 2015 https://www.freshports.org/dns/knot Can you guys change the line to # cd /usr/ports/dns/knot3 just to be more clear for a new user of freebsd https://www.freshports.org/dns/knot3 Com os meus melhores cumprimentos, André Cruz

2 roky

3
3
0 0

module 'mod-onlinesign/authsignal', incompatible with automatic signing

by Erwin Lansing

Howdy, I’m trying to get Knot 3.3.5 to use authenticated DNSSEC bootstrapping following the blog article and docs. However, I’m getting an error for the signalling zones, but I fail to figure out what I may have overlooked. error: [_signal.ns2.droso.dk <http://signal.ns2.droso.dk/>.] module 'mod-onlinesign/authsignal', incompatible with automatic signing Relevant knot.conf snippets (in order): policy: - id: ecc algorithm: ecdsap256sha256 nsec3: on rrsig-refresh: 7d mod-onlinesign: - id: authsignal nsec-bitmap: [CDS, CDNSKEY] policy: ecc template: - id: default … dnssec-signing: on dnssec-policy: ecc … zone: - domain: _signal.ns2.droso.dk <http://signal.ns2.droso.dk/> module: [mod-authsignal, mod-onlinesign/authsignal] Any hint appreciated Best Erwin

2 roky

3
3
0 0

KNOT resolver and NS serverers with CNAME

by Josef Karliak

Good morning, ISC bind is strict about CNAME of NS server: skipping nameserver 'aa.bb.cz' because it is a CNAME, while resolving '9.4/4.3.2.1.in-addr.arpa/PTR'. How about Knot resolver ? Thanks and best regards J.Karliak

2 roky

4
3
0 0

Remotely adding zones

by Einar Bjarni Halldórsson

Hi, I have a use case, where today we’re running BIND and a daemon uses rndc to create/remove/update zones on secondary servers. According to `man knotc` knotc only supports UNIX sockets (old ubuntu man page showed ‘-p’ parameter to specify port). I know I could use a catalog zone, but that would be a bigger change than I prefer right now. The primary server is running BIND+DLZ with a PostgreSQL backend. Replacing the primary is on the roadmap, but for now, I just want to replace the secondaries. Is there a good way to remotely add zones to a knot secondary? .einar

2 roky, 1 měsíc

3
3
0 0

knotc reload after updates to knot.conf

by Angus Clarke

Hello, When doing something quite dramatic in knot.conf like adding and/or removing a zone, is "knotc reload" a suitable approach to honour those changes or would you recommend restarting the whole process? "knotc reload" seems to work just fine in test, I'm just looking for some further confidence I suppose. Thanks Angus

2 roky, 1 měsíc

2
1
0 0

kzonecheck for bookworm

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

2 roky, 1 měsíc

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

2 roky, 2 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

2 roky, 2 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

2 roky, 2 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

2 roky, 2 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.

2 roky, 2 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

2 roky, 2 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

2 roky, 3 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

2 roky, 3 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

2 roky, 3 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

2 roky, 3 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

2 roky, 3 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

2 roky, 3 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

2 roky, 3 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 ;-)

2 roky, 3 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

2 roky, 3 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

2 roky, 3 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

2 roky, 3 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

2 roky, 4 měsíce

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

2 roky, 4 měsíce

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

2 roky, 5 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

2 roky, 5 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

2 roky, 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

2 roky, 7 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

2 roky, 7 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

2 roky, 8 měsíců

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users