IETF Logo Mail Archive

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

Ralf Weber <dns@fl1ger.de> Tue, 23 May 2023 09:21 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 D66B3C14CE53 for <dnsop@ietfa.amsl.com>; Tue, 23 May 2023 02:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 YVL6lcuYUPIT for <dnsop@ietfa.amsl.com>; Tue, 23 May 2023 02:21:04 -0700 (PDT)
Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 26AA2C14CE46 for <dnsop@ietf.org>; Tue, 23 May 2023 02:21:02 -0700 (PDT)
Received: from [100.64.0.1] (p4fc217f3.dip0.t-ipconnect.de [79.194.23.243]) (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 70D105F42AF0; Tue, 23 May 2023 09:20:59 +0000 (UTC)
From: Ralf Weber <dns@fl1ger.de>
To: Mark Andrews <marka@isc.org>
Cc: Petr Špaček <pspacek@isc.org>, dnsop@ietf.org
Date: Tue, 23 May 2023 11:20:59 +0200
X-Mailer: MailMate (1.14r5964)
Message-ID: <FE40AF47-8AB2-4823-B167-3379CC1D609C@fl1ger.de>
In-Reply-To: <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> <37179086-13A6-4840-BFCB-2C8349926AA2@isc.org>
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/NIH18OOe-vy4h1tVxBSKPwyJJcA>
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 09:21:10 -0000

Moin!

On 23 May 2023, at 9:45, Mark Andrews wrote:
>> 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.

No, the filtering is done by the server giving back NXDomain or something other than the actual authoritative data. The client can display the reason for filtering, but not decide if to filter or not.

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

I’m not following. Can you please explain it in more detail. From my understanding it just is a format for the EXTRA-TEXT field and if they client does not parse or understand it, it still can be displayed or used for debugging.

So long
-Ralf
——-
Ralf Weber

v2.23.0 | Report a Bug | By Email