Knot resolver in CU 203: enable HTTP API

Knot resolver in CU 203: enable HTTP API

[Robin Roevens]

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.

[PATCH] knot-resolver: Enable HTTP API

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

Re: Knot resolver in CU 203: enable HTTP API

[Michael Tremer]

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

Re: Knot resolver in CU 203: enable HTTP API

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

[PATCH] zabbix_agentd: Add support for kresd metrics

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