Since upgrade to knot 3.6, when I restart the knot server, a new serial is generated for the secondary zones,
putting them out of sync with the primary.
Logs in 3.5
Aug 25 10:31:50 ns knot[45038]: info: [domain.] zone will be loaded
Aug 25 10:31:51 ns knot[45038]: info: [domain.] zone loaded from journal, serial 2026023115
Aug 25 10:31:51 ns knot[45038]: info: [domain.] zone file loaded, serial updated 2026023115 -> 2026082500
Aug 25 10:31:51 ns knot[45038]: info: [domain.] loaded, serial none -> 2026082500 -> 2026023115, 21088 bytes, expires in 2137390 seconds
Last line show the serial is set back to the serial of the journal loaded zone
When starting 3.6
Sep 24 07:49:14 ns knot[23114]: info: [domain.] zone will be loaded
Sep 24 07:49:14 ns knot[23114]: info: [domain.] zone loaded from journal, serial 2026023175
Sep 24 07:49:14 ns knot[23114]: info: [domain.] zone file loaded, serial updated 2026023175 -> 2026092400
Sep 24 07:49:14 ns knot[23114]: info: [domain.] loaded, serial none -> 2026092400, 21088 bytes, expires in 2158298 seconds
The serial is not set back to the serail from the journal. As you can see in this case the primary does not use a date based serial number,
thus the secondary is then out of sync and refuses the notifications
--
Erwan David
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
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
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
