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 4gjCvd4RYfz2xsf for ; Sat, 20 Jun 2026 12:10:05 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (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 4gjCvZ2MNBz2xJy for ; Sat, 20 Jun 2026 12:10:02 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4gjCvX4HLTzNL; Sat, 20 Jun 2026 12:10:00 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1781957401; 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; bh=XBoO/97eSuFvlrAPkV3Cv7y6pW9t/niLL3TGD2qjtNU=; b=kCrIiv5cMey9ecz8Mu3G8ScQ8nmEy4CoTYNp6kBBoHhy9/fFCyAPyDZoSqrDcxVNrC5Vk7 uJ3bWKiKClkbTQBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1781957401; 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; bh=XBoO/97eSuFvlrAPkV3Cv7y6pW9t/niLL3TGD2qjtNU=; b=J2uRuYwLM/5XlfBrExw5BNFJ4uFVcQO28gRIL3QMBofXqBB27wROrrV5zaB0OXyN8nFAnF h/8ALaSyUtx91AjJIka8JCGN2s81V5rEtYt0BHiMFpZ/8ICv320Edh28o2PuJsj4w2pe2r MzBT+yUAvFvdxNXBppYUmAu6kDRgbrjIVgQeEMtrvkNJVom+DXNErCJ+fbGuKjo5FSE8sE g7Y1WVRZfcmSt8iFK/RKaipt/Llawynj8I0063bzh+L79LU4vbBxbVYTBjC+j4idQnH+XE emTdk0oauntsFUn66CVeKBR6lV6PnF8EJ8vej6bfnNjLxiZEU/tGMwEcXfT48w== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: Knot resolver in CU 203: enable HTTP API From: Michael Tremer In-Reply-To: <20260618180341.35720-1-robin.roevens@disroot.org> Date: Sat, 20 Jun 2026 07:09:57 -0500 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20260618180341.35720-1-robin.roevens@disroot.org> To: Robin Roevens Hello, > On 18 Jun 2026, at 12:58, Robin Roevens = wrote: >=20 > Hi Michael >=20 > Michael Tremer schreef op wo 17-06-2026 om 14:11 [+0100]: >> Hello Robin, >>=20 >> 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. >>=20 >> It seems that kresctl is only returning the plain output of the HTTP >> API anyways. >>=20 >> However, I am not sure if we should make this available over the >> network because of the following problems: >>=20 >> * 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. >=20 > 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.. >>=20 >> * Security - Securing access to localhost is hard. >=20 > True.. any process running on IPFire could easily query/use the knot = API. >=20 >>=20 >> 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: >>=20 >> [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,=E2=80=A6 >>=20 >> 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. >=20 > 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..=20 >=20 > 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=E2=80=99t create any port conflicts, don=E2=80=99t = 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 >=20 > --=20 > Dit bericht is gescanned op virussen en andere gevaarlijke > inhoud door MailScanner en lijkt schoon te zijn.