ZONEMD Records in DBL RPZ Zones Break Unbound DNSSEC Priming

ZONEMD Records in DBL RPZ Zones Break Unbound DNSSEC Priming

[ummeegge]

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

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

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

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

[ummeegge]

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

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

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

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

[ummeegge]

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

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

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

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

[ummeegge]

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

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

[Michael Tremer]

Hello,

I don’t quite know why, but rspamd considered this email very spammy:

2026-02-17 09:07:17 #2317039(rspamd_proxy) <82c6da>; proxy; rspamd_task_write_log: id: <20260217090707.492743-1-ummeegge@ipfire.org>, qid: <4fFYgT4dNNz5gt>, ip: 172.28.1.201, from: <development@lists.ipfire.org>, (default: T (reject): [12.21/11.00] [URL_OBFUSCATED_TEXT(9.00){type=bracket_dots;url=http://github.com;orig= ZONEMD RR (type 63) create phantom QNAME trigger ;orig=ZONEMD RR (type 63) create phantom QNAME trigger f;},SPAM_FLAG(5.00){},INTERNAL_BULK_SENDERS_IGNORED_AUTOLEARN(-2.00){},MID_CONTAINS_FROM(1.00){},NEURAL_HAM(-1.00){-1.000;},R_MISSING_CHARSET(0.50){},MAILLIST(-0.17){generic;},MIME_GOOD(-0.10){text/plain;},HAS_LIST_UNSUB(-0.01){},ALIAS_RESOLVED(0.00){},ARC_NA(0.00){},BAYES_SPAM(0.00){99.99%;},FORGED_RECIPIENTS_MAILLIST(0.00){},FORGED_SENDER_MAILLIST(0.00){},FROM_HAS_DN(0.00){},FROM_INTERNAL_BULK_SENDERS(0.00){172.28.1.201;},FROM_NEQ_ENVFROM(0.00){ummeegge@ipfire.org;development@lists.ipfire.org;},LOCAL_OUTBOUND(0.00){},MIME_TRACE(0.00){0:+;},MISSING_XM_UA(0.00){},RCPT_COUNT_TWO(0.00){2;},RCVD_COUNT_THREE(0.00){3;},RCVD_TLS_LAST(0.00){},RCVD_VIA_SMTP_AUTH(0.00){},RECEIVED_HELO_LOCALHOST(0.00){},TAGGED_FROM(0.00){bounces-1725-XXX;},TO_DN_SOME(0.00){}]), len: 5175, time: 20.925ms, dns req: 21, digest: <4a22acd73bc52a0abae6476f118c1260>, rcpts: <XXX>, mime_rcpts: <development@lists.ipfire.org,ummeegge@ipfire.org>

I don’t know what has caused the high score of the obfuscated URL which already scored 9 out of a total 12.21 points.

The email also had "X-Spam: Yes” set in its headers which did not come from us.

I will extract the patch from the archive.

-Michael

> On 17 Feb 2026, at 12:29, ummeegge <ummeegge@ipfire.org> wrote:
> 
> 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
>>>>>>> 
>>>>> 
>>>> 
>>> 
> 

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

[ummeegge]

Strange ?! Thanks for extracting the patch.

Best,

Erik

Am Dienstag, dem 17.02.2026 um 15:44 +0000 schrieb Michael Tremer:
> Hello,
> 
> I don’t quite know why, but rspamd considered this email very spammy:
> 
> 2026-02-17 09:07:17 #2317039(rspamd_proxy) <82c6da>; proxy;
> rspamd_task_write_log: id:
> <20260217090707.492743-1-ummeegge@ipfire.org>, qid: <4fFYgT4dNNz5gt>,
> ip: 172.28.1.201, from: <development@lists.ipfire.org>, (default: T
> (reject): [12.21/11.00]
> [URL_OBFUSCATED_TEXT(9.00){type=bracket_dots;url=
> http://github.com;orig= ZONEMD RR (type 63) create phantom QNAME
> trigger ;orig=ZONEMD RR (type 63) create phantom QNAME trigger
> f;},SPAM_FLAG(5.00){},INTERNAL_BULK_SENDERS_IGNORED_AUTOLEARN(-
> 2.00){},MID_CONTAINS_FROM(1.00){},NEURAL_HAM(-1.00){-
> 1.000;},R_MISSING_CHARSET(0.50){},MAILLIST(-
> 0.17){generic;},MIME_GOOD(-0.10){text/plain;},HAS_LIST_UNSUB(-
> 0.01){},ALIAS_RESOLVED(0.00){},ARC_NA(0.00){},BAYES_SPAM(0.00){99.99%
> ;},FORGED_RECIPIENTS_MAILLIST(0.00){},FORGED_SENDER_MAILLIST(0.00){},
> FROM_HAS_DN(0.00){},FROM_INTERNAL_BULK_SENDERS(0.00){172.28.1.201;},F
> ROM_NEQ_ENVFROM(0.00)
> {ummeegge@ipfire.org;development@lists.ipfire.org;},LOCAL_OUTBOUND(0.
> 00){},MIME_TRACE(0.00){0:+;},MISSING_XM_UA(0.00){},RCPT_COUNT_TWO(0.0
> 0){2;},RCVD_COUNT_THREE(0.00){3;},RCVD_TLS_LAST(0.00){},RCVD_VIA_SMTP
> _AUTH(0.00){},RECEIVED_HELO_LOCALHOST(0.00){},TAGGED_FROM(0.00){bounc
> es-1725-XXX;},TO_DN_SOME(0.00){}]), len: 5175, time: 20.925ms, dns
> req: 21, digest: <4a22acd73bc52a0abae6476f118c1260>, rcpts: <XXX>,
> mime_rcpts: <development@lists.ipfire.org,ummeegge@ipfire.org>
> 
> I don’t know what has caused the high score of the obfuscated URL
> which already scored 9 out of a total 12.21 points.
> 
> The email also had "X-Spam: Yes” set in its headers which did not
> come from us.
> 
> I will extract the patch from the archive.
> 
> -Michael
> 
> > On 17 Feb 2026, at 12:29, ummeegge <ummeegge@ipfire.org> wrote:
> > 
> > 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
> > > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> >