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