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 4fF1105GgBz32m8 for ; Mon, 16 Feb 2026 11:35:32 +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 4fF10x1Spqz2xSL for ; Mon, 16 Feb 2026 11:35:29 +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 4fF10v3jzbz2T8; Mon, 16 Feb 2026 11:35:27 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1771241727; 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=tlxN6EVUKS0rPdmjJhWKybAJlQFuf/fRIMx/14sxblw=; b=if0VdWk6O4aY22HFTzLgwyTTxXHetlhe4xcbsYpE3hUlPWLlQoRoH1PuavXRAlGxXCQiFa 8jR4i7yHBKRaLuDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1771241727; 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=tlxN6EVUKS0rPdmjJhWKybAJlQFuf/fRIMx/14sxblw=; b=HnkP/Iv32dhm6FFfPgsD8B7LdAM9lo5mb4xyEicPhswi7YqbzPxVXfEF6a8Of2LFYD3nh7 xZekx5X6ef5q1AB0bxteVx9+udWHCEPfk1HhaTlpnCyZyImMdUnCyvoSG7HivM1+e6dC0z hC1IMtR+Qx1edFIC0xkhjgKYNtVXn4rI5d8PHDcnHujLc+6Bg5EQtP7+Qd9nPj06HI1GNM TIyuYLW5kcKHdyN5oz+i2VDAiOBdUxf2iAV92VQf9mtaiFsqOxsBWMwayqsP/bistY8BbW tpFclMzw3cxtdoScK2IgjmTfhYi7DiBMtMqZ+37ceTkmav/LyN449by043fadg== 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 11:35:26 +0000 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: ummeegge Hello Erik, This is a *very* long email to tell us about a bug in Unbound. Did you report your problem there? -Michael > 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