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 >
