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

Paul Vixie <> Thu, 02 July 2020 15:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD5D03A0835 for <>; Thu, 2 Jul 2020 08:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yN0zVnwG7pHI for <>; Thu, 2 Jul 2020 08:29:02 -0700 (PDT)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B8D7F3A0833 for <>; Thu, 2 Jul 2020 08:29:02 -0700 (PDT)
Received: from linux-9daj.localnet ( []) (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 (Postfix) with ESMTPSA id 5CBE6B0588; Thu, 2 Jul 2020 15:29:02 +0000 (UTC)
From: Paul Vixie <>
To:, John R Levine <>
Date: Thu, 02 Jul 2020 15:29:01 +0000
Message-ID: <6402649.6cnN7U4pX5@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: <>
Subject: Re: [DNSOP] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Jul 2020 15:29:05 -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 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).