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
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
