IETF Logo Mail Archive

Re: [DNSOP] Consensus suggestion for EDE and the TC bit

Ray Bellis <ray@bellis.me.uk> Thu, 21 November 2019 17:03 UTC

Return-Path: <ray@bellis.me.uk>
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 139FD120B44 for <dnsop@ietfa.amsl.com>; Thu, 21 Nov 2019 09:03:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=portfast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNZBgWB9By8z for <dnsop@ietfa.amsl.com>; Thu, 21 Nov 2019 09:03:48 -0800 (PST)
Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B0C4120890 for <dnsop@ietf.org>; Thu, 21 Nov 2019 09:03:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1NDQHSoHeMGXHYcaUeKyxy4jbB1LPhQcJ//4ENmNRmI=; b=Q05ETcjyIZnjpVCzzab0K4cz8 xMDPUXhl1VJqpT2L81rpniu1j91euq6cTw3Lk54heIn6Y+V/FY5pdWN0ZvFiezW0mayiAV54X5bKb ANQ67lOOJOyCg31MXbGWZwp6MsuiKc2H6ukjND7DJU57He/oj7bobHwdoweBnWaeCKR/E=;
Received: from bb121-6-214-58.singnet.com.sg ([121.6.214.58]:35600 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1iXprt-0002Lq-S8 (Exim 4.89) for dnsop@ietf.org (return-path <ray@bellis.me.uk>); Thu, 21 Nov 2019 17:03:46 +0000
To: dnsop@ietf.org
References: <yblzhgpwwit.fsf@wu.hardakers.net> <CAHbrMsBR6LZ880RXPDW2L+c_gcC6Tpg+L_c78OZvxJs4Gc4pUQ@mail.gmail.com>
From: Ray Bellis <ray@bellis.me.uk>
X-Pep-Version: 2.0
Message-ID: <81b64ed1-3b0a-e323-ab4f-b3ab89a14775@bellis.me.uk>
Date: Fri, 22 Nov 2019 01:03:42 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <CAHbrMsBR6LZ880RXPDW2L+c_gcC6Tpg+L_c78OZvxJs4Gc4pUQ@mail.gmail.com>
Content-Type: multipart/mixed; boundary="------------96B7468264BB64DBAEB05481"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/b8T36ngDYCY-T1gCVuVEH16NXMY>
Subject: Re: [DNSOP] Consensus suggestion for EDE and the TC bit
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 21 Nov 2019 17:03:50 -0000


On 21/11/2019 15:37, Ben Schwartz wrote:

> I would suggest adding a requirement to the EDE draft that EDE be
> the last option in OPT

And what if some other future option wants to lay claim to that requirement?

> Then as a client, I can easily detect this situation, because the 
> truncation point is in the middle of the EDE option.

A conformant server should never crop a packet in the middle of an RR
when truncating such that the resulting packet is unparsable (implied by
RFC 1035 §6.2)

Also, an EDNS conformant server MUST include an OPT RR in its
response to a query that contained an OPT RR, even when truncating.
(RFC 6891 §6.1.1, §7).

Ray

v2.23.0 | Report a Bug | By Email