Currently we are managing our knot configuration and zones via text editor and shell commands. It would be nice to find something abit more user-friendly so we can pass off some management tasks to less experienced operators. I am currently researching options to see what best fits our use case. My question is to other Knot users on this mailing list: What management tools are you using with Knot?
Much obliged,
-BC
Not sure how to capture better data (both platforms are running DEBUG level logs), but I'm running into an odd issue.
DHCP server is Kea v3.0.3 (part of the OpnSense distribution, so can't be easily updated to "latest") on FreeBSD.
DNS server is Knot v3.5.6 on Debian Trixie.
Kea is handing out both IPv4 and IPv6 addresses with:
"ddns-replace-client-name": "always"
set for all ranges /zones.
However, DDNS is not updating the zone records; A, AAAA, or PTR.
On the Kea side I get:
ERROR [kea-dhcp-ddns.d2-to-dns.0x90effa75010] DHCP_DDNS_ADD_FAILED DHCP_DDNS Request ID 00020129B7C04BF0FCBC35ACB85DE1ADD2747633BB2B32C6D7B4F195CF4667783622B5: Transaction outcome Status: Failed, Event: UPDATE_FAILED_EVT, Forward change: failed, Reverse change: failed, request: Type: 0 (CHG_ADD)
On the Knot DNS side I get:
ACL, allowed, action update, remote 192.168.144.1@57483 UDP
DDNS, processing 1 updates
DDNS, incoming, remote 192.168.144.1@57483 TCP, prerequisites not met (UPDATE prerequisite not met)
DDNS, finished, no changes to the zone were made
But no clue as to what prerequisite is missing, unmet, incorrect, etc.
Any idea how I can dig up that nugget of information? Or increase verbosity to give me enough DEBUG logs to figure it out?
deb13
knot 3.5.6
i just want a few stats for a few zones, a la
mod-stats:
- id: custom
server-operation: on
query-type: on
and it is a one-shot, i just want a one day sample
is there a brutally simple way to get them out?
yes, i can be attracted to shiny objects such as prometheus/grafna,
which i use for other purposes. but ...
i hesitate to run prometheus on the dns server, it has enough to
do. i do have prometheus running with grafana on a remote host.
knot-exporter leads me down a `python3 -m venv foo` rabbit hole,
which feels pretty weird and unnatural
and do i really need to do all this just to get simple stats out?
randy
Hi Knot DNS developers,
I've seen the discussion about the breaking changes between LMDB 0.9 and
1.0.
I understand that Knot DNS 3.6 will have some magic in it to
automatically migrate the databases.
However, my concern is about the installation of LMDB itself. Currently,
our Knot DNS packages depend on the "lmdb-libs" package from the
distribution (RedHat and derivatives), and it is version 0.9.x. RedHat
is conservative, is unlikely to update to 1.0, because that would break
everything, so I expect the RedHat packages to remain at 0.9.
Will the new Knot DNS require newer LMDB, and if so, is it expected that
we'll have to roll our own packages for LMDB? Or do you intend to bundle
LMDB with Knot DNS as you do with some other libraries?
Regards,
Anand Buddhdev
RIPE NCC
Hi,
I do want to point out: http://www.lmdb.tech/doc/upgrading.html
tl;dr dump your databases *before* upgrading.
I got bitten by this on FreeBSD and had had to fall back to lmdb 0.93.5
Has anyone succeeded in this migration your knot databases to lmdb 1.0?
Which knot databases are involved? (journal, timers, kasp, …?)
Thanks and regards,
Michael
Hello
Each action I try to do on knot gets the error
error: failed to load configuration file '/usr/local/etc/knot/knot.conf'
(MDB_BAD_TXN: Transaction must abort, has a child, or is invalid)
What can I do ? (configuration not changed recently)
Hi
I have two questions about this blog post on multi-signers: https://en.blog.nic.cz/2025/05/07/knot-dns-in-a-complex-dnssec-topology/
First, the blog post shows auto-increment SOA serial mode for the zone files in-line with the docs example:
```
zonefile-sync: -1zonefile-load: difference-no-serial
journal-content: all
```
This would work fine for me in general, I don't mind zone files being the "source of truth".
But the docs has a note "This mode is not suitable if the zone can be modified externally (e.g. DDNS, knotc)."
Do I understand correctly that this is because any dynamic changes to the zone get wiped on reboot ? So, for example, if the only external DDNS modification in my environment is DNS-01 for cert issuance, it won't cause me a problem, because those are ephemeral by nature anyway ?
This then raises the second question, how would I deal with catlog zones with this concept of multi-signers ? Or are catlog zones too much trouble in a multi-signer environment ?
Thank you
