From nobody Mon May 22 17:00:27 2023 Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: <1BE5004E-B64D-407D-80F5-EB25D7BB671C@apple.com> Date: Tue, 23 May 2023 10:00:04 +1000 Cc: dnsop 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 X-Mailer: Apple Mail (2.3731.500.231) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2023 00:00:27 -0000 > On 23 May 2023, at 02:20, Tommy Pauly = wrote: >=20 > Hello DNSOP, >=20 > In draft-ietf-dnsop-structured-dns-error, there=E2=80=99s a = description of how clients should indicate that they understand extended = DNS errors (EDE) by sending an empty EDE option.=20 >=20 > = https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-02.h= tml#name-client-generating-request >=20 > 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. >=20 > However, in testing this out, I=E2=80=99m 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: >=20 > 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 >=20 > 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.=20 > Best, > Tommy > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org