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

[ummeegge <ummeegge@ipfire.org>]

Yes, have send it to the list. Have a bouncing message report "Hi, this
is the Mlmmj program managing the <development@lists.ipfire.org>
mailing list.

Some messages to you could not be delivered. If you're seeing this
message it means things are back to normal, and it's merely for your
information.

Here is the list of the bounced messages:
- 1725" . 
In the list i can see it here
https://lists.ipfire.org/development/20260217090707.492743-1-ummeegge@ipfire.org/T/#u
???

Am Dienstag, dem 17.02.2026 um 10:13 +0000 schrieb Michael Tremer:
> Hello Erik,
> 
> Where has it been sent to? To this list?
> 
> I did not receive anything.
> 
> -Michael
> 
> > On 17 Feb 2026, at 09:18, ummeegge <ummeegge@ipfire.org> wrote:
> > 
> > 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
> > > > > > 
> > > > 
> > > 
> >