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 4fFkTx1Lzpz36XL for ; Tue, 17 Feb 2026 15:44:37 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (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 4fFkTs4F6sz2xLm for ; Tue, 17 Feb 2026 15:44:33 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4fFkTr05RHz1FW; Tue, 17 Feb 2026 15:44:31 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1771343072; 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=8ke7thfjc3Zu8Vwxvcd9dLH/GT4VBnSAYDsq8uy3Oho=; b=htCVTZsur0gkeYvXof3V4jyZOmygICTzq/zIEhLLHIs9MNpHY4rMV4TxWpA7v3nXeg2dt7 LB2z9WL7WX6cOFAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1771343072; 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=8ke7thfjc3Zu8Vwxvcd9dLH/GT4VBnSAYDsq8uy3Oho=; b=EgXzCIrRbc6WAJHex1rlgzLJfz+XDFE3nzO7Y1jCiD/ggsDcGPfBUwfPDATh5jHFa6/9nM JcqjP825ZR82c7QqlekNqTlcFtFgKmJgDHohqCSfccixF+Pg6NC9FsVPJbPVpMjJz8kins nZWTkGPvsmmgecFRZHx7CO7v8blhdUKeCpq3VtiSBAtUdeS+4FRMQpGN2MP5hnOrlmGAER 7AX0SOQoiGZYKx46ok0JrsjpV1uASV+v02ncT1vzTinvlyZIzVVDAL2k6yc0ZllsTL3IBo d6LCBSPxmDD0ZoyhmT35DST74TSrIpqrWfSiqasQek6t6NNKh7ydhlRVbGfDfw== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: ZONEMD Records in DBL RPZ Zones Break Unbound DNSSEC Priming From: Michael Tremer In-Reply-To: <9503d2dd19cd1e5c8597cfbed58c0182dabb1480.camel@ipfire.org> Date: Tue, 17 Feb 2026 15:44:31 +0000 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: ummeegge Hello, I don=E2=80=99t 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: , (default: T = (reject): [12.21/11.00] = [URL_OBFUSCATED_TEXT(9.00){type=3Dbracket_dots;url=3Dhttp://github.com;ori= g=3D ZONEMD 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%;},FO= RGED_RECIPIENTS_MAILLIST(0.00){},FORGED_SENDER_MAILLIST(0.00){},FROM_HAS_D= N(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.0= 0){},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: , mime_rcpts: = 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. The email also had "X-Spam: Yes=E2=80=9D 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 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@ipfi= re.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/16e1e6d375e93e6c00c9b5d20ec4e50= fb55d961f >>>>> 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 >>>>>>> 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 (.). >>>>>>>=20 >>>>>>> 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: >>>>>>>=20 >>>>>>>=20 >>>>>>> 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 >>>>>>>=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 >>>>>>> Unbound reads the apex ZONEMD record. >>>>>>>=20 >>>>>>> rpz_type_ignored(63) returns 0 =E2=86=92 record gets = processed. >>>>>>>=20 >>>>>>> strip_dname_origin() removes the zone name =E2=86=92 empty = label >>>>>>> (.). >>>>>>>=20 >>>>>>> A rpz-local-data rule for . is created, blocking 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 >>>>>>> Configure one IPFire DBL RPZ zone (e.g., >>>>>>> ads.rpz.ipfire.org) >>>>>>> following the instructions from >>>>>>> https://www.ipfire.org/dbl/how-to-use . >>>>>>>=20 >>>>>>> Restart Unbound =E2=86=92 zone gets cached (may still work >>>>>>> initially). >>>>>>>=20 >>>>>>> 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 >>>>>>> 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