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

Petr Špaček <pspacek@isc.org> Tue, 23 May 2023 07:11 UTC

Return-Path: <pspacek@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 906BBC15154E for <dnsop@ietfa.amsl.com>; Tue, 23 May 2023 00:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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=-0.001, 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="Mh/JGq/e"; dkim=pass (1024-bit key) header.d=isc.org header.b="PueQ3UGp"
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 F4tD_JF0vHND for <dnsop@ietfa.amsl.com>; Tue, 23 May 2023 00:11:20 -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 D53D3C15107F for <dnsop@ietf.org>; Tue, 23 May 2023 00:11:20 -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 02DCC3AB033 for <dnsop@ietf.org>; Tue, 23 May 2023 07:11:19 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 02DCC3AB033
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=1684825879; cv=none; b=qIT3vK5WNMVRuyjpib1SG1Bpxq8fv3Aw2bYGdGzc6gOHAZCa1E69Tjx4IkQOmVp3Xu+ZLv+S5kNzGcbNsVn4Br0ugI71TTjdkTn9t+eVYKQDs+g+ritI+xqovhtyQen+wbI0vr2q9COrAAyCY9Ec0+0ftkajbythWgjYvE1mvEQ=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1684825879; c=relaxed/relaxed; bh=OfyXXvErx/l6PfH4b872n1Bb6tR84l1/9QsRSGkR0FQ=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=UtpIGbWHKQlS31nDBva5v3ECu9r2jblex0FBmpXfAZSd9Wg3BnYy6jbrSn77jN1+rtlUf4+/Rw28ubqtEmZuLpP+3fDWjpmoh0vcFiPn0YsY592UPiWMV4TKzSY9lna2jGpAV2xa8ES+lgX7O+I9QFGl4oYfIYlqH8pajp3GPgI=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 02DCC3AB033
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1684825879; bh=OfyXXvErx/l6PfH4b872n1Bb6tR84l1/9QsRSGkR0FQ=; h=Date:Subject:To:References:From:In-Reply-To; b=Mh/JGq/eIkO8JKc+M6pQk81+6rHhoyZWMyQZFv3ok8gL+0eWGUs7DDlUO9EWDbgqv MLALO9y8jbZzM7kkBvqutba4bGheQxzZChL3U5kpdmXV+R1xKFBtZh4L3bgXCGlTGj OCB6aQPz59NkDR7pFoSOA195XrSr4fyO9ZaGrHLc=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id E50D310E8464 for <dnsop@ietf.org>; Tue, 23 May 2023 07:11:18 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 9F8F610E8468 for <dnsop@ietf.org>; Tue, 23 May 2023 07:11:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 9F8F610E8468
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1684825878; bh=OfyXXvErx/l6PfH4b872n1Bb6tR84l1/9QsRSGkR0FQ=; h=Message-ID:Date:MIME-Version:To:From; b=PueQ3UGpL6BtEpE7Iw5jaZ+4zx34AXNLF5eXIIxrHdd/ILaR/aGE4z7oxeyQNo9ff HKHDFvhpp9DNDHSrmQYbw/wQc6FbC94Gooyil9edH8f49WMxIOnJcwNBMnH35kWbL9 Nl2C9lna9g1MIoXafWtLvv3nBYQYFhwd0qIG1B78=
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 XHpmoi4Ox5JK for <dnsop@ietf.org>; Tue, 23 May 2023 07:11:18 +0000 (UTC)
Received: from [192.168.0.158] (ip-86-49-243-194.bb.vodafone.cz [86.49.243.194]) by zimbrang.isc.org (Postfix) with ESMTPSA id 0D95210E8464 for <dnsop@ietf.org>; Tue, 23 May 2023 07:11:17 +0000 (UTC)
Message-ID: <ef88a8d7-0c13-acff-a5fc-fdc0fb38de98@isc.org>
Date: Tue, 23 May 2023 09:11:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US
To: dnsop@ietf.org
References: <1BE5004E-B64D-407D-80F5-EB25D7BB671C@apple.com> <4A22932F-1980-438E-9B6A-176B82CECE50@isc.org> <A474412D-191B-48BD-8FC4-E07578E9C487@apple.com> <70B7A79D-9419-45C9-A4F7-CA3BCB8CB4D9@fl1ger.de>
From: Petr Špaček <pspacek@isc.org>
In-Reply-To: <70B7A79D-9419-45C9-A4F7-CA3BCB8CB4D9@fl1ger.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6XUf2fGP0VkjWZiMwuJi_I5pFGg>
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 07:11:25 -0000

On 23. 05. 23 7:03, Ralf Weber wrote:
> Moin!
> 
> On 23 May 2023, at 4:44, Tommy Pauly wrote:
> 
>> Thanks, Mark.
>>
>> For what it's worth, I just ran two other tests, and for both of these cases, all of the resolvers I tried did accept the request:
>> - Choose a new EDNS option code point (I just tested 50, randomly)
>> - Use EDE but set the length to 2 and the error to 0 (other error), rather than a length of 0
> 
> I don’t think we need a new code point. Just having a valid opt record without a further option will work as RFC8914 states:
> 
> The Extended DNS Error (EDE) option can be included in any response (SERVFAIL, NXDOMAIN, REFUSED, even NOERROR, etc.) to a query that includes an OPT pseudo-RR [RFC6891]. This document includes a set of initial codepoints but is extensible via the IANA registry defined and created in Section 5.2.
> 
> and as the mechanism in draft-ietf-dnsop-structured-dns-error just defines a special format for the EDE EXTRA-TEXT field the most backward compatible solution IMHO is just to rely on the mechanism defined in RFC8914, and not to define any special handling.
> 
> So I would propose 5.1 to be:
> 
> When generating a DNS query, the client includes the OPT pseudo-RR [RFC6891] to elicit the Extended DNS Error option in the DNS response.

I agree. Sending empty EDE in requests seems superfluous to me.

-- 
Petr Špaček
Internet Systems Consortium