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!
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
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
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
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
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
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
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
