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 4h6GqK2RNwz30Hc for ; Fri, 24 Jul 2026 18:34:21 +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 4h6GqF6R44z2xJ5 for ; Fri, 24 Jul 2026 18:34:17 +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 4h6GqF14PjzPh; Fri, 24 Jul 2026 18:34:17 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1784918057; 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=eWETD28lDd7NE/j5eMzPFVui0CAt9DnBuZNfNHBFHqM=; b=jlYes0k01SwHE7avlnrchT1TSl9JU5gpdu5sCQ34f/tAun3Z6B1J9GdswxoKofTSC9Vnxz pWAOLhH7ntIkPzAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1784918057; 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=eWETD28lDd7NE/j5eMzPFVui0CAt9DnBuZNfNHBFHqM=; b=iUltJ3Meq1IwU9ohmMjM0VVhqNSrtz+EfHapz9eXhTs/KKD9RwFhWdWUc6X/SN2R3l71aR lBV2haLIGiDY7Jv/Tj0T21tz+zMBp2uzX5sYiFpIA9Uc+xUI2vWwFlQ08eczei1mMyN6Sx 2hXy+5DLe0pu8yAKoSr/XGuzQewRVxtyChUFiUfEObYvE82Qq1RtGoKrU5xuUUqEuuVxG0 85VgtVmuwoAiGLviC8TpVOYnuvgvPKjxK0fMJDutp2o3lBFArUI1UBYL/2T17KbkZOpBtf Vj9zUkXS5b9Q7BnJk6Mk/XEIxAKWb4VL+NY7QIaX0md/osHE67CowpB3sJ5PLQ== Message-ID: <111fd0f3-4ca3-48ba-b8f9-18ffe69f62aa@ipfire.org> Date: Fri, 24 Jul 2026 20:34:09 +0200 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 Content-Language: en-US To: Michael Tremer References: <6662cba6-6773-4040-ace7-7be7f8ad3679@ipfire.org> <14b83a61-7167-4a10-aef5-7c909171f4aa@ipfire.org> Cc: "IPFire: Development-List" From: Matthias Fischer In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 24.07.2026 17:44, Michael Tremer wrote: > Hello Matthias, Hi Michael, > 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. Yep. This directory was definitely missing. Two reboots didn't help, these directory showed up after I reinstalled the core update per hand. Together with a few others... > The second one is this: > > 08:56:49 kresd[20066]: [net ] bind to '0.0.0.0@53' (UDP): Permission denied > 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’) > > 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. Which capabilities are these? I looked through the update script but didn't find anything special which could give me a hint. Right now it looks like this: ... root@ipfire: /usr/bin # ls knot-resolver -ls 4 -rwxr-xr-x 1 root root 988 Jul 20 14:54 knot-resolver ... > So I don’t think that this is general bug in Knot Resolver or IPFire, but just a slightly botched development system maybe?! Äääh!...how could it be!? This was the first time this procadure failed... ;-) But yes - I thought the same. No bug, just borked. Thanks for any hints! :-) Best Matthias > > -Michael > >> On 23 Jul 2026, at 22:17, Matthias Fischer wrote: >> >> (2nd try - this didn't show up on the public inbox, so I removed the >> attachments) >> >> ########## >> >> On 23.07.2026 11:05, Michael Tremer wrote: >>> Hello Matthias, >> >> Hi Michael, >> >> sorry, this is a bit longer. ;-) >> >>> What happens when you run "update-rpzs”? >> >> Cursor went one line down...waited...and showed normal bash prompt >> again. No errors. >> >> But something weird happened before - I had some problems, found a >> solution, but don't know what the solution was... ;-) >> >> 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. >> >> - 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=config/rootfiles/common/knot-resolver >> >> 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. >> >> - 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 / >> >> 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'. >> >> 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"). >> >> Hm! >> >> 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. >> >> 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. >> >> Suddenly DNS was running - and I could add the "Gambling" list (e.g.) to >> DNS-Firewall - it was downloaded and seems to work. >> >> 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. >> >> EDIT: >> If it helps I could open a bug report, explain the process and attach an >> excerpt of the dns log. ;-) >> >> I don't like to push this update until I know what happened... ;-) >> >> Best >> Matthias >> >>> -Michael >>> >>>> On 22 Jul 2026, at 14:02, Matthias Fischer wrote: >>>> >>>> Hi, >>>> >>>> I have one problem with Core 203 and I'm not sure whats the culprit: >>>> >>>> No matter what I do, Core 203 won't download additional zone files. >>>> >>>> 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. >>>> >>>> Can anyone confirm? OR give me a hint where to look at? >>>> >>>> Thanks in advance >>>> Matthias >>>> >>>> >>> >>> >> > >