IETF Logo Mail Archive

Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

Mark Andrews <marka@isc.org> Tue, 23 May 2023 00:00 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DAFC14CF13 for <dnsop@ietfa.amsl.com>; Mon, 22 May 2023 17:00:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b="OK48SgRo"; dkim=pass (1024-bit key) header.d=isc.org header.b="NRUFXYNQ"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtwF5-3xxp5q for <dnsop@ietfa.amsl.com>; Mon, 22 May 2023 17:00:22 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD6BC14F749 for <dnsop@ietf.org>; Mon, 22 May 2023 17:00:22 -0700 (PDT)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 053763AB021; Tue, 23 May 2023 00:00:22 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 053763AB021
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.1.12
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1684800022; cv=none; b=iX8LBOOM7CYnA56YbzK/63c+ShA8NLdITj3kQO1/Ws3xBN8WkyXiJXGL2aDN8CmY3Ay1XmI3pJhIvakAnfN8wjSvxlxhX6InrXKZ1VK7yAVl5HyMfnK+1mZnGhRbirMKD8umGHzrxHgzUcmm7jLuPJB0cnC0oxKDMkv4tB8+Stg=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1684800022; c=relaxed/relaxed; bh=TSbiQw9Lzq9XRVRZndC0Mh4D1q20ovXIQHquZO9HX0M=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=duafAlLvb+laliHN6xnUpF1AFOI0JhAKQi6bCR8ic/F+Zm0b9/DtXIDIN95VkFWRIlk3Z5W5bZ+XoGz3mH0UIJBSNQYaNfKN8ULecky1Dm/693RjnMKOhPw94WJGi13u/huxnSzcjS4AaxIb5Sv5KGYFacz60eDqctHUF0Sb1E8=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 053763AB021
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1684800022; bh=BH5PWb31Uxaw8T3As31yAj9JDOq+Y5wYVFKo7CiCWLk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=OK48SgRoakTKFvJ/JkwA49Rqr5+jPd98wxS4KbadJJbx4mWrSfIlZYwazN9VwJFd8 TGVbVpAqwFB2RYwg0K98bYdKTT2RKligagxl1cQu7pELaKcUWm2ACnIwCe3j2M7d+5 sf0Ts8AjsfqyI5v/PDUWv5EY6pe/pb6FoaBsH4l4=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id EC3AE10E7FED; Tue, 23 May 2023 00:00:21 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id C057B10E7FEF; Tue, 23 May 2023 00:00:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org C057B10E7FEF
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1684800021; bh=TSbiQw9Lzq9XRVRZndC0Mh4D1q20ovXIQHquZO9HX0M=; h=Mime-Version:From:Date:Message-Id:To; b=NRUFXYNQkFAKH9kdj6noR65rpEhA7gHY3/k59eq6PuY9IyfNdBH10XA9yzDeEkPvc chDuKC2CF8cqEhBSigvL8HbqUhYkmFhDVR+b1IwRJgQmUoVHg9vcinjnL+0tsLTx+c rlJJRhxjSByWKRpkW/byocXKPas3h6UAfaUwk6vQ=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gpXIX9vCobhX; Tue, 23 May 2023 00:00:21 +0000 (UTC)
Received: from smtpclient.apple (n49-187-27-239.bla1.nsw.optusnet.com.au [49.187.27.239]) by zimbrang.isc.org (Postfix) with ESMTPSA id C303710E7FED; Tue, 23 May 2023 00:00:20 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <1BE5004E-B64D-407D-80F5-EB25D7BB671C@apple.com>
Date: Tue, 23 May 2023 10:00:04 +1000
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A22932F-1980-438E-9B6A-176B82CECE50@isc.org>
References: <1BE5004E-B64D-407D-80F5-EB25D7BB671C@apple.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BIbsGeOnsvue4Viei8VRGaLgJKA>
Subject: Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 May 2023 00:00:27 -0000


> On 23 May 2023, at 02:20, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
> 
> Hello DNSOP,
> 
> In draft-ietf-dnsop-structured-dns-error, there’s a description of how clients should indicate that they understand extended DNS errors (EDE) by sending an empty EDE option. 
> 
> https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-02.html#name-client-generating-request
> 
> This is something that makes a lot of sense to me, and provides a great way to indicate that a client would prefer to receive proper blocked/filtered errors (with possible extra text) as opposed to a forged answer.
> 
> However, in testing this out, I’m seeing inconsistent compatibility with some public resolvers. I was testing enabling this for encrypted resolvers only, and I see the following behavior for a sampling of resolvers using DoH:
> 
> 1.1.1.1 - NOERROR, works fine!
> 9.9.9.9 - NOERROR, works fine!
> 8.8.8.8 - FORMERR on all responses
> dns.adguard-dns.com - SERVFAIL on all responses
> 
> Do we think that this should be allowed in queries (and thus this is a bug in resolvers like 8.8.8.8 or AdGuard)? Or is there a problem with the approach this document is suggesting?

RFC 8914 left whether EDE in requests was permitted or not undefined.  I can see an EDE implementation making the option parser return FORMERR if the EDE option length was less than 2 and applying that to both requests and responses.  RFC 8914 really should have said that EDE in requests should be ignored and then there would have been a possibility on extending behaviour based on adding EDE to a request.  We are already 10 years into trying to fix unknown EDNS option behaviour and are still getting FORMERR on unknown EDNS options in requests.  If the working group want to allow extending EDE by adding it to a request is should obsolete RFC 8914 now with RFC8914bis that specifies that EDE in requests are to be ignored.

At the moment draft-ietf-dnsop-structured-dns-error-02 really should use another EDNS option code point.  It really is not backwards compatible with EDE the way it is currently specified. 


> Best,
> Tommy
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email