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