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 4fF3YT2d8Tz32m8 for ; Mon, 16 Feb 2026 13:30:21 +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) 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 4fF3YP4kJBz2xMK for ; Mon, 16 Feb 2026 13:30:17 +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 4fF3YN54wMz31f; Mon, 16 Feb 2026 13:30:16 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1771248616; 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=NtvQw7YnDMRcBFcs5qZz4+gwHKR9s2JmQom8Y3igVGw=; b=YPZzF6FbbnJzxr6i4OTQvsxa1fM2ipEzmwiXIjSuoEoxqeKlZPUGbxGdWNVwfwTAVRpxPk uBia4p8ABe74DHCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1771248616; 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=NtvQw7YnDMRcBFcs5qZz4+gwHKR9s2JmQom8Y3igVGw=; b=C7Z4aESWfWq8UPx3r4JNt8SDj5OJpColVPXPaTnW/nqhWX8dFy+AmOceqj6DOaMo3njaWY rMk278e7ZxjrFlPpCc2SlYvkTbqwyRm2ptpsVAzlE5u1tGI1zMxnfQFptWrOCdCExCmLmk OfUR5CkBWGhx8LGZFKAg0isLgtGewEJpkqI4QFR2G4LhhmV/iqjuugjNjgnEe8uRBgeN4g dAaCGYMN+Ak3DHEVJAdlU1M9KZP3eFYcjOTHPSFvBfQhGxEZYRJ27+IVT0+4iikKVdH9xR zncMl4GwRvzOJV5D7JQB5JMqP6pHNO2bry/Y4P3Gnvq/guwRDxmAzDex6eX1CQ== Message-ID: Subject: Re: ZONEMD Records in DBL RPZ Zones Break Unbound DNSSEC Priming From: ummeegge To: Michael Tremer Cc: development@lists.ipfire.org Date: Mon, 16 Feb 2026 14:30:12 +0100 In-Reply-To: References: 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, 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. 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/16e1e6d375e93e6c00c9b5d20ec4e50f= b55d961f 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. Have also tested the patch here now and it works like it should: AXFR/IXFR with multiple DBL zones, no problems at all. Best, Erik 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 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-local-data . D= NSKEY > > IN > > =C2=A0=C2=A0 unbound: info: failed to prime trust anchor -- could not f= etch > > 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 gets proce= ssed. > >=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 root DNSK= EY > > 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.or= g) > > 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 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