From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4gh7rp15V5z32dV for ; Thu, 18 Jun 2026 18:03:54 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "YR2" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4gh7rk5NF3z2xHP for ; Thu, 18 Jun 2026 18:03:50 +0000 (UTC) Received: from layka.disroot.org (layka.disroot.org [178.21.23.139]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mail01.ipfire.org (Postfix) with ESMTPS id 4gh7rj3nLxz6v5 for ; Thu, 18 Jun 2026 18:03:49 +0000 (UTC) Authentication-Results: mail01.ipfire.org; dkim=pass header.d=disroot.org header.s=mail header.b="OYg/Q/v4"; spf=pass (mail01.ipfire.org: domain of robin.roevens@disroot.org designates 178.21.23.139 as permitted sender) smtp.mailfrom=robin.roevens@disroot.org; dmarc=pass (policy=reject) header.from=disroot.org ARC-Seal: i=1; a=rsa-sha256; d=lists.ipfire.org; s=202003rsa; cv=none; t=1781805829; b=Zg5EHEGcm+1JJJXbFeFDV/CV3L8ms6xzVqavfsBZhYwdFShNLasx3lf5EUwK+eabNg3g7h O9qcH6jjbpE7NYsdFo94wx9oiupfNc4vHGC6+7zB7uBzVygSJU8wPhQV7OoFpP3WYVdvlT /ROWgj0o9kyItz6vDKyUAZ8upwgpvSpbIWu24yB78GaqH3RGuFtLu4DQX7ZNqhPmA0q2cJ kKDCsPrh5tQ+eAsGO/PYwPNRO55AgfIO5tSmJQDUpg8Lz+c3xIzU7jOpV4fqIx13dlMitJ oStM2zcLKCR4SMoMx+nUITGYc8oBdV+DA66fV8prd1b8uvbiFC+txvtbwGmM0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.ipfire.org; s=202003rsa; t=1781805829; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+q+qumFSoxOq/+FJNczzBfM2Szv3m/YXiMYR41XL0UE=; b=w63HqiXRiF1qYXf9p/sOr2N3zgWpOUGOjPxTmLy0whKvf3GQfkOT0KIQhUoI+jmViLqBer Prk4DywTkOoD+TcnMutrKDDyvs1umnfSoJdqzV3q0Xi649D8ujDG0yy9NCs9yoNA29gsG9 wCbzTw5n3b0HzjXQUaiWX8CvwSC8g8I5stA10wodDxHE46YoJWaT6Yp5aTUhEB5EP4hirT P+tQFM0B6r5rxT1nVw1OlxrB00+O2g9DqO3wrmcqa0wnzlRblksXFX/hYhLZL7LkKkhxb5 EUgQddwlicTcdzHIkoXrovmVyBdSMPR5+mGtVaexPyYOU4xi1ksy3rwikK+TqQ== ARC-Authentication-Results: i=1; mail01.ipfire.org; dkim=pass header.d=disroot.org header.s=mail header.b="OYg/Q/v4"; spf=pass (mail01.ipfire.org: domain of robin.roevens@disroot.org designates 178.21.23.139 as permitted sender) smtp.mailfrom=robin.roevens@disroot.org; dmarc=pass (policy=reject) header.from=disroot.org Received: from mail01.disroot.lan (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id EA3F6278D8; Thu, 18 Jun 2026 20:03:48 +0200 (CEST) X-Virus-Scanned: SPAM Filter at disroot.org Received: from layka.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavis, port 10024) with ESMTP id r0hHdGQ1TD3H; Thu, 18 Jun 2026 20:03:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1781805828; bh=MAY8iAWHlhZrQBeOUhmTCcnKFLSNmXKw4k9sEiYmHaU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=OYg/Q/v4TXmBgcjEP16Enefd0K0NVhzQ0cs13qiAKl8oPHejkJTfNtLQt/xMneFoI SyePDKspuFlVzfeBGhVCSSTulKhZ8ApSvBpu4xKyBO/TbDIWcOyDPSvG2vkxIuRxJw A/SxPgnQs1Tni/kP3attmRMu0Su3yRBQPoSyFcSHn+XIrfutiAFXofwxzT5qypX61V owS+VO2BI74eWQpMGDv+RvIGf3Pm0pFoQyued5zUMa/Tr19ybFGBVG3FHQ6zr+opPx 2JF2hRFBgvTbXESHS1ul2NCOIbQzi+9Bzwst/OpgZYzFnJDI/dl+ZHeWsjo4skmv8S rQy74hp9QOa+g== Received: from chojin.roevenslambrechts.be (Chojin.roevenslambrechts.be [192.168.0.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (no client certificate requested) (Authenticated sender) by hachiman (MailScanner Milter) with SMTP id 1FDC8551FA9; Thu, 18 Jun 2026 20:03:43 +0200 (CEST) From: Robin Roevens To: development@lists.ipfire.org, Michael Tremer Cc: Robin Roevens Subject: Re: Knot resolver in CU 203: enable HTTP API Date: Thu, 18 Jun 2026 19:58:33 +0200 Message-ID: <20260618180341.35720-1-robin.roevens@disroot.org> In-Reply-To: References: Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-RoevensLambrechts-MailScanner-ID: 1FDC8551FA9.AD033 X-RoevensLambrechts-MailScanner: Found to be clean X-RoevensLambrechts-MailScanner-From: robin.roevens@disroot.org X-RoevensLambrechts-MailScanner-Watermark: 1782410625.40742@2HM60cRgPMs0quDM4BAdwQ X-Rspamd-Action: no action X-Spamd-Result: default: False [-5.51 / 11.00]; BAYES_HAM(-3.00)[100.00%]; R_DKIM_ALLOW(-1.65)[disroot.org:s=mail]; MID_CONTAINS_FROM(1.00)[]; DKIM_REPUTATION(-0.91)[-0.91458259578858]; DMARC_POLICY_ALLOW(-0.50)[disroot.org,reject]; R_SPF_ALLOW(-0.20)[+a]; SPF_REPUTATION_HAM(-0.15)[-0.14804339834727]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_SIGNED(0.00)[lists.ipfire.org:s=202003rsa:i=1]; MX_INFLIGHT(0.00)[disroot.org]; ASN(0.00)[asn:50673, ipnet:178.21.23.0/24, country:NL]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_REPUTATION_HAM(0.00)[asn: 50673(0.00), country: NL(-0.01), ip: 178.21.23.139(0.00)]; RWL_MAILSPIKE_POSSIBLE(0.00)[178.21.23.139:from]; RCPT_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[disroot.org:+] X-Rspamd-Server: mail01.haj.ipfire.org X-Rspamd-Queue-Id: 4gh7rj3nLxz6v5 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.