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

[Michael Tremer <michael.tremer@ipfire.org>]

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