knot-dns-users

knot-dns-users@lists.nic.cz

5 participants
773 discussions

Problem with mod-onlinesign and too large UDP Responses

by Alexander Hausner

Dear all, I use Knot 3.5.6 and have a problem with mod-onlinesign and large UDP responses. See the following example. bmgf.gv.at has 4 MX-Records, with glue-records (IPv4 and IPv6) the response don't fit in UDP, Knot answers SERVFAIL, which is some bad. Is this a known bug? With static signing there is no problem with this zone. As a temporary workaround, I removed an MX record, now the response fits in UDP. hugo ~ > dig mx bmgf.gv.at @ns1.bmgf.gv.at +dnssec +norecurse ;; communications error to 2a00:1610:0:50::35:2#53: timed out ;; BADCOOKIE, retrying. ; <<>> DiG 9.20.26 <<>> mx bmgf.gv.at @ns1.bmgf.gv.at +dnssec +norecurse ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63299 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 1177367604efa74d010000006a7ee210cb0462e2174243dd (good) ;; QUESTION SECTION: ;bmgf.gv.at. IN MX ;; Query time: 2 msec ;; SERVER: 2a00:1610:0:50::35:2#53(ns1.bmgf.gv.at) (UDP) ;; WHEN: Fri Aug 14 11:38:24 CEST 2026 ;; MSG SIZE rcvd: 67 hugo ~ > dig mx bmgf.gv.at @ns1.bmgf.gv.at +dnssec +norecurse +tcp ; <<>> DiG 9.20.26 <<>> mx bmgf.gv.at @ns1.bmgf.gv.at +dnssec +norecurse +tcp ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51923 ;; flags: qr aa; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 17 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: c6a7f32e776ee047010000006a7ee21ac217503f358d8896 (good) ;; QUESTION SECTION: ;bmgf.gv.at. IN MX ;; ANSWER SECTION: bmgf.gv.at. 10800 IN MX 50 m4.bmgf.gv.at. bmgf.gv.at. 10800 IN MX 50 m1.bmgf.gv.at. bmgf.gv.at. 10800 IN MX 50 m2.bmgf.gv.at. bmgf.gv.at. 10800 IN MX 50 m3.bmgf.gv.at. bmgf.gv.at. 10800 IN RRSIG MX 14 3 10800 20260828093834 20260814080834 50873 bmgf.gv.at. ix7J58s4ypgmFdEz9vC7Ua0kSgSGIpoQS7dWHpnJaWYBfORKdJqfjyMH 5DwD34tLa9Ni1evugObc9Mm+fA/xgiXRGSXTgFyPWgaWpQGHLZG61Ho+ +76SRZYwTRa/oJpf ;; ADDITIONAL SECTION: m1.bmgf.gv.at. 86400 IN A 194.48.236.129 m1.bmgf.gv.at. 86400 IN AAAA 2a00:1610:0:50::19:1 m2.bmgf.gv.at. 86400 IN A 194.48.236.130 m2.bmgf.gv.at. 86400 IN AAAA 2a00:1610:0:50::19:2 m3.bmgf.gv.at. 86400 IN A 194.48.238.131 m3.bmgf.gv.at. 86400 IN AAAA 2a00:1610:0:51::19:1 m4.bmgf.gv.at. 86400 IN A 194.48.238.130 m4.bmgf.gv.at. 86400 IN AAAA 2a00:1610:0:51::19:2 m1.bmgf.gv.at. 86400 IN RRSIG A 14 4 86400 20260828093834 20260814080834 50873 bmgf.gv.at. Y2jZzelOx9K50ArysU41iuLiJjl72eicSHkKeK2gK6/RvCG5E0QkktQ1 Ex58vZWXYradR8gaE/fAQLo7fjJ0Ovq7EhVuE+Nb6cnfWNjCP3AHX6BE qr7DTgoSMeJ47NsJ m1.bmgf.gv.at. 86400 IN RRSIG AAAA 14 4 86400 20260828093834 20260814080834 50873 bmgf.gv.at. gTSHczdHuFYiW7FWEOXU1CK2ap/XSDaYQRV9pD3+PvGlaXf1oo0Xv/uX U1CyHhuS90ekXnqicgduA0ssGNgwYmYvoeTOshT/juuCy8sqGz1bd6Jv VRmT9Tdjiact4Qh/ m2.bmgf.gv.at. 86400 IN RRSIG A 14 4 86400 20260828093834 20260814080834 50873 bmgf.gv.at. a9WC+6E05xVjXdgeA7fStV1rG3FGpTpf9tC5IyKbAp7drnENlxY2zEI6 1OlYmV2zhVIUsQ6G0454BsHiUZJUSQcM9pN7Fi09dYV/toK1wdZTuF5Q gLGM4ykgoZAoW8S0 m2.bmgf.gv.at. 86400 IN RRSIG AAAA 14 4 86400 20260828093834 20260814080834 50873 bmgf.gv.at. DWMNJH62Grvy3HEc6Vp3DcwF98iVyj4xthEQtVD5sITimPAzIgV/hMDm fQ8zhDIQ1LO2Z6czR4PPXdommZCCTdouV5c4GWnDCTJexP8v8DAjmXiA MibMxqidbujrRdj7 m3.bmgf.gv.at. 86400 IN RRSIG A 14 4 86400 20260828093834 20260814080834 50873 bmgf.gv.at. bTTmNigjqdhPZ22ncMVZtKb0MpeicV3TJRnPY2I8bKujqIvyLfcVEk4R QUt4rJkqlNwLclVK7MreGR8GvWQRFeLI5L+EleB/V6wWmLYq6/cwGQSN 0+eHKXoW3ZDeYKDV m3.bmgf.gv.at. 86400 IN RRSIG AAAA 14 4 86400 20260828093834 20260814080834 50873 bmgf.gv.at. mB2MK+qhyyZKlKonarYnJlHlAFaSwm46o1rv1rU9MyL0Uu1LZyt/pmZ5 e5SGQAIyKcbhIM1C5/TzyWVrYcbAtFTPmauBNQmJf2AVLdzxZHvxIpOc trmphwY+Kj2CxU7U m4.bmgf.gv.at. 86400 IN RRSIG A 14 4 86400 20260828093834 20260814080834 50873 bmgf.gv.at. 5Edu5spf8YkWA/tpzpyZguDlO0hxcxpsDbXM4RM1AjwzjTGgYzIDcn6D MMleg89vLwotGB0Rx9CFo2Ojrf0gQFIkjEU94NTvid2L0haEGx5RZMN9 TnnIczIYX2nPN5HE m4.bmgf.gv.at. 86400 IN RRSIG AAAA 14 4 86400 20260828093834 20260814080834 50873 bmgf.gv.at. YD8kOs9smUoGXI3XUL4e6hst+ET7JwAeRzXLaE48FWzQOtUPI1pyH7rO b7RDHqw+sTomMMrNQV7Vrq3PVG4P/Ammk3O1MVr1fCfeEdgyh/ExI8xN BusfA05QJ6pK9pZL ;; Query time: 4 msec ;; SERVER: 2a00:1610:0:50::35:2#53(ns1.bmgf.gv.at) (TCP) ;; WHEN: Fri Aug 14 11:38:34 CEST 2026 ;; MSG SIZE rcvd: 1573 Best Regards, Alexander Hausner

17 hours, 29 minutes

knotd v3.5.6 fails to start if it fails to load QUIC/TLS keys or certificates

by Max Hearnden

knotd still fails to start if it can't load certificates or keys. This appears to be a bug given that "knotd: server crashes when it fails to load a QUIC/TLS key" is in the release notes for knot-dns v3.5.6. Below is a patch that allows the server to start if knotd can't load the certificates/keys. --- src/knot/server/server.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/knot/server/server.c b/src/knot/server/server.c index 8de6f1a8f..e03178144 100644 --- a/src/knot/server/server.c +++ b/src/knot/server/server.c @@ -824,9 +824,10 @@ static int configure_sockets(conf_t *conf, server_t *s) s->quic_active = conf->cache.xdp_quic > 0 || convent_quic > 0 || quic_rmt_count(conf, C_QUIC) > 0; s->tls_active = convent_tls > 0 || quic_rmt_count(conf, C_TLS) > 0; if (s->quic_active || s->tls_active) { - if (init_creds(conf, s) != KNOT_EOK) { - server_deinit_iface_list(newlist, nifs); - return KNOT_ERROR; + int ret; + if ((ret = init_creds(conf, s)) != KNOT_EOK) { + log_error("failed to configure server credentials (%s)", + knot_strerror(ret)); } } -- 2.54.0

3 days, 18 hours

grafana dashboard

by Randy Bush

deb13 knot 3.5.6 prometheus 2.53.3+ds1-2 grafana 13.0.2 i am running the [python version](https://gitlab.nic.cz/knot/knot-dns/-/tree/master/python/knot_exporter) of knot_exporter on the dns server .../knot-exporter --web-listen-addr 666.42.7.11 --web-listen-port 9443 prometheus on my webby host seems to be pulling happily from 9443 of the knotty server. i.e. http://knotty.host:9443/metrics has a lot of data and http://webby.host:9090/metrics has data and grafana drilldown/metrics has pretty data but which main grafana dashboard json should i be using for knot? https://grafana.com/grafana/dashboards/14989-knot-metrics-dashboard/ displays a lot of No Data randy

1 week, 5 days

Knot management tools?

by Billiam Crashkopf

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

2 weeks

DDNS update prerequisites???

by edv＠null-route.com

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?

2 weeks, 3 days

simplest way to get stats

by Randy Bush

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

2 weeks, 4 days

Knot DNS 3.5.6 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 3.5.6. This is a bug-fix release with a security fix for ACL evaluation. Upgrade is recommended if certificate hostname verification is enabled. Note that Knot DNS 3.5 is not compatible with LMDB 1.x. The upcoming Knot DNS version 3.6, which is expected to be released in two months, will support automatic migration of LMDB databases to version 1.x. Changelogs: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v3.5.6/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 weeks, 4 days

LMDB version compatibility issues

by Anand Buddhdev

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

3 weeks, 4 days

[heads up] upgrading lmdb to version 1.0

by Michael Grimm

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

1 month, 1 week

knot blocked

by Erwan David

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)

1 month, 1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users