knot-dns-users

knot-dns-users@lists.nic.cz

2 participants
771 discussions

what does "disposal of old contents blocked by outstanding zone transfer" mean?

by Jan-Piet Mens

Hello! I'm testing periodic key rollovers in a playground running Knot DNS 3.5.4 (I am aware that 3.5.5 is out, but this message is also in the current source code) Zone transfers are not being performed, neither incoming nor outgoing (the latter occasionally to see zone content as shown below). At the completion of each signing operation (with purposely very short timings), I see the following debug output: 2026-06-19T08:39:32+0000 info: [b.net.] DNSSEC, signing zone 2026-06-19T08:39:32+0000 info: [b.net.] DNSSEC, KSK rollover started 2026-06-19T08:39:32+0000 info: [b.net.] DNSSEC, next key action, KSK tag 18749, submit at 2026-06-19T08:40:42+0000 2026-06-19T08:39:32+0000 info: [b.net.] DNSSEC, key, tag 15175, algorithm ECDSAP256SHA256, KSK 2026-06-19T08:39:32+0000 info: [b.net.] DNSSEC, key, tag 14234, algorithm ECDSAP256SHA256, public, active 2026-06-19T08:39:32+0000 info: [b.net.] DNSSEC, key, tag 60870, algorithm ECDSAP256SHA256, KSK, public, active 2026-06-19T08:39:32+0000 info: [b.net.] DNSSEC, key, tag 18749, algorithm ECDSAP256SHA256, KSK, public, active+ 2026-06-19T08:39:32+0000 info: [b.net.] DNSSEC, signing started 2026-06-19T08:39:32+0000 info: [b.net.] DNSSEC, successfully signed, serial 94, new RRSIGs 3 2026-06-19T08:39:32+0000 info: [b.net.] DNSSEC, next signing at 2026-06-19T08:40:42+0000 2026-06-19T08:39:32+0000 info: [b.net.] zone file updated, serial 93 -> 94 2026-06-19T08:39:32+0000 debug: [b.net.] disposal of old contents blocked by outstanding zone transfer 2026-06-19T08:40:42+0000 info: [b.net.] DNSSEC, signing zone 2026-06-19T08:40:42+0000 notice: [b.net.] DNSSEC, KSK submission, waiting for confirmation 2026-06-19T08:40:42+0000 info: [b.net.] DNSSEC, key, tag 15175, algorithm ECDSAP256SHA256, KSK 2026-06-19T08:40:42+0000 info: [b.net.] DNSSEC, key, tag 14234, algorithm ECDSAP256SHA256, public, active 2026-06-19T08:40:42+0000 info: [b.net.] DNSSEC, key, tag 60870, algorithm ECDSAP256SHA256, KSK, public, active 2026-06-19T08:40:42+0000 info: [b.net.] DNSSEC, key, tag 18749, algorithm ECDSAP256SHA256, KSK, public, ready, active+ 2026-06-19T08:40:42+0000 info: [b.net.] DNSSEC, signing started 2026-06-19T08:40:42+0000 info: [b.net.] DNSSEC, successfully signed, serial 95, new RRSIGs 6 2026-06-19T08:40:42+0000 info: [b.net.] DNSSEC, next signing at 2026-07-03T06:45:11+0000 2026-06-19T08:40:42+0000 info: [b.net.] zone file updated, serial 94 -> 95 2026-06-19T08:40:42+0000 debug: [b.net.] disposal of old contents blocked by outstanding zone transfer 2026-06-19T08:40:42+0000 info: [b.net.] DS check, outgoing, remote 127.0.0.2@53 TCP, key p01., KSK submission check: negative 2026-06-19T08:40:52+0000 info: [b.net.] DS push, outgoing, remote 127.0.0.2@53 TCP, key p01., success 2026-06-19T08:41:42+0000 info: [b.net.] DS check, outgoing, remote 127.0.0.2@53 TCP, key p01., KSK submission check: positive 2026-06-19T08:41:42+0000 notice: [b.net.] DNSSEC, KSK submission, confirmed The zone itself is trivially short: $ dig -p 5340 @127.0.0.1 b.net AXFR +noall +answer +onesoa | ldns-read-zone -s b.net. 60 IN SOA ns.b.net. root.b.net. 100 10800 3600 604800 3600 www.b.net. 60 IN HTTPS 0 b.net. ns.b.net. 60 IN AAAA 2001:db8:2::4444 ns.b.net. 60 IN A 192.0.2.42 b.net. 60 IN NSEC3PARAM 1 0 0 - b.net. 60 IN DNSKEY 257 3 13 zmXFV/KHpRk/E6l7oiRg2f2M+YpWxGqHFJtHmsAFl4KAxZPeiL2VIFLswpGnrwxO47//vz/I1VqsLhmUz9k35A== ;{id = 18749 (ksk), size = 256b} b.net. 60 IN DNSKEY 256 3 13 x9PPypMDeXRarFtYwxT5uvQjE/DHQd6g+NcF5FkVGDhz/+Xq2r3ZDfLXYUjW1ivoZHstnH5hSC4znp9oghlLfw== ;{id = 38612 (zsk), size = 256b} b.net. 60 IN TXT "DNS is innocent" b.net. 60 IN NS ns.b.net. and the IMO relevant bits of the configuration are: acl: - id: all_xfr address: [ 127.0.0.1 ] action: [ transfer, notify ] submission: - id: pdns_submission check-interval: 60s parent: pdns_remote parent-delay: 10s template: - id: default storage: "/tmp/zones" zonefile-load: difference file: "%s" policy: - id: autoFAST keystore: pemstore single-type-signing: off manual: off algorithm: ecdsap256sha256 ksk-shared: off ksk-lifetime: 1h zsk-lifetime: 2h delete-delay: 1h propagation-delay: 10s nsec3: on nsec3-iterations: 0 nsec3-salt-length: 0 nsec3-salt-lifetime: 0 cds-cdnskey-publish: rollover zone-max-ttl: 60s ksk-submission: pdns_submission ds-push: pdns_remote zone: - domain: b.net dnssec-signing: on dnssec-policy: autoFAST acl: [ all_xfr ] Ought I be worried about "disposal of old contents blocked by outstanding zone transfer"? I don't think I've noticed that before. A second zone which uses the same policy shows the same behaviour. Best regards, -JP

1 měsíc, 1 týden

Knot DNS 3.5.5 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.5.5. This is a bug fix version with some improvements. Changelogs: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.5.5/NEWS Download: https://www.knot-dns.cz/download/ Documentation: https://www.knot-dns.cz/documentation/ Support: https://www.knot-dns.cz/support/ Regards, Daniel

1 měsíc, 2 týdny

[BUG] AXFR responses missing AA bit (RFC 5936 violation) in Knot 3.5.x

by Mateusz Masłowski

Hello, I would like to report a bug in Knot DNS 3.5.x where AXFR responses do not have the Authoritative Answer (AA) bit set, which appears to violate RFC 5936 §2.2. Affected versions tested: - 3.5.3 - 3.5.4 Packages tested: - cznic.1~bookworm Summary RFC 5936 §2.2 states: "Each DNS message returned by the AXFR server MUST have the AA bit set to 1." However, Knot DNS sends AXFR responses with flags set to qr only. The AA bit is not set in any of the messages in the transfer stream. As a result, strict secondary DNS servers, notably Windows Server DNS, reject such responses as invalid and abort the zone transfer. Expected behavior AXFR response messages should have the AA bit set. Expected flags: qr aa Actual behavior AXFR response messages have only the QR bit set. Actual flags: qr Possible root cause The function axfr_process_query() in src/knot/nameserver/axfr.c does not appear to call knot_wire_set_aa(). By contrast, the normal query path, via solve_answer() in internet.c, does set the AA bit, so SOA, A, and other authoritative responses are returned correctly. The AXFR code path appears to bypass this logic. Minimal reproducer dig @<knot-master> +tcp AXFR <zone> | head -2 Observed output: ;; flags: qr; The AA bit is missing. This can also be verified with tcpdump: byte 3 of each DNS message in the AXFR stream has value 0x80 / QR only, instead of 0x84 / QR + AA. -- Best regards, Mateusz Masłowski

1 měsíc, 3 týdny

Glue Record Problem

by Stefan Estada

Hi all I am having trouble forwarding a subdomain since I upgraded to the latest knot. For a couple of years I have been running a custom DNS server under dynamic.estada.ch that the clients find via my regular infrastructure. On my primary zone I have these records, but knot appears to answer weirdly: *estada.ch.zone* dynamic.estada.ch. 3600 A 185.194.239.135 dynamic.estada.ch. 3600 AAAA 2a0a:51c0::12b dynamic.estada.ch. 3600 NS dynamic.estada.ch. kdig AAAA dynamic.estada.ch @ns1.estada.ch ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 29173 ;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 3 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; dynamic.estada.ch. IN AAAA ;; AUTHORITY SECTION: dynamic.estada.ch. 3600 IN NS dynamic.estada.ch. ;; ADDITIONAL SECTION: dynamic.estada.ch. 3600 IN A 185.194.239.135 dynamic.estada.ch. 3600 IN AAAA 2a0a:51c0::12b But public servers don't get the glue records: kdig AAAA dynamic.estada.ch @9.9.9.9 ;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 63899 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; dynamic.estada.ch. IN AAAA The trouble is that most resolvers are now unable to resolve the domain as the AAAA and A queries still get answered with NS + additional A+AAAA. Is there a configuration option to tell knot to actually respond with the A or AAAA record when asked? Also ANY, TXT, or CAA queries behave the same as NS queries: kdig ANY dynamic.estada.ch @ns1.estada.ch ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 14419 ;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 3 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; dynamic.estada.ch. IN ANY ;; AUTHORITY SECTION: dynamic.estada.ch. 3600 IN NS dynamic.estada.ch. ;; ADDITIONAL SECTION: dynamic.estada.ch. 3600 IN A 185.194.239.135 dynamic.estada.ch. 3600 IN AAAA 2a0a:51c0::12b I am happy for any pointers you may have. Cheers, Stefan

1 měsíc, 3 týdny

Standby masters, how to?

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

3 měsíce

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

3 měsíce, 1 týden

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.

3 měsíce, 1 týden

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>

4 měsíce, 2 týdny

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!

4 měsíce, 2 týdny

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

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users