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 4h6C401Pxnz2yn0 for ; Fri, 24 Jul 2026 15:45:04 +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) (Client CN "mail01.haj.ipfire.org", Issuer "YR2" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4h6C3w5bRjz2xLm for ; Fri, 24 Jul 2026 15:45:00 +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 4h6C3t1z0Jz5tT; Fri, 24 Jul 2026 15:44:58 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1784907898; 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=qFRXdNQeJvs3rJ8Ws2QKLjAby2257sJpguHGzrXoGLE=; b=M/MInQvr0kN6bwuH6KIAGsSTW5kE9cAJ48XeD7KwP5Tbuem0WceF0BNV/E9Rc1n1D8Btf1 rz3A0x0hOq+i6kDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1784907898; 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=qFRXdNQeJvs3rJ8Ws2QKLjAby2257sJpguHGzrXoGLE=; b=pGK/Zcu0mr7aSy3MQd7K48k55SwD7WUZA3H+M/6xzRFwu46fTGe11bzBXqbispwKyc0phi DG6iSPbbaHlJo12LZ242qNqqHtHZ+hTXifBKy8hdjLddyn2N42+qv4k+soXvflg+8tfvEK xjbbof2aT2D2MTbz4KOH3j9I3TZKufQ/GCyUoR3aIGEQ4QWRA3o/l707ZWhZJP8ZOj4U6R IJXTwgKKv0GA4MOk8bcHMH0ElE34eQb5myUKGPmCoDVmwisNHjIs36Wxw1DuWuKqKaesa1 w3+STcW9yMUDu4S3i5Rk745fMfKAgIMAEHULv8UrvwfHYs6afORxK5nhMRevsA== 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: Core 203 - DNS firewall doesn't update (?) or add (!) - zone files From: Michael Tremer In-Reply-To: <14b83a61-7167-4a10-aef5-7c909171f4aa@ipfire.org> Date: Fri, 24 Jul 2026 16:44:57 +0100 Cc: "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6662cba6-6773-4040-ace7-7be7f8ad3679@ipfire.org> <14b83a61-7167-4a10-aef5-7c909171f4aa@ipfire.org> To: Matthias Fischer Hello Matthias, You seem to have two problems why Knot Resolver did not come up. The first one is this: 08:56:53 supervisord: captured stdio output from kresd1[20077] = (stderr): [system] config 'kresd1.conf' (workdir '/run/knot-resolver'): = No such file or directory The directory will be created in the updater and at boot time, so I = suppose something went wrong here. Potentially a reboot would have fixed = it. The second one is this: 08:56:49 kresd[20066]: [net ] bind to '0.0.0.0@53' (UDP): Permission = denied=20 08:56:49 kresd[20066]: [system] error while loading config: error = occurred here (config filename:lineno is at the bottom, if config is = involved): stack traceback: [C]: in function 'listen' = kresd0.conf:123: in main chunk ERROR: net.listen() failed to bind = (workdir '/run/knot-resolver=E2=80=99)=20 Knot Resolver does not run as root and is therefore not allowed to bind = to any of the privileged ports < 1024 to which 53 belongs. We solve this = by giving the binary special capabilities which might have been lost = when you extracted the tarball. So I don=E2=80=99t think that this is general bug in Knot Resolver or = IPFire, but just a slightly botched development system maybe?! -Michael > On 23 Jul 2026, at 22:17, Matthias Fischer = wrote: >=20 > (2nd try - this didn't show up on the public inbox, so I removed the > attachments) >=20 > ########## >=20 > On 23.07.2026 11:05, Michael Tremer wrote: >> Hello Matthias, >=20 > Hi Michael, >=20 > sorry, this is a bit longer. ;-) >=20 >> What happens when you run "update-rpzs=E2=80=9D? >=20 > Cursor went one line down...waited...and showed normal bash prompt > again. No errors. >=20 > But something weird happened before - I had some problems, found a > solution, but don't know what the solution was... ;-) >=20 > Steps to reproduce (perhaps?): > - I built an update for 'knot-resolver v6.4.1' under Core 203 - this = was > built without any problem, I only had to deactivate the existing patch > file. Hm. >=20 > - I stripped the files by hand and built an archive with the = command:tar > cvfz ../uploads/knot-resolver-6.4.1-for-ipfire-Core203.tar.gz -C > build_x86_64 --files-from=3Dconfig/rootfiles/common/knot-resolver >=20 > I'm doing this procedure all the time with all updated programs so I = can > install and test them on my testmachine or my productive machine, > whatever comes first. >=20 > - In the next step I copied this resolver-archive to the root = directory > of my productive machine (sigh!), stopped the running 'knot-resolver' > (at least I think this stops him) with '/etc/init.d/knot-resolver = stop' > and extracted the archive with the command: > tar xvf knot-resolver-6.4.1-for-ipfire-Core203.tar.gz -C / >=20 > E.g., I did this the same way before I pushed the last 'knot > 3.5.6'-update. No problem. Until the update for 'knot-resolver 6.4.1'. >=20 > Result: > - Restarting the 'knot-resolver 6.4.1' failed, DNS was completely = broken. > And the 'Domain Name Sstem'-Log was filled with 'kresd' and > 'knot_resolver.manager.server:' errors ("kresd[20064]: [system] error > while loading config: error occurred here" or "Uncaught generic > exception during manager inicialization"). >=20 > Hm! >=20 > Since I had backups of all essential files of the previous version > (6.4.0), I copied them back - with the same result. DNS stayed broken, > no matter what I did. Old version, new version, nothing started, = always > the same crashes. I checked rights, I checked contents, rebooted, no > chance. I don't know if I missed something - nothing worked. >=20 > Then today I copied a fresh built 'core-upgrade-2.29-203.ipfire' to > '/opt/pakfire/tmp' and updated the whole system just like I did a few > days ago through pakfire, only this time from console per = './update.sh' > and rebooted. >=20 > Suddenly DNS was running - and I could add the "Gambling" list (e.g.) = to > DNS-Firewall - it was downloaded and seems to work. >=20 > So now DNS is working (again) but I don't know why it was broken and I > don't know what fixed it in the end... weird. >=20 > EDIT: > If it helps I could open a bug report, explain the process and attach = an > excerpt of the dns log. ;-) >=20 > I don't like to push this update until I know what happened... ;-) >=20 > Best > Matthias >=20 >> -Michael >>=20 >>> On 22 Jul 2026, at 14:02, Matthias Fischer = wrote: >>>=20 >>> Hi, >>>=20 >>> I have one problem with Core 203 and I'm not sure whats the culprit: >>>=20 >>> No matter what I do, Core 203 won't download additional zone files. >>>=20 >>> After rebooting I found the already used and activated blocklists = (from >>> Core 202) in the '/var/lib//knot-resolver/zones' dirextory. They're >>> working - no seen problem. But even if I activate them all on the = DNSBL >>> page, nothing gets downloaded, the selection and number of block = lists >>> always remain the same. It won't add or remove any of the existing = lists. >>>=20 >>> Can anyone confirm? OR give me a hint where to look at? >>>=20 >>> Thanks in advance >>> Matthias >>>=20 >>>=20 >>=20 >>=20 >