Hello Erik, Where has it been sent to? To this list?
I did not receive anything. -Michael > On 17 Feb 2026, at 09:18, ummeegge <[email protected]> wrote: > > Hello Michael, > sure. Patch has been delivered. > > Best, > > Erik > > Am Montag, dem 16.02.2026 um 16:11 +0000 schrieb Michael Tremer: >> Hello Erik, >> >> Thanks for the feedback. >> >> Good to hear that your problem could be solved upstream. >> >> Will you provide a patch to fix this in IPFire before the next >> release of Unbound? >> >> -Michael >> >>> On 16 Feb 2026, at 13:30, ummeegge <[email protected]> wrote: >>> >>> Yes, it took longer since I discovered it and I simply wanted to >>> share >>> the insights with you all – thought it makes sense. >>> >>> Issue was opened yesterday: >>> https://github.com/NLnetLabs/unbound/issues/1404 >>> The fix has been committed today to the maintainer's fork: >>> https://github.com/dwongdev/unbound/commit/16e1e6d375e93e6c00c9b5d20ec4e50fb55d961f >>> It's a kind of "Root Cause Analysis" that delivered it there, and >>> the >>> issue is meanwhile marked as 'completed' (low hanging fruit ;-) ). >>> Hopefully it will soon be merged upstream. >>> >>> Have also tested the patch here now and it works like it should: >>> AXFR/IXFR with multiple DBL zones, no problems at all. >>> >>> Best, >>> >>> Erik >>> >>> Am Montag, dem 16.02.2026 um 11:35 +0000 schrieb Michael Tremer: >>>> Hello Erik, >>>> >>>> This is a *very* long email to tell us about a bug in Unbound. >>>> >>>> Did you report your problem there? >>>> >>>> -Michael >>>> >>>>> On 15 Feb 2026, at 11:58, ummeegge <[email protected]> wrote: >>>>> >>>>> We've identified a compatibility issue with the IPFire Domain >>>>> Blocklist >>>>> (DBL) RPZ zones. These zones contain a ZONEMD record (Type 63) >>>>> at >>>>> the >>>>> zone apex (e.g., ads.rpz.ipfire.org. 60 IN ZONEMD ...), >>>>> intended >>>>> for >>>>> data integrity checks. This record causes a critical failure in >>>>> Unbound >>>>> DNS resolver when used with RPZ. >>>>> >>>>> Impact was here: >>>>> >>>>> DNSSEC Failure: Unbound does not ignore the ZONEMD record >>>>> during >>>>> RPZ processing and mistakenly interprets the zone apex record >>>>> as a >>>>> policy rule for the root name (.). >>>>> >>>>> Symptoms: After loading more than one IPFire RPZ zone or >>>>> modifying >>>>> the configuration file and restarting/reloading Unbound, the >>>>> resolver >>>>> fails to prime its DNSSEC trust anchor. Typical log entries: >>>>> >>>>> >>>>> unbound: info: rpz: applied [dbl-ads] . rpz-local-data . >>>>> DNSKEY >>>>> IN >>>>> unbound: info: failed to prime trust anchor -- could not >>>>> fetch >>>>> DNSKEY rrset . DNSKEY IN >>>>> >>>>> Result: All DNSSEC validation fails, rendering the resolver >>>>> unable >>>>> to >>>>> resolve any domain names and effectively breaking DNS >>>>> resolution >>>>> for >>>>> the entire network. >>>>> >>>>> The issue affects more users, as confirmed by Unbound GitHub >>>>> Issue >>>>> #1404 (verified in Unbound 1.24.1/1.24.2) and potentially also >>>>> #1152. >>>>> >>>>> Technical Cause: >>>>> >>>>> In Unbound's RPZ implementation (services/rpz.c), the function >>>>> rpz_type_ignored() filters out DNSSEC-related records (DNSKEY, >>>>> RRSIG, >>>>> NSEC, etc.) to prevent them from being treated as policy rules. >>>>> ZONEMD >>>>> (RFC 8976, Type 63) is missing from this ignore list – this is >>>>> IMHO >>>>> an >>>>> Unbound bug. >>>>> >>>>> Loading process: >>>>> >>>>> Unbound reads the apex ZONEMD record. >>>>> >>>>> rpz_type_ignored(63) returns 0 → record gets processed. >>>>> >>>>> strip_dname_origin() removes the zone name → empty label >>>>> (.). >>>>> >>>>> A rpz-local-data rule for . is created, blocking root DNSKEY >>>>> priming queries. >>>>> >>>>> Note: A detailed analysis and proposed fix (add case >>>>> LDNS_RR_TYPE_ZONEMD: to rpz_type_ignored()) has been submitted >>>>> to >>>>> Unbound Issue #1404. The root cause lies with Unbound. >>>>> >>>>> Reproduction Steps: >>>>> >>>>> Configure one IPFire DBL RPZ zone (e.g., ads.rpz.ipfire.org) >>>>> following the instructions from >>>>> https://www.ipfire.org/dbl/how-to-use . >>>>> >>>>> Restart Unbound → zone gets cached (may still work >>>>> initially). >>>>> >>>>> Modify the configuration or add a second zone and restart >>>>> Unbound >>>>> again → priming failure appears in logs. >>>>> >>>>> Tested with Unbound 1.24.1 on IPFire Core 199 and Unbound >>>>> 1.24.2 on >>>>> Rocky Linux 8.10 (on Unbounds Github). Single zone may load >>>>> initially, >>>>> but fails reliably with config changes or by adding multiple >>>>> zones. >>>>> >>>>> Current temporary workaround: >>>>> >>>>> Remove ZONEMD records post-download via script (e.g., cron job >>>>> after >>>>> AXFR): >>>>> >>>>> >>>>> sed -i '/IN[[:space:]]\+ZONEMD/d' >>>>> /var/lib/unbound/*.rpz.ipfire.org.zone >>>>> >>>>> Then reload Unbound. >>>>> >>>>> >>>>> While Unbound developers might likely investigate and may fix >>>>> rpz_type_ignored() (Issue #1404), which way should IPFire users >>>>> go >>>>> until then – since this blocks testing the Beta DBL usage with >>>>> Unbound >>>>> (great project)? Haven´t tested a patched version of Unbound >>>>> since >>>>> i >>>>> have currently no build environment around but if again, am >>>>> happy >>>>> to >>>>> test preview versions! >>>>> >>>>> May someone have similar problems or even another workaround or >>>>> potential Fix for this ? >>>>> >>>>> Best regards, >>>>> >>>>> Erik >>>>> >>> >> >
