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

[ummeegge <ummeegge@ipfire.org>]

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