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 4g5Wvc6sx9z2yxC for ; Wed, 29 Apr 2026 22:20:12 +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 4g5WvK1qb9z2xPc for ; Wed, 29 Apr 2026 22:19:57 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (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) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4g5WvG3z3Mz7BS; Wed, 29 Apr 2026 22:19:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1777501195; 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=SpFwlrP2IWX4D60PYoY4REdKNNRvG501eqpFNeu4H5A=; b=JVWOHB6SXJQqil2ZW3GMMAeIhiokknHUsLAnE77G0rEpR/IlaRvXeotdUHH1lrARhUABHs p35d3Cop4i8Y749ckhvtyw0xO6ptSdbt42aW7RO/6Mzj/ePslYXDrN31HZmRB+iBq0Amkg geiO8Hn5rl5ZBq85DwM5CYTTB0srGn0rADWCdQr0ui8sZSzqQNL9yPmnB6gLbizqWc/M1P EM2UGVOlrN/cP4izBIN6b+s42j6qki9P79YKHMz47aQgqZV3/UAw8Zvx4bHjDDrA3mT+TX LQFYAYHsaYxg9rH+pupWnYxdPltx2YuOKcmzJUa7GUDH+yKYlpdLrMc0e8GqEQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1777501195; 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=SpFwlrP2IWX4D60PYoY4REdKNNRvG501eqpFNeu4H5A=; b=KF/Uaiwtoik/pfMV+QDwl3gdgqj5zCgAATbv5mAIqHsIxzucnl+fdeVXNcxgLUdi3s9wa/ KRLOeO5vtpWkXSCQ== Message-ID: <6d3f21de-40c8-4f6d-8946-6b6e28e50bc0@ipfire.org> Date: Thu, 30 Apr 2026 00:19:53 +0200 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 To: Michael Tremer Cc: IPFire Development References: <1fad9a20-1291-4584-a35e-e0a6251df296@ipfire.org> Content-Language: en-GB From: Bernhard Bitsch In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello Michael, Am 29.04.2026 um 22:09 schrieb Michael Tremer: > Hello Bernhard, > >> On 29 Apr 2026, at 18:43, Bernhard Bitsch wrote: >> >> Hi, >> >> 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. > 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 ). > For now we are stuck with Unbound, but it has always been giving us a lot of trouble. > 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? 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. >> >> >> I must apologize not to have tested the release. But I haven't the equipment, yet ( only one production system ). >> >> Regards, >> Bernhard >> >