Re: [DNSOP] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

Mukund Sivaraman <muks@mukund.org> Thu, 02 July 2020 15:49 UTC

Return-Path: <muks@mukund.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 920A83A0852 for <dnsop@ietfa.amsl.com>; Thu, 2 Jul 2020 08:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 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, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mukund.org
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 nBInGo_2UkH7 for <dnsop@ietfa.amsl.com>; Thu, 2 Jul 2020 08:48:57 -0700 (PDT)
Received: from jupiter.mukund.org (jupiter.mukund.org [46.4.226.158]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92DAE3A084F for <dnsop@ietf.org>; Thu, 2 Jul 2020 08:48:50 -0700 (PDT)
Date: Thu, 2 Jul 2020 21:18:41 +0530
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mukund.org; s=mail; t=1593704928; bh=Cj/LxvsAyjTWw4Dx+PwYa44BHldNWAbayKOJPg9H9iE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=P8J7zXHF4kSTClxSjC2gy5yEdrObM2WpcjdRtnjlwUFc2OmuIgl9ub9Hot9b7BVFY N27x9NtxbJy7fppil8rsJMj2li7bwuY+TA6AlQvHIaj9/IB76ljj7+kPZnXQFVMQIQ eqwd/SbMjWshGEdSgS9nDVyJ51gLCb/gZzDbbRDQ=
From: Mukund Sivaraman <muks@mukund.org>
To: Paul Vixie <paul@redbarn.org>
Cc: dnsop@ietf.org, John R Levine <johnl@taugh.com>
Message-ID: <20200702154841.GA83916@jurassic.vpn.mukund.org>
References: <20200702011816.D4B0D1C3CD10@ary.qy> <2843010.V8yvLItfke@linux-9daj> <alpine.OSX.2.22.407.2007020949360.96330@ary.qy> <6402649.6cnN7U4pX5@linux-9daj>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh"
Content-Disposition: inline
In-Reply-To: <6402649.6cnN7U4pX5@linux-9daj>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DJS01c9RhTsI4yhvmDZ7RZG3Mz4>
Subject: Re: [DNSOP] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
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, 02 Jul 2020 15:49:05 -0000

On Thu, Jul 02, 2020 at 03:29:01PM +0000, Paul Vixie wrote:
> On Thursday, 2 July 2020 14:50:24 UTC John R Levine wrote:
> > On Thu, 2 Jul 2020, Paul Vixie wrote:
> > > ... but our goal should be to allow smart initiators to avoid
> > > retrying with TCP out of reflex. my recommendation of TC=0 is to suppress
> > > reflexive TCP retries.
> > I wouldn't disagree but it seems to me once again it's a tradeoff between
> > performance and correctness.  I'd prefer correctness, particularly since
> > it seems that the option to use what's in a truncated referral gets you
> > both.
> 
> TC=1 will, on several DNS initiators whose architecture i know, automatically 
> trigger TCP fallback, without regard to what's in the various sections. that 
> is often a layering constraint in the software, where "get the response" has 
> the fallback logic, and "look at the response" comes after that's completed.
> 
> > > 3. even without TC=1 you will know there's under-zonecut glue you didn't
> > > receive, because you saw the NS RR, and the only path to the address RR is
> > > through that NS RRset.
> > 
> > Well, maybe.  Even if you got one A record there might be others. 
> 
> no. truncation is on RRset boundaries. even in a truncated response, RRsets 
> are never broken up. if you have any A records for a name, you have them all.

IIRC truncation on RRset boundaries is not defined. This is usually why
initiators abandon the whole message when TC=1.

E.g., from RFC 1035 section 7.4:

> When a response is truncated, and a resolver doesn't know whether it
> has a complete set, it should not cache a possibly partial set of RRs.

implying that it may not be a complete set, and RFC 2181 section 9:

>   Where TC is set, the partial RRSet that would not completely fit may
>   be left in the response.  When a DNS client receives a reply with TC
>   set, it should ignore that response, and query again, using a
>   mechanism, such as a TCP connection, that will permit larger replies.

		Mukund