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