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 > > > > > > >
