Re: ZONEMD Records in DBL RPZ Zones Break Unbound DNSSEC Priming

[ummeegge <ummeegge@ipfire.org>]

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 <ummeegge@ipfire.org> 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
> >