Re: Core 203 - DNS firewall doesn't update (?) or add (!) - zone files

[Matthias Fischer <matthias.fischer@ipfire.org>]

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 <matthias.fischer@ipfire.org> 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 <matthias.fischer@ipfire.org> 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
>>>> 
>>>> 
>>> 
>>> 
>> <Deleted: excerpt-from DNS log.txt><Deleted: knot-resolver-6.4.1-for-ipfire-Core203.tar.gz>
> 
>