Re: [DNSOP] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
Paul Vixie <paul@redbarn.org> Sat, 04 July 2020 22:58 UTC
Return-Path: <paul@redbarn.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 A54D03A11B9 for <dnsop@ietfa.amsl.com>; Sat, 4 Jul 2020 15:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dPrdAVHW5d6z for <dnsop@ietfa.amsl.com>; Sat, 4 Jul 2020 15:58:42 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF4F3A11B8 for <dnsop@ietf.org>; Sat, 4 Jul 2020 15:58:42 -0700 (PDT)
Received: from linux-9daj.localnet (dhcp-166.access.rits.tisf.net [24.104.150.166]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 281CCB0588; Sat, 4 Jul 2020 22:58:40 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org, John R Levine <johnl@taugh.com>
Date: Sat, 04 Jul 2020 22:58:39 +0000
Message-ID: <1734668.YOVlOlHUhS@linux-9daj>
Organization: none
In-Reply-To: <alpine.OSX.2.22.407.2007020949360.96330@ary.qy>
References: <20200702011816.D4B0D1C3CD10@ary.qy> <2843010.V8yvLItfke@linux-9daj> <alpine.OSX.2.22.407.2007020949360.96330@ary.qy>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/x22jYu1efFp6d6iS5Ak5DITzhVI>
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: Sat, 04 Jul 2020 22:58:44 -0000
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. > Or if > you got an AAAA record but no A record and you're on an IPv4 network, you > can't tell whether there's a lurking A record or not, or vice-versa. > (See the glue for j.zdnscloud.com in the root.) that's why my proposal was to only avoid setting TC=1 if some minimal amount of glue does fit, specifically two RRsets of each address type (AAAA and A). > If we do it your way, if any NS is in-zone and the lookups fail, you > *always* need to do a TCP query just to see if if the UDP response left > something out. in the statement, "if in-zone and failures then TCP" does not warrant the use of the word "always" which is either redundant (that's what if/then means) or misleading (failures aren't the norm). i am ok with having to use TCP when not all glue fits, and the part that does fit, refers to currently-unreachable servers. a zone for whom two of its servers, on all of their address types, are down is going to see serious slowdown due to timeouts. so, already a bad day well worth avoiding. getting additional TCP fallback is additive not multiplicative to the badness costs in that non-normal situation. > > R's, > John > > PS: I'm less worried about round-robin DNS, since then it's clearly a > deliberate decision by the parent to leave some of the answers out. here, round-robin is an access method used for populating a section, and in this case the section is additional-data not answer. so, round-robin and random-robin should behave similarly in the truncation path we're discussing, where i'm saying the truncation would be better off silent (TC=0). -- Paul
- [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-… Peter van Dijk
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-… Wessels, Duane
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-… Paul Vixie
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-gl… Paul Hoffman
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-gl… Wessels, Duane
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-gl… John Levine
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-gl… Wessels, Duane
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-gl… John R Levine
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-… Jan Včelák
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-… Paul Vixie
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-… Jan Včelák
- Re: [DNSOP] partial glue is not enough, I-D Actio… John Levine
- Re: [DNSOP] partial glue is not enough, I-D Actio… Mark Andrews
- Re: [DNSOP] partial glue is not enough, I-D Actio… Paul Vixie
- Re: [DNSOP] partial glue is not enough, I-D Actio… Paul Vixie
- Re: [DNSOP] partial glue is not enough, I-D Actio… John R Levine
- Re: [DNSOP] partial glue is not enough, I-D Actio… Paul Vixie
- Re: [DNSOP] partial glue is not enough, I-D Actio… Mukund Sivaraman
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… Paul Hoffman
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… Brian Dickson
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… Shane Kerr
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… Masataka Ohta
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… John Levine
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… Brian Dickson
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… John R Levine
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… Brian Dickson
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… John R Levine
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… Mukund Sivaraman
- Re: [DNSOP] partial glue is not enough, I-D Actio… Paul Vixie
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… Paul Hoffman
- Re: [DNSOP] partial glue is not enough, I-D Actio… Havard Eidnes
- Re: [DNSOP] partial glue is not enough, I-D Actio… Joe Abley
- Re: [DNSOP] partial glue is not enough, I-D Actio… Havard Eidnes
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… Masataka Ohta
- Re: [DNSOP] partial glue is not enough, I-D Actio… Paul Vixie
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… John Levine
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… Mark Andrews
- Re: [DNSOP] [Ext] partial glue is not enough, I-D… Masataka Ohta
- Re: [DNSOP] draft-ietf-dnsop-respsize, was partia… John Levine
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-gl… Brian Dickson
- Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-gl… Peter van Dijk