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

[Mukund Sivaraman <[e-mail]>]

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