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

Ralf Weber <dns@fl1ger.de> Mon, 22 May 2023 20:19 UTC

Return-Path: <dns@fl1ger.de>
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 B9952C151548 for <dnsop@ietfa.amsl.com>; Mon, 22 May 2023 13:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
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 LaZvNG-su73q for <dnsop@ietfa.amsl.com>; Mon, 22 May 2023 13:19:11 -0700 (PDT)
Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id D619FC15152B for <dnsop@ietf.org>; Mon, 22 May 2023 13:19:09 -0700 (PDT)
Received: from [100.64.0.1] (p54b8a2be.dip0.t-ipconnect.de [84.184.162.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 3D8C95F407C9; Mon, 22 May 2023 20:19:07 +0000 (UTC)
From: Ralf Weber <dns@fl1ger.de>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: dnsop <dnsop@ietf.org>
Date: Mon, 22 May 2023 22:18:55 +0200
X-Mailer: MailMate (1.14r5964)
Message-ID: <458AA6C1-1183-4430-8545-7C8DB2CE6DA4@fl1ger.de>
In-Reply-To: <1BE5004E-B64D-407D-80F5-EB25D7BB671C@apple.com>
References: <1BE5004E-B64D-407D-80F5-EB25D7BB671C@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sua_0AiU3hVfDsk0Xcjj5Z85nmU>
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: Mon, 22 May 2023 20:19:14 -0000

Moin!

On 22 May 2023, at 18:20, Tommy Pauly wrote:
> 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?

As long as the OPT RR is properly formatted what it should be reading your description and the correct answer from 1.1.1.1 and 9.9.9.9 this should be ok, but it for sure would be good to have a bigger sample size, maybe including what software actually runs the service (which might be custom for some public resolvers).

So long
-Ralf
——-
Ralf Weber