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 07:45 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 A3ADCC151078 for <dnsop@ietfa.amsl.com>; Tue, 23 May 2023 00:45:39 -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="m9PgQlad"; dkim=pass (1024-bit key) header.d=isc.org header.b="FPPJFXg4"
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 Fgl3O-ejJ3IG for <dnsop@ietfa.amsl.com>; Tue, 23 May 2023 00:45:35 -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 4D906C151554 for <dnsop@ietf.org>; Tue, 23 May 2023 00:45:35 -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 9D8A73AB21A for <dnsop@ietf.org>; Tue, 23 May 2023 07:45:34 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 9D8A73AB21A
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=1684827934; cv=none; b=UIvnEuungbIS2aGNDGVgGX87mdeGDxpt0htWtHiqRvxmp2Reyd0fF3msaWczIlbVHorvJUgcR0AjT+XaDGvesIV4LJpN25sLEzkCA9e8AAWYSKGMq7t99qiA/rOMFUJghmwTJZigK8Udwdrph0uIVgMA2fDvTE8gZQVGHAa2Q+Y=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1684827934; c=relaxed/relaxed; bh=jSiQmm6kD/BfyO8YEcYFmd3Q7OmDfwWWNQtpkFQiQ7E=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=jC9rJPqAIiOSBmzqe1hLWOsPVgDkgkv+YXHG2AKk0IQI8cEmBh5/P6wDqpTTpH7+dQV2BTSqIxuPupd1ua+yQDBOvHx041IiZNqV48mN29rBeDO1WgxBirUCLfu8fWEr0Lrj8BwKhn3fcGLfYynYx15anZmCjoEj7S+gAliL5rE=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 9D8A73AB21A
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1684827934; bh=gjSu2T/i93+kH4b7nkndfq8mMNARJQlVLAExx8QlA9I=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=m9PgQladcdc/C3+M42IpDnKKbNilo1UlFV1s8mL1SSKek43r0zS5a0rsqQn4rwNaj 9GITA0IBT2DzLq1SpJiSpH0l7FeusNepOZHciBzsi1MPS/1mjaWh2O/y56rNu1MVtN pNld7TX7pzoMQsx9M/6OkN/pCUXO/eoS27a2+yeY=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 3BC8110E863A; Tue, 23 May 2023 07:45:34 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 1184110E863D; Tue, 23 May 2023 07:45:34 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 1184110E863D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1684827934; bh=jSiQmm6kD/BfyO8YEcYFmd3Q7OmDfwWWNQtpkFQiQ7E=; h=Mime-Version:From:Date:Message-Id:To; b=FPPJFXg406Wln9VavS19/QIcqUfxzOGOCnpDeLcq69s7X6eooo0Q/1k7S+K+QyN8z gpjHhIrfnUGyvt3slK53Eu6Hb2yAtEdjHlv+yZX8Qu7En9vXrV2zrnCC0OzjmBudo1 NEmOVoxD5+qHZHR0EJ2jwTDvVmPDYa1o5v2wPfuc=
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 yzn1QGn3FMml; Tue, 23 May 2023 07:45:33 +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 621E210E863A; Tue, 23 May 2023 07:45:33 +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: <ef88a8d7-0c13-acff-a5fc-fdc0fb38de98@isc.org>
Date: Tue, 23 May 2023 17:45:20 +1000
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <37179086-13A6-4840-BFCB-2C8349926AA2@isc.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> <ef88a8d7-0c13-acff-a5fc-fdc0fb38de98@isc.org>
To: Petr Špaček <pspacek@isc.org>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Pt47Mn62lVGyW_paE2cqatZsTrs>
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:45:39 -0000


> On 23 May 2023, at 17:11, Petr Špaček <pspacek@isc.org> wrote:
> 
> 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.

The point of adding it to the request is to signal that that client will do the filtering.

Even if signalling is removed the current text is incompatible with EDE.  Read it in “perverse” mode (client will be stupid).

> -- 
> Petr Špaček
> Internet Systems Consortium
> 
> _______________________________________________
> 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.46.0 | Report a Bug | By Email | System Status