Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 13 November 2019 23:05 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 4072112083A for <dnsop@ietfa.amsl.com>; Wed, 13 Nov 2019 15:05:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 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, URIBL_BLOCKED=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 FyJbe7u4jCOJ for <dnsop@ietfa.amsl.com>; Wed, 13 Nov 2019 15:05:50 -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 A4979120837 for <dnsop@ietf.org>; Wed, 13 Nov 2019 15:05:50 -0800 (PST)
Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (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 B5A1332C827 for <dnsop@ietf.org>; Wed, 13 Nov 2019 18:05:49 -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: <ybl4kz7gzlc.fsf@w7.hardakers.net>
Date: Wed, 13 Nov 2019 18:05:47 -0500
Content-Transfer-Encoding: 7bit
Reply-To: dnsop@ietf.org
Message-Id: <F04D10EC-4185-4F78-9EF1-12033DCE766F@dukhovni.org>
References: <CADyWQ+FG7qzPnLkUH7mSBca=1NfXy6YduHD4UdmcfXFjD8xC6g@mail.gmail.com> <CA+9_gVuwAEthi9HU2wdw+Vf+STCwvXr4wOB4PRD_Hej6JPPbuQ@mail.gmail.com> <yblr241z4s8.fsf@w7.hardakers.net> <CA+9_gVvqqKwrkM7WYuEGGzfy+DSm3TzwmCDXA+AyyQ3c0Hr8wg@mail.gmail.com> <yblzhgzhd8b.fsf@w7.hardakers.net> <94DB2B7E-31E5-4D52-A8AA-F2354209F250@dukhovni.org> <ybl4kz7gzlc.fsf@w7.hardakers.net>
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Hrx_ToCBD4MLoNTkwTA3ZMwym8c>
Subject: Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error
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: Wed, 13 Nov 2019 23:05:52 -0000


> On Nov 13, 2019, at 5:50 PM, Wes Hardaker <wjhns1@hardakers.net>; wrote:
> 
>>> I added this text to the next version:
>>> 
>>>     <t>When the response grows beyond the requestor's UDP payload
>>>     size <xref target="RFC6891" />, servers SHOULD truncate messages
>>>     by dropping EDE options before dropping other data from
>>>     packets.  Implementations SHOULD set the truncation bit when
>>>     dropping EDE options.</t>
>> 
>> Are you sure that setting TC=1 when EDE doesn't fit is the right
>> trade-off?  I'm somewhat skeptical...
> 
> Well, that's what the other specs say.  We could break from that, you're
> right, and it's a discussion I was going to mention in Singapore for
> that matter.

A colleague suggested that would could use another bit (from the EDNS
flags field, say bit 14 adjacent to DO) to signal that non-essential
diagnostic information was left out.  Resolvers can then choose to
retry over TCP only if they deem it important to retrieve and use
EDE information.

It'd be a shame (though admittedly not frequent) to have a resolver
retry over TCP just to get the same answer with additional information
it does not need and perhaps does not even understand.

Of course this only matters in the rare (when not specifically elicited
by carefully crafted queries) case that it is the EDE options that push
the packet over the UDP size limit, and the rest of the payload would
otherwise just fit.  Perhaps on that basis the extra bit is not warranted.
We could just say that EDE can be silently dropped, or could leave the
text as proposed, with EDE occasionally eliciting "avoidable" TCP retries.

-- 
	Viktor.