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

[ummeegge <ummeegge@ipfire.org>]

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