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 4fFb8T5PxZz34Rc for ; Tue, 17 Feb 2026 10:14:01 +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 4fFb8Q2DTvz2xSm for ; Tue, 17 Feb 2026 10:13:58 +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 4fFb8P3bjKz1PK; Tue, 17 Feb 2026 10:13:57 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1771323237; 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=5A4gwYcOHnfgOFVsrp2X0IZqrgNs4Xf2ljOkYVC8BHE=; b=fbldaThEqvMRDRLqeWIwnRabst3C4pf+HL+eniNzeiDMkoVme2Foo9/sIBgTARGU4nbHO6 OwUkxQb4L/IuDkCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1771323237; 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=5A4gwYcOHnfgOFVsrp2X0IZqrgNs4Xf2ljOkYVC8BHE=; b=Xy7MGhpaWZ9ofnI5FPU1FK1mPE2FS9Bh26lLJEsTArNOftVf1TxGcnRrmcOCIicuiIjzLV 38HhryvuuN7zr/nB4DyLA6r5crA6rVm9a+TGa3tYL3AMfn9ujVm4BPxtU7PlViVZOPxU7F SvFM/SLY2xidixStUUOMVpPwcWa0Ier2QkmYoz4wFrG9sPoLHFZbO7sR/NzDsyXwopUew2 xClOwnhmqN3vIzEEOUfVJpfe18Hw1e/sSmyp4pCufvrUgr2JjZT4nCQ/czvzfm+L+aT7ih mP3x+7jbr0Vn8iSGpotTWwZXJnvAH/qnbHLG5gHbGcleenZOuVhA69gnN7+D9Q== 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: <158b16aa7a943cfc02d5d444521b93bbe33f7e1e.camel@ipfire.org> Date: Tue, 17 Feb 2026 10:13:57 +0000 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: <490AD19B-AFF1-48C2-A98B-F9095AC35FA2@ipfire.org> References: <37FA5A19-27A8-4367-8350-DE3514456ABC@ipfire.org> <158b16aa7a943cfc02d5d444521b93bbe33f7e1e.camel@ipfire.org> To: ummeegge 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 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