* Knot resolver in CU 203: enable HTTP API @ 2026-06-16 20:15 Robin Roevens 2026-06-16 20:15 ` [PATCH] knot-resolver: Enable " Robin Roevens 2026-06-17 13:11 ` Knot resolver in CU 203: enable " Michael Tremer 0 siblings, 2 replies; 6+ messages in thread From: Robin Roevens @ 2026-06-16 20:15 UTC (permalink / raw) To: development Hi all For Zabbix to be able to get knot-resolver metrics, I would like to have the HTTP API enabled (https://www.knot-resolver.cz/documentation/latest/manager-api.html). Receving the same metrics is currently already possible using kresctl however this is very slow and seems to use quite some resources (especially on my mini appliance v1: one cpu goes to 100% for 2s) while when using curl to get the metrics from the HTTP API, they are returned instantly without noticable cpu usage: Timings for kresctl: real 0m1.979s user 0m1.825s sys 0m0.126s Timings for curl using the http api: real 0m0.051s user 0m0.015s sys 0m0.018s And secondly, if I would use kresctl, I would need an additional config to zabbix_agent and sudoers to support calling that binary, while using the HTTP API is natively built in into the zabbix_agent and much more performant. I have added a patch that will enable the HTTP API in the knot resolver config. If possible, I would like this to be applied already to CU 203 so that I can release a Zabbix template to monitor knot without the need for additional changes to the zabbix_agent pak that would then probably have to wait for at least CU 204. Regards Robin -- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] knot-resolver: Enable HTTP API 2026-06-16 20:15 Knot resolver in CU 203: enable HTTP API Robin Roevens @ 2026-06-16 20:15 ` Robin Roevens 2026-06-17 13:11 ` Knot resolver in CU 203: enable " Michael Tremer 1 sibling, 0 replies; 6+ messages in thread From: Robin Roevens @ 2026-06-16 20:15 UTC (permalink / raw) To: development; +Cc: Robin Roevens Enable HTTP API in knot-resolver config for performant retrieval of kresd metrics Signed-off-by: Robin Roevens <robin.roevens@disroot.org> --- config/knot-resolver/config.yaml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/config/knot-resolver/config.yaml b/config/knot-resolver/config.yaml index 7a2dd29fb..94872456a 100644 --- a/config/knot-resolver/config.yaml +++ b/config/knot-resolver/config.yaml @@ -36,6 +36,10 @@ options: # Detect time jumps time-jump-detection: true +# Enable HTTP API +management: + interface: 127.0.0.1@5000 + # Load our policy lua: script: | -- 2.54.0 -- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Knot resolver in CU 203: enable HTTP API 2026-06-16 20:15 Knot resolver in CU 203: enable HTTP API Robin Roevens 2026-06-16 20:15 ` [PATCH] knot-resolver: Enable " Robin Roevens @ 2026-06-17 13:11 ` Michael Tremer 2026-06-18 17:58 ` Robin Roevens 1 sibling, 1 reply; 6+ messages in thread From: Michael Tremer @ 2026-06-17 13:11 UTC (permalink / raw) To: Robin Roevens; +Cc: development Hello Robin, I totally agree that the overhead of kresctl is way too high, especially on some of the weaker hardware that we are using. The HTTP responses are available instantaneously which is much nicer as it almost uses zero resources. It seems that kresctl is only returning the plain output of the HTTP API anyways. However, I am not sure if we should make this available over the network because of the following problems: * Port Number Congestion - Port 5000 is a very round number and might already be used by other services like OpenVPN or even the proxy where people can choose a port number freely. As the number is easy to remember chances are high. * Security - Securing access to localhost is hard. So I have a counter-proposal which does not require any configuration changes on behalf of the Knot Resolver configuration. Kresctl already as a socket to communicate with the daemon using a Unix domain socket using the HTTP API - although it feels a bit weird sending HTTP over the socket. But it does work: [root@fw01 ~]# curl --unix-socket /var/run/knot-resolver/kres-api.sock http://localhost/metrics/json {"kresd:kresd0": {"answer": {"total": 0, "noerror": 0, "nxdomain": 0, "nodata": 0, "1ms": 0, "10ms": 0, "50ms": 0, "100ms": 0, "250ms": 0, "500ms": 0, "1000ms": 0,… Is this an option for Zabbix? I suppose you are using curl as a replacement to kresctl as it is much more lightweight. Or are you using an internal HTTP client of the zabbix agent? And if so, does it support the Unix socket? Best, -Michael > On 16 Jun 2026, at 21:15, Robin Roevens <robin.roevens@disroot.org> wrote: > > Hi all > > For Zabbix to be able to get knot-resolver metrics, I would like to have > the HTTP API enabled > (https://www.knot-resolver.cz/documentation/latest/manager-api.html). > Receving the same metrics is currently already possible using kresctl > however this is very slow and seems to use quite some resources > (especially on my mini appliance v1: one cpu goes to 100% for 2s) while > when using curl to get the metrics from the HTTP API, they are returned > instantly without noticable cpu usage: > Timings for kresctl: > real 0m1.979s > user 0m1.825s > sys 0m0.126s > Timings for curl using the http api: > real 0m0.051s > user 0m0.015s > sys 0m0.018s > > And secondly, if I would use kresctl, I would need an additional config to > zabbix_agent and sudoers to support calling that binary, while > using the HTTP API is natively built in into the zabbix_agent and much > more performant. > > I have added a patch that will enable the HTTP API in the knot resolver > config. If possible, I would like this to be applied already to CU 203 > so that I can release a Zabbix template to monitor knot without the need > for additional changes to the zabbix_agent pak that would then probably > have to wait for at least CU 204. > > Regards > Robin > > -- > Dit bericht is gescanned op virussen en andere gevaarlijke > inhoud door MailScanner en lijkt schoon te zijn. > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Knot resolver in CU 203: enable HTTP API 2026-06-17 13:11 ` Knot resolver in CU 203: enable " Michael Tremer @ 2026-06-18 17:58 ` Robin Roevens 2026-06-18 17:58 ` [PATCH] zabbix_agentd: Add support for kresd metrics Robin Roevens 2026-06-20 12:09 ` Knot resolver in CU 203: enable HTTP API Michael Tremer 0 siblings, 2 replies; 6+ messages in thread From: Robin Roevens @ 2026-06-18 17:58 UTC (permalink / raw) To: development, Michael Tremer; +Cc: Robin Roevens Hi Michael Michael Tremer schreef op wo 17-06-2026 om 14:11 [+0100]: > Hello Robin, > > I totally agree that the overhead of kresctl is way too high, > especially on some of the weaker hardware that we are using. The HTTP > responses are available instantaneously which is much nicer as it > almost uses zero resources. > > It seems that kresctl is only returning the plain output of the HTTP > API anyways. > > However, I am not sure if we should make this available over the > network because of the following problems: > > * Port Number Congestion - Port 5000 is a very round number and might > already be used by other services like OpenVPN or even the proxy > where people can choose a port number freely. As the number is easy > to remember chances are high. I just took 5000 as that was used in the example provided by the knot documentation. I noticed older versions of knot had a HTTP plugin serving more or less the same purpose, and that operated on port 8043 (http) or 8443 (https). It seems they downscaled that (only http now) and built it into the core.. > > * Security - Securing access to localhost is hard. True.. any process running on IPFire could easily query/use the knot API. > > So I have a counter-proposal which does not require any configuration > changes on behalf of the Knot Resolver configuration. Kresctl already > as a socket to communicate with the daemon using a Unix domain socket > using the HTTP API - although it feels a bit weird sending HTTP over > the socket. But it does work: > > [root@fw01 ~]# curl --unix-socket > /var/run/knot-resolver/kres-api.sock http://localhost/metrics/json > {"kresd:kresd0": {"answer": {"total": 0, "noerror": 0, "nxdomain": 0, > "nodata": 0, "1ms": 0, "10ms": 0, "50ms": 0, "100ms": 0, "250ms": 0, > "500ms": 0, "1000ms": 0,… > > Is this an option for Zabbix? I suppose you are using curl as a > replacement to kresctl as it is much more lightweight. Or are you > using an internal HTTP client of the zabbix agent? And if so, does it > support the Unix socket? Zabbix agent natively supports querying http(s) over tcp/udp sockets using a builtin client, but does not support unix sockets out of the box. So using this method will need a different approach on the Zabbix agent if we want to support it "out-of-the-box". I've been looking around for existing Knot templates, but the only ones I found use the http(s) plugin for knot and even query the interface straight from the Zabbix server instead of through the agent, so the http(s) interface has to be accessible from the Zabbix server for them to work. Anyway, the unix socket won't work natively, so I will have to add a new UserParameter to the Zabbix agent IPFire specific config, calling curl to retrieve the metrics from the unix socket, like I already do with ping, arping, getipstat, openvpnctrl, wireguardctl etc.. I've tested this and this seems to work nearly as good as natively calling http. There will always be a little performance loss due to the fact that a separate process is forked to execute an additional binary. But as it seems minimal, this should not pose a problem. Regards Robin -- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] zabbix_agentd: Add support for kresd metrics 2026-06-18 17:58 ` Robin Roevens @ 2026-06-18 17:58 ` Robin Roevens 2026-06-20 12:09 ` Knot resolver in CU 203: enable HTTP API Michael Tremer 1 sibling, 0 replies; 6+ messages in thread From: Robin Roevens @ 2026-06-18 17:58 UTC (permalink / raw) To: development, Michael Tremer; +Cc: Robin Roevens Add new UserParameter ipfire.kresd.stats.get for retrieval of kresd metrics using curl over unix-sockert. Add curl command to sudoers for Zabbix agent to be able to access the unix-socket. Signed-off-by: Robin Roevens <robin.roevens@disroot.org> --- config/zabbix_agentd/sudoers | 1 + config/zabbix_agentd/userparameter_ipfire.conf | 3 +++ 2 files changed, 4 insertions(+) diff --git a/config/zabbix_agentd/sudoers b/config/zabbix_agentd/sudoers index 50a9e69de..13edfcce9 100644 --- a/config/zabbix_agentd/sudoers +++ b/config/zabbix_agentd/sudoers @@ -12,3 +12,4 @@ zabbix ALL=(ALL) NOPASSWD: /opt/pakfire/pakfire status, /usr/sbin/fping, /usr/sb zabbix ALL=(ALL) NOPASSWD: /usr/local/bin/openvpnctrl rw log, /usr/local/bin/wireguardctrl dump zabbix ALL=(ALL) NOPASSWD: /var/ipfire/zabbix_agentd/scripts/ipfire_certificate_detail.sh zabbix ALL=(ALL) NOPASSWD: /var/ipfire/zabbix_agentd/scripts/ipfire_services.pl +zabbix ALL=(ALL) NOPASSWD: /usr/bin/curl -s --unix-socket /var/run/knot-resolver/kres-api.sock http\://localhost/metrics/json diff --git a/config/zabbix_agentd/userparameter_ipfire.conf b/config/zabbix_agentd/userparameter_ipfire.conf index e88c20298..a91e305a3 100644 --- a/config/zabbix_agentd/userparameter_ipfire.conf +++ b/config/zabbix_agentd/userparameter_ipfire.conf @@ -10,9 +10,12 @@ UserParameter=ipfire.captive.clients,awk -F ',' 'length($2) == 17 {sum += 1} END UserParameter=ipfire.services.get,sudo /var/ipfire/zabbix_agentd/scripts/ipfire_services.pl # IPS throughput bypassed/scanned/whitelisted in bytes/type (JSON) UserParameter=ipfire.ips.throughput.get,sudo /usr/local/bin/getipstat -xm | awk 'BEGIN{ORS="";print "{"}/Chain IPS/{f=1}/BYPASSED/&&f{printf "\"bypassed\":%s",$2}/SCANNED/&&f{printf ",\"scanned\":%s",$2}/WHITELISTED/&&f{printf ",\"whitelisted\":%s",$2}/^$/{f=0}END{print "}"}' +# Knot DNS resolver statistics +UserParameter=ipfire.kresd.stats.get,sudo /usr/bin/curl -s --unix-socket /var/run/knot-resolver/kres-api.sock http://localhost/metrics/json # Addon: Guardian: Number of currently blocked IP's UserParameter=ipfire.guardian.blocked.count,sudo /usr/local/bin/getipstat | awk 'BEGIN{ORS="";c=0}/Chain GUARDIAN/{f=1}/DROP/&&f{c++}/^$/{f=0}END{print c}' # # Allow item key to be called with (unused) parameters. This allows the #SINGLETON method of discovering this item only when specific service is active Alias=ipfire.ips.throughput.get[]:ipfire.ips.throughput.get +Alias=ipfire.kresd.stats.get[]:ipfire.kresd.stats.get Alias=ipfire.guardian.blocked.count[]:ipfire.guardian.blocked.count \ No newline at end of file -- 2.54.0 -- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Knot resolver in CU 203: enable HTTP API 2026-06-18 17:58 ` Robin Roevens 2026-06-18 17:58 ` [PATCH] zabbix_agentd: Add support for kresd metrics Robin Roevens @ 2026-06-20 12:09 ` Michael Tremer 1 sibling, 0 replies; 6+ messages in thread From: Michael Tremer @ 2026-06-20 12:09 UTC (permalink / raw) To: Robin Roevens; +Cc: development Hello, > On 18 Jun 2026, at 12:58, Robin Roevens <robin.roevens@disroot.org> wrote: > > Hi Michael > > Michael Tremer schreef op wo 17-06-2026 om 14:11 [+0100]: >> Hello Robin, >> >> I totally agree that the overhead of kresctl is way too high, >> especially on some of the weaker hardware that we are using. The HTTP >> responses are available instantaneously which is much nicer as it >> almost uses zero resources. >> >> It seems that kresctl is only returning the plain output of the HTTP >> API anyways. >> >> However, I am not sure if we should make this available over the >> network because of the following problems: >> >> * Port Number Congestion - Port 5000 is a very round number and might >> already be used by other services like OpenVPN or even the proxy >> where people can choose a port number freely. As the number is easy >> to remember chances are high. > > I just took 5000 as that was used in the example provided by the knot documentation. I noticed older versions of knot had a HTTP plugin serving more or less the same purpose, and that operated on port 8043 (http) or 8443 (https). It seems they downscaled that (only http now) and built it into the core.. >> >> * Security - Securing access to localhost is hard. > > True.. any process running on IPFire could easily query/use the knot API. > >> >> So I have a counter-proposal which does not require any configuration >> changes on behalf of the Knot Resolver configuration. Kresctl already >> as a socket to communicate with the daemon using a Unix domain socket >> using the HTTP API - although it feels a bit weird sending HTTP over >> the socket. But it does work: >> >> [root@fw01 ~]# curl --unix-socket >> /var/run/knot-resolver/kres-api.sock http://localhost/metrics/json >> {"kresd:kresd0": {"answer": {"total": 0, "noerror": 0, "nxdomain": 0, >> "nodata": 0, "1ms": 0, "10ms": 0, "50ms": 0, "100ms": 0, "250ms": 0, >> "500ms": 0, "1000ms": 0,… >> >> Is this an option for Zabbix? I suppose you are using curl as a >> replacement to kresctl as it is much more lightweight. Or are you >> using an internal HTTP client of the zabbix agent? And if so, does it >> support the Unix socket? > Zabbix agent natively supports querying http(s) over tcp/udp sockets using a builtin client, but does not support unix sockets out of the box. So using this method will need a different approach on the Zabbix agent if we want to support it "out-of-the-box". I've been looking around for existing Knot templates, but the only ones I found use the http(s) plugin for knot and even query the interface straight from the Zabbix server instead of through the agent, so the http(s) interface has to be accessible from the Zabbix server for them to work. > > Anyway, the unix socket won't work natively, so I will have to add a new UserParameter to the Zabbix agent IPFire specific config, calling curl to retrieve the metrics from the unix socket, like I already do with ping, arping, getipstat, openvpnctrl, wireguardctl etc.. > > I've tested this and this seems to work nearly as good as natively calling http. There will always be a little performance loss due to the fact that a separate process is forked to execute an additional binary. But as it seems minimal, this should not pose a problem. I agree that there will be a very small amount of extra overhead, but this is still much better than launching kresctl. And by using the Unix socket, we don’t create any port conflicts, don’t accidentally expose the API over the proxy and so on. So I believe that this is a very good compromise. Patch merged! Thanks! -Michael > Regards > Robin > > -- > Dit bericht is gescanned op virussen en andere gevaarlijke > inhoud door MailScanner en lijkt schoon te zijn. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-06-20 12:10 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-06-16 20:15 Knot resolver in CU 203: enable HTTP API Robin Roevens 2026-06-16 20:15 ` [PATCH] knot-resolver: Enable " Robin Roevens 2026-06-17 13:11 ` Knot resolver in CU 203: enable " Michael Tremer 2026-06-18 17:58 ` Robin Roevens 2026-06-18 17:58 ` [PATCH] zabbix_agentd: Add support for kresd metrics Robin Roevens 2026-06-20 12:09 ` Knot resolver in CU 203: enable HTTP API Michael Tremer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox