On Wed, Apr 15, 2020 at 08:27:08PM +0200, Florian Weimer wrote: > >> I don't understand your PTR example. It seems such a fringe case that > >> people produce larger PTR responses because they add all virtual hosts > >> to the reverse DNS zone. Sure, it happens, but not often. > > > > I think it's probably more a matter of the concurrent lookups from > > multiple nameservers (e.g. local, ISP, and G/CF, where local has > > fastest round-trip but not much in cache, G/CF has nearly everything > > in cache but slowest round trip, and ISP is middle on both) than lack > > of tcp fallback that makes netstat etc. so much faster. > > The question is: Why would you get a TC bit response? Is the musl > resolver code triggering some anti-spoofing measure that tries to > validate source addresses over TCP? (I forgot about this aspect of > DNS. Ugh.)
TC bit is for truncation, and means that the complete response would have been larger than 512 bytes and was truncated to whatever number of whole RRs fit in 512 bytes. > > However it's not clear how "fallback to tcp" logic should interact > > with such concurrent requests -- switch to tcp for everything and > > just one nameserver as soon as we get any TC response? > > It's TCP for this query only, not all subsequent queries. It makes > sense to query the name server that provided the TC response: It > reduces latency because that server is more likely to have the large > response in its cache. I'm not talking about future queries but other unfinished queries that are part of the same operation (presently just concurrent A and AAAA lookups). Rich
