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 4fFf8Z44p2z34RR for ; Tue, 17 Feb 2026 12:29:18 +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) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4fFf8W0xj8z2xXH for ; Tue, 17 Feb 2026 12:29:15 +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 4fFf8T74DGz2mK; Tue, 17 Feb 2026 12:29:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1771331354; 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=4UDmUcxldv6UYFdYdylJJ9FqbLKdd7sz82vGTXhG8Zg=; b=NsYaVCqnQVBKepK1wmf34XgkqQPEpCEgQvdhlThjjI7X22YVoRe5ROnY06j2FT3f2K4egs vyCUqh/0akezjZxQ3G+IOAl1XSsRYDSYbXZVhEctVW7DXJJKsqOIvww5YPNQ4dZEobFIzS KZjBGbuXM5ni7BZ1qKl+qC4ATsFBENpps9IDOlQNDyP370m5qFbH9pk3aMUFsGwhBZ6T+T 486upN48r2CHItT3Ie8jCBAvl6LRLWGMp79Ip1NZOHNNiDo4h7aQ96zLOr9BGPCy+2d4ym u4VZ5szkWMxnf7vdABHK91sluTOQNXNDaDmxsCLAjkCcx0PLw0atKfVO73/kXw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1771331354; 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=4UDmUcxldv6UYFdYdylJJ9FqbLKdd7sz82vGTXhG8Zg=; b=pMNDyHYrs9bgNUGIFg9A3YoAjW89lcQZJvJvMfXIhsYOsTazFzF+90kpm9LfkXg9kUjQbz Rxdy5m13ZhmFZGDA== Message-ID: <9503d2dd19cd1e5c8597cfbed58c0182dabb1480.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 13:29:09 +0100 In-Reply-To: <490AD19B-AFF1-48C2-A98B-F9095AC35FA2@ipfire.org> References: <37FA5A19-27A8-4367-8350-DE3514456ABC@ipfire.org> <158b16aa7a943cfc02d5d444521b93bbe33f7e1e.camel@ipfire.org> <490AD19B-AFF1-48C2-A98B-F9095AC35FA2@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 Yes, have send it to the list. Have a bouncing message report "Hi, this is the Mlmmj program managing the 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" .=C2=A0 In the list i can see it here https://lists.ipfire.org/development/20260217090707.492743-1-ummeegge@ipfir= e.org/T/#u ??? 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/16e1e6d375e93e6c00c9b5d2= 0ec4e50fb55d961f > > > > 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 ZONEMD > > > > > > 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 RPZ z= one 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-local-= data . > > > > > > DNSKEY > > > > > > IN > > > > > > =C2=A0=C2=A0 unbound: info: failed to prime trust anchor -- cou= ld 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 record ge= ts 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, blocking r= oot > > > > > > 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 (may st= ill 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 usa= ge > > > > > > 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