From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4fFnpy0Y6sz34RY for ; Tue, 17 Feb 2026 18:14:34 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4fFnpn051jz2xRF for ; Tue, 17 Feb 2026 18:14:25 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange secp256r1 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4fFnpk6JLgz2wG; Tue, 17 Feb 2026 18:14:22 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1771352063; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=f5z36HMVlu+w6sDYRudQiNZyGtE8RYHXtDyTlrnRkd4=; b=zDP5QsNPkcqR5uh9MAw5fFaSZ4ukL5Ec3nIAE+rwKEv79A4+R3UaGGFdm2j9uvE49nKUnT CpTqAybWWK5VD1Dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1771352063; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=f5z36HMVlu+w6sDYRudQiNZyGtE8RYHXtDyTlrnRkd4=; b=geCdX0LBQPnwB7hMUVro2hZ4F7HxiKu+zviryWBvzyB1WclRNDH4ozwwzWSkwlmQCJrCaW qRfWhH+f/1xyO/e1NKlu2DbXYIbHpzVwyOeLbH4Kz7fXi98u9qDdUFphUYVJIAQZCAjZyr GsgMhhmWbdLb3M9asCXJhittbIJiwB18Cp4B7SXag6K0KuEXUZR7etqqZINGpy9k4z32SE DEbzLFwcYJvKYBxsrifICLiLd4CnWo5ZJTHscaz9YjP6Nfu+QUN+IqNOYHmzOf03pSZu31 MDGd6Hiz2bNMCT9Q5BuWzi+BR8c3IvuiLDHgYsmHfYnuvgC55k3yTc1O6WAAfw== Message-ID: <83bf6fba5ff7ebb99a795e748a0b1cffba33a155.camel@ipfire.org> Subject: Re: ZONEMD Records in DBL RPZ Zones Break Unbound DNSSEC Priming From: ummeegge To: Michael Tremer Cc: development@lists.ipfire.org Date: Tue, 17 Feb 2026 19:14:18 +0100 In-Reply-To: <2D0CAAFA-FE31-441E-B0D8-CA74E51A9789@ipfire.org> References: <37FA5A19-27A8-4367-8350-DE3514456ABC@ipfire.org> <158b16aa7a943cfc02d5d444521b93bbe33f7e1e.camel@ipfire.org> <490AD19B-AFF1-48C2-A98B-F9095AC35FA2@ipfire.org> <9503d2dd19cd1e5c8597cfbed58c0182dabb1480.camel@ipfire.org> <2D0CAAFA-FE31-441E-B0D8-CA74E51A9789@ipfire.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Strange ?! Thanks for extracting the patch. Best, Erik Am Dienstag, dem 17.02.2026 um 15:44 +0000 schrieb Michael Tremer: > Hello, >=20 > I don=E2=80=99t quite know why, but rspamd considered this email very spa= mmy: >=20 > 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: , (default: T > (reject): [12.21/11.00] > [URL_OBFUSCATED_TEXT(9.00){type=3Dbracket_dots;url=3D > http://github.com;orig=3D=C2=A0ZONEMD RR (type 63) create phantom QNAME > trigger ;orig=3DZONEMD 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: , > mime_rcpts: >=20 > I don=E2=80=99t know what has caused the high score of the obfuscated URL > which already scored 9 out of a total 12.21 points. >=20 > The email also had "X-Spam: Yes=E2=80=9D set in its headers which did not > come from us. >=20 > I will extract the patch from the archive. >=20 > -Michael >=20 > > On 17 Feb 2026, at 12:29, ummeegge wrote: > >=20 > > Yes, have send it to the list. Have a bouncing message report "Hi, > > this > > is the Mlmmj program managing the > > mailing list. > >=20 > > 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. > >=20 > > Here is the list of the bounced messages: > > - 1725" .=20 > > In the list i can see it here > > https://lists.ipfire.org/development/20260217090707.492743-1-ummeegge@i= pfire.org/T/#u > > ??? > >=20 > > Am Dienstag, dem 17.02.2026 um 10:13 +0000 schrieb Michael Tremer: > > > Hello Erik, > > >=20 > > > Where has it been sent to? To this list? > > >=20 > > > I did not receive anything. > > >=20 > > > -Michael > > >=20 > > > > On 17 Feb 2026, at 09:18, ummeegge wrote: > > > >=20 > > > > Hello Michael, > > > > sure. Patch has been delivered. > > > >=20 > > > > Best, > > > >=20 > > > > Erik > > > >=20 > > > > Am Montag, dem 16.02.2026 um 16:11 +0000 schrieb Michael > > > > Tremer: > > > > > Hello Erik, > > > > >=20 > > > > > Thanks for the feedback. > > > > >=20 > > > > > Good to hear that your problem could be solved upstream. > > > > >=20 > > > > > Will you provide a patch to fix this in IPFire before the > > > > > next > > > > > release of Unbound? > > > > >=20 > > > > > -Michael > > > > >=20 > > > > > > On 16 Feb 2026, at 13:30, ummeegge > > > > > > wrote: > > > > > >=20 > > > > > > Yes, it took longer since I discovered it and I simply > > > > > > wanted > > > > > > to > > > > > > share > > > > > > the insights with you all =E2=80=93 thought it makes sense. > > > > > >=20 > > > > > > 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/16e1e6d375e93e6c00c9= b5d20ec4e50fb55d961f > > > > > > 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. > > > > > >=20 > > > > > > Have also tested the patch here now and it works like it > > > > > > should: > > > > > > AXFR/IXFR with multiple DBL zones, no problems at all. > > > > > >=20 > > > > > > Best, > > > > > >=20 > > > > > > Erik > > > > > >=20 > > > > > > Am Montag, dem 16.02.2026 um 11:35 +0000 schrieb Michael > > > > > > Tremer: > > > > > > > Hello Erik, > > > > > > >=20 > > > > > > > This is a *very* long email to tell us about a bug in > > > > > > > Unbound. > > > > > > >=20 > > > > > > > Did you report your problem there? > > > > > > >=20 > > > > > > > -Michael > > > > > > >=20 > > > > > > > > On 15 Feb 2026, at 11:58, ummeegge > > > > > > > > > > > > > > > > wrote: > > > > > > > >=20 > > > > > > > > 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. > > > > > > > >=20 > > > > > > > > Impact was here: > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0 DNSSEC Failure: Unbound does not ignore the ZO= NEMD > > > > > > > > record > > > > > > > > during > > > > > > > > RPZ processing and mistakenly interprets the zone apex > > > > > > > > record > > > > > > > > as a > > > > > > > > policy rule for the root name (.). > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0 Symptoms: After loading more than one IPFire R= PZ > > > > > > > > zone or > > > > > > > > modifying > > > > > > > > the configuration file and restarting/reloading > > > > > > > > Unbound, > > > > > > > > the > > > > > > > > resolver > > > > > > > > fails to prime its DNSSEC trust anchor. Typical log > > > > > > > > entries: > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0 unbound: info: rpz: applied [dbl-ads] . rpz-lo= cal- > > > > > > > > data . > > > > > > > > DNSKEY > > > > > > > > IN > > > > > > > > =C2=A0=C2=A0 unbound: info: failed to prime trust anchor --= could > > > > > > > > not > > > > > > > > fetch > > > > > > > > DNSKEY rrset . DNSKEY IN > > > > > > > >=20 > > > > > > > > Result: All DNSSEC validation fails, rendering the > > > > > > > > resolver > > > > > > > > unable > > > > > > > > to > > > > > > > > resolve any domain names and effectively breaking DNS > > > > > > > > resolution > > > > > > > > for > > > > > > > > the entire network. > > > > > > > >=20 > > > > > > > > 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. > > > > > > > >=20 > > > > > > > > Technical Cause: > > > > > > > >=20 > > > > > > > > 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 =E2=80= =93 > > > > > > > > this > > > > > > > > is > > > > > > > > IMHO > > > > > > > > an > > > > > > > > Unbound bug. > > > > > > > >=20 > > > > > > > > Loading process: > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0 Unbound reads the apex ZONEMD record. > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0 rpz_type_ignored(63) returns 0 =E2=86=92 recor= d gets > > > > > > > > processed. > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0 strip_dname_origin() removes the zone name =E2= =86=92 empty > > > > > > > > label > > > > > > > > (.). > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0 A rpz-local-data rule for . is created, blocki= ng > > > > > > > > root > > > > > > > > DNSKEY > > > > > > > > priming queries. > > > > > > > >=20 > > > > > > > > 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. > > > > > > > >=20 > > > > > > > > Reproduction Steps: > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0 Configure one IPFire DBL RPZ zone (e.g., > > > > > > > > ads.rpz.ipfire.org) > > > > > > > > following the instructions from > > > > > > > > https://www.ipfire.org/dbl/how-to-use=C2=A0. > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0 Restart Unbound =E2=86=92 zone gets cached (ma= y still work > > > > > > > > initially). > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0 Modify the configuration or add a second zone = and > > > > > > > > restart > > > > > > > > Unbound > > > > > > > > again =E2=86=92 priming failure appears in logs. > > > > > > > >=20 > > > > > > > > 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. > > > > > > > >=20 > > > > > > > > Current temporary workaround: > > > > > > > >=20 > > > > > > > > Remove ZONEMD records post-download via script (e.g., > > > > > > > > cron > > > > > > > > job > > > > > > > > after > > > > > > > > AXFR): > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0 sed -i '/IN[[:space:]]\+ZONEMD/d' > > > > > > > > /var/lib/unbound/*.rpz.ipfire.org.zone > > > > > > > >=20 > > > > > > > > Then reload Unbound. > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > While Unbound developers might likely investigate and > > > > > > > > may > > > > > > > > fix > > > > > > > > rpz_type_ignored() (Issue #1404), which way should > > > > > > > > IPFire > > > > > > > > users > > > > > > > > go > > > > > > > > until then =E2=80=93 since this blocks testing the Beta DBL > > > > > > > > usage > > > > > > > > with > > > > > > > > Unbound > > > > > > > > (great project)? Haven=C2=B4t tested a patched version of > > > > > > > > Unbound > > > > > > > > since > > > > > > > > i > > > > > > > > have currently no build environment around but if > > > > > > > > again, am > > > > > > > > happy > > > > > > > > to > > > > > > > > test preview versions! > > > > > > > >=20 > > > > > > > > May someone have similar problems or even another > > > > > > > > workaround or > > > > > > > > potential Fix for this ? > > > > > > > >=20 > > > > > > > > Best regards, > > > > > > > >=20 > > > > > > > > Erik > > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > >=20 > >=20