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 4fF7733rhKz339q for ; Mon, 16 Feb 2026 16:11:11 +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) 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 4fF76z742bz2xXQ for ; Mon, 16 Feb 2026 16:11:07 +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 4fF76z17sGz1FF; Mon, 16 Feb 2026 16:11:07 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1771258267; 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=2MXiP8IaO+/Bw82DnmJEH8qCzch1XD0fMPgvKTac1DE=; b=GkPNIo7cVmgFaAQiZsIi65bxnZwOWiGazpnZMYM+urjljkSTvf8UB5lkAkkS6ccNhHDHO6 Ajs9edsaqhwTl6Bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1771258267; 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=2MXiP8IaO+/Bw82DnmJEH8qCzch1XD0fMPgvKTac1DE=; b=bWKFiSHYg6PpwZSXUfgGAvN/06kbdSvBibhlLFfOO80X4pzsHMEHuT9hCfZR6toqubPezo jbyOVNu4zqNS9WLpfQItYQ7B9F+sAsUgE7AFNsjBYDcCe0IymkzZka5ZAp6z2k9mta1CR0 Ntdhoog/IXtd6zH0hGerPdL/N2HuskvhXsS8lKEF3WNOwbfAXg0qrWlU9+zJsxuIH+Vd2A vPz3UyEpWraDS0lYQvC2+IUxO3ua/Lmm3j3Bez4quOMzbLYyNo+nvfSg/8loi6bCnn1AiV Hip0zELVu1WYlwAzBQqp/Z/xjaTZXVpRcMeEQwsUJ2+GcOQd5XcqvO4erqU7ww== 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: Date: Mon, 16 Feb 2026 16:11:06 +0000 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: <37FA5A19-27A8-4367-8350-DE3514456ABC@ipfire.org> References: To: ummeegge 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 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