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 4fDPZQ4swlz332S for ; Sun, 15 Feb 2026 11:58:54 +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 4fDPZM1DXJz2xHk for ; Sun, 15 Feb 2026 11:58:51 +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 4fDPZL2zd0zQ5 for ; Sun, 15 Feb 2026 11:58:50 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1771156730; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=FGMmKlRrWh61wiLt71gPUowDTAhiojoO0bvkEAglT2I=; b=5fuVipWnPNluu5nVt+SBvfrN/qOe5sN56UdiVmuo8fWuDuxA6Gs0woKCEwuLf3VikDvjTt 4uTHq1erb1XW8NCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1771156730; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=FGMmKlRrWh61wiLt71gPUowDTAhiojoO0bvkEAglT2I=; b=Tj7y5Uh36v54liPV1vMJBZr8QbFLfNDog9pX03Es4lckdqxmDm2hG7cpg/xW+tVadKuZmw cSfrtzv6SPapWl/cJq/Sth+Le5Q2OPN84z9uNyMGlrqS78OCvLFoVJl7pyOoBJzErpoZjX ss9Nf/n3JWFTgrrMI91wln4N7KWXZH4weJTW+PDY0xmLCtjBhEyaot3bHSDNu/vY/oZHiW Ff4MhyqhcUGhz6PrCdwDyKNnLt8FcI2Ot8CEdp2b/zKjX/EhdQE0YAO6O2mU1w9XINpOKa CNYXSMLql0Rf2+vLjkMWsZqOuruVqKsr+HTNrM/CX494nM1MQgz600JkU9RZdw== Message-ID: Subject: ZONEMD Records in DBL RPZ Zones Break Unbound DNSSEC Priming From: ummeegge To: development@lists.ipfire.org Date: Sun, 15 Feb 2026 12:58:50 +0100 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 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. Impact was here: 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 (.). 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: 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 Result: All DNSSEC validation fails, rendering the resolver unable to resolve any domain names and effectively breaking DNS resolution for the entire network. 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. Technical Cause: 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. Loading process: Unbound reads the apex ZONEMD record. rpz_type_ignored(63) returns 0 =E2=86=92 record gets processed. strip_dname_origin() removes the zone name =E2=86=92 empty label (.). A rpz-local-data rule for . is created, blocking root DNSKEY priming queries. 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. Reproduction Steps: Configure one IPFire DBL RPZ zone (e.g., ads.rpz.ipfire.org) following the instructions from https://www.ipfire.org/dbl/how-to-use . Restart Unbound =E2=86=92 zone gets cached (may still work initially). Modify the configuration or add a second zone and restart Unbound again =E2=86=92 priming failure appears in logs. 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. Current temporary workaround: Remove ZONEMD records post-download via script (e.g., cron job after AXFR): sed -i '/IN[[:space:]]\+ZONEMD/d' /var/lib/unbound/*.rpz.ipfire.org.zone Then reload Unbound. 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 Unbo= und (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! May someone have similar problems or even another workaround or potential Fix for this ? Best regards, Erik