Re: [DNSOP] Filtering and DNSSEC

Vladimír Čunát <> Thu, 25 November 2021 13:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 802C93A0889; Thu, 25 Nov 2021 05:37:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OBlHdM9uJ_Jq; Thu, 25 Nov 2021 05:37:30 -0800 (PST)
Received: from ( [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA6023A088C; Thu, 25 Nov 2021 05:37:25 -0800 (PST)
Received: from [IPV6:2001:1488:fffe:6:dcac:6e28:41bb:6697] (unknown [IPv6:2001:1488:fffe:6:dcac:6e28:41bb:6697]) by (Postfix) with ESMTPSA id 9CE26140813; Thu, 25 Nov 2021 14:37:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1637847441; bh=wfj3MN0pTyzXW+922wXj1aXdgiqdnduc69FJvaT7sSI=; h=Date:To:From; b=jjxjwCwftP1SELw4QDxXFCxVhJDGgcfyDf5nAvAFleL12nvbLgA7fG37rhN4ms/wC 2DnngXLSsyyaS0pN1bZ87WBFDO7eFi/ca3WNyNMXbhlbe+c3sSBadeTavItmcjx5qT lYYZr7RLhWA6QQxPfLrkRgIwSaA3ROfTbs0KDmXk=
Message-ID: <>
Date: Thu, 25 Nov 2021 14:37:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2
Content-Language: en-US
References: <>
From: Vladimír Čunát <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.102.4 at mail
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [DNSOP] Filtering and DNSSEC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Nov 2021 13:37:36 -0000

I realize this is tangential, but I believe it's important over the long 

Any modification of DNS will break *later* DNSSEC validation.  As 
filtering seems almost always done by DNS modification (e.g. NXDOMAIN), 
and I see significant trends in doing filtering as a service, there's a 
problem that DNSSEC gets crippled from the filterer onwards.

I can't realistically see moving *all* filtering use cases into end 
clients, but I'd really hate for DNSSEC to meet the same fate and I 
don't think it's necessary at all.  In other words, we need a model 
where upstream DNS service is trusted with filtering but not with 
DNSSEC.  Now perhaps if validation was done directly in a browser, it 
might choose that only "positive" answers get validated and the rest is 
trusted (encrypted link etc), but generally I wouldn't do that, as it 
would surely create some holes in DANE or elsewhere.

What we already have is SERVFAIL.  That's what validators MUST return 
instead of the forged answer (since the beginning of DNSSEC).  And 
actually it does the filtering job, as the SERVFAILed services won't be 

With EDE (RFC 8914) indicating a few kinds of filtering, servers and 
clients now could make some behavior better suited for these cases, 
around fallback to other servers, maybe caching, etc. (Say, only if it 
came over a trusted channel, based on local policy.)  I suspect there's 
currently still lots of room for improvement on implementation side 
here.  And orthogonally, structured-error-page or other mechanism could 
extend the available information in these *SERVFAIL* answers and perhaps 
get utilized in web browsers.

I do realize that SERVFAIL isn't ideal approach to blocking, but I can't 
really see anything better (or similar) that could reconcile DNSSEC with 
some of the common filtering use cases.

--Vladimir |