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 4g5qZb0vV8z2yF2 for ; Thu, 30 Apr 2026 10:06:31 +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 "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4g5qZW4sxDz2xKC for ; Thu, 30 Apr 2026 10:06:27 +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 4g5qZV6Yzvz5hF; Thu, 30 Apr 2026 10:06:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1777543587; 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=Yk0eVzCrTSdnuul6tOjgy2zWOYWl56MwI/UefLIyCLg=; b=bRcHzJZdrDfEcK7wYcMRx+eZ32EE88LrbH0aygx1jQfvlwgCTZAWf43rZcDEhm9RKf7RFO N7St86Q4k2K8LET2yA8Gah/zm2AeB3gRGq2eKl26ZI+XWQoeveS0HeNHAl+Ecw9lac0oWr IDBiO0B0wf+N40ZMZPVWFEeRbyHYexYqvVOUiIxNbCuB0eUcOJuKy7Q63oveENdYY/BuSk eMygoRNABdYJAvYFoK07OpNvqLhuRC3cVj+oSp8cdeS73cKTrP2yJM1WDHbg2D+lc4yx31 wSD2OBeC5s0ukg98Cb4bDFaAgCV//MUAmFRajkqcXY1BwXo7CkKELaWtYNDJig== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1777543587; 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=Yk0eVzCrTSdnuul6tOjgy2zWOYWl56MwI/UefLIyCLg=; b=MJQ2JIXNg/f1ukyKG6cHomXbCO/fWsXwjNRvcKD/dS4SwOdbap9OI8LG92RlVktKKiDafd +diDAAvOSb+k38DQ== 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: Feedback about the DNS FW From: Michael Tremer In-Reply-To: <6d3f21de-40c8-4f6d-8946-6b6e28e50bc0@ipfire.org> Date: Thu, 30 Apr 2026 11:06:26 +0100 Cc: IPFire Development Content-Transfer-Encoding: quoted-printable Message-Id: References: <1fad9a20-1291-4584-a35e-e0a6251df296@ipfire.org> <6d3f21de-40c8-4f6d-8946-6b6e28e50bc0@ipfire.org> To: Bernhard Bitsch Hello Bernhard, > On 29 Apr 2026, at 23:19, Bernhard Bitsch wrote: >=20 > Hello Michael, >=20 > Am 29.04.2026 um 22:09 schrieb Michael Tremer: >> Hello Bernhard, >>> On 29 Apr 2026, at 18:43, Bernhard Bitsch = wrote: >>>=20 >>> Hi, >>>=20 >>> after using the new DNS FW ( congrats to this nice feature! ), I = found some issues. >> Thanks. I believe that the entire feature has received very poor = testing. Considering how many people have stated how important it is to = them, really critical issues have been reported very late in the release = process which indicates that the feature has not been tested, or if = people found those bugs, they have not been reported. >> I have to say that I am very disappointed about this. But it has = nothing to do with your question. >>> - Each 'save' in WUI page increases the memory consumption. Even if = nothing changed. A restart of unbound frees this huge allocation. >> Yes, this is known. It is a problem inside Unbound and there is = nothing we can do about it. I did not report it to Unbound, but I am = sure they should be made aware. >> Unbound in general is using a lot of memory when it is downloading = the lists. I have imported the lists into PowerDNS Recursor and it = raises its memory consumption by about ~300 MiB when Unbound is going = into 1.6-1.7 GiB. >=20 > Some more investigation in unbound docs about the operation = fast_reload ("This command is experimental at this time.") and some = experiments I can state, that the fast_reload doesn't free the copy of = the state. This gives the increase in memory consumption. > The runtime for the 'reload_keep_cache' operation is about the same as = for 'fast_reload' ( just my feeling ). But the memory load doesn't = increase ( measured just with the WUI memory stats ). Well, that is not experimental then, it is utterly broken. We are however between a rock and a hard place, because the alternative = would be to run a regular reload which will result in Unbound stopping = to process any queries, reload the zones and then resuming. On some = hardware, we are in the area of minutes to load the zones which will = cause absolute chaos if there is no DNS resolution for that time. >> For now we are stuck with Unbound, but it has always been giving us a = lot of trouble. >=20 > Does this mean we are switching to PowerDNs? But we should have a = stable system meantime. What about going back to the 'reload_keep_cache' = operation? No, we are not switching to anything at the moment because I simply = don=E2=80=99t have the time. We will however do it at some point in the = future. PowerDNS Recursor is one of the candidates because it is very = scriptable with Lua. Knot Resolver would also be a good option. I tested running them on IPFire and they both work great, but we have a = lot of custom tooling which will be quite time-consuming to migrate to = any of the other solutions. -Michael > Regards, > Bernhard >>> - Knowing from using Jon's RPZ prototype, I checked whether a single = reload ( used in DNS FW? ) propagates the changes, new list and/or = allow/deny entries, really. I found cases where this isn't true. A = unbound restart yielded the right behaviour. >>>=20 >>>=20 >>> I must apologize not to have tested the release. But I haven't the = equipment, yet ( only one production system ). >>>=20 >>> Regards, >>> Bernhard >>>=20 >=20 >=20