IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 21 November 2019 08:10 UTC

Return-Path: <ietf-dane@dukhovni.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 995E012085E for <dnsop@ietfa.amsl.com>; Thu, 21 Nov 2019 00:10:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 hudnMVJsAwaq for <dnsop@ietfa.amsl.com>; Thu, 21 Nov 2019 00:10:25 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC9112083A for <dnsop@ietf.org>; Thu, 21 Nov 2019 00:10:25 -0800 (PST)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id AC4B5332AD4 for <dnsop@ietf.org>; Thu, 21 Nov 2019 03:10:24 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAHbrMsBR6LZ880RXPDW2L+c_gcC6Tpg+L_c78OZvxJs4Gc4pUQ@mail.gmail.com>
Date: Thu, 21 Nov 2019 03:10:24 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: dnsop@ietf.org
Message-Id: <9641D361-6A98-4B4B-BAAD-20327194EC4B@dukhovni.org>
References: <yblzhgpwwit.fsf@wu.hardakers.net> <CAHbrMsBR6LZ880RXPDW2L+c_gcC6Tpg+L_c78OZvxJs4Gc4pUQ@mail.gmail.com>
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6lwiYlPPfM8kJ9ZJYRxqh1DEQ8E>
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 08:10:26 -0000

> On Nov 21, 2019, at 2:37 AM, Ben Schwartz <bemasc@google.com> wrote:
> 
> To be clear, we are talking only about the case where a response "fits" until the EDE is added, after which it exceeds the limit and is truncated.  If optimizing this situation is important, I would suggest adding a requirement to the EDE draft that EDE be the last option in OPT.  Then as a client, I can easily detect this situation, because the truncation point is in the middle of the EDE option.  The client logic then is very simple: if I don't care about EDE, I can ignore the TC bit.

Not sure what you mean by "in the middle of the EDE option", IIRC
truncation IIRCin DNS is never "in the middle" of an element, we
either send the whole element or don't send it.

For the OPT RR, I think that means that it includes a set of
complete options.

I do agree that truncation due to EDE should be rare, and therefore
also TCP failover as a result of such truncation, so if the consensus
is to keep it simple, so be it, but I don't see how how the client
could figure out what was left out...


-- 
	Viktor.

v2.23.0 | Report a Bug | By Email