Re: [musl] TCP support in the stub resolver

[Rich Felker <dalias@libc.org>]

On Sun, Apr 19, 2020 at 10:12:56AM +0200, Florian Weimer wrote:
> * Rich Felker:
> 
> >> No, you can reuse the connection for the second query (in most cases).
> >> However, for maximum robustness, you should not send the second query
> >> until the first response has arrived (no pipelining).  You may still
> >> need a new connection for the second query if the TCP stream ends
> >> without a response, though.
> >
> > That's why you need one per request -- so you can make them
> > concurrently (can't assume pipelining).
> 
> Since the other query has likely already been cached in the recursive
> resolver due to the UDP query (which is already in progress), the
> second TCP query only saves one round-trip, I think.  Is that really
> worth it?

If the nameserver is not local, absolutely. A round trip can be over
500 ms.

> >> Then it might be possible that no one will notice the missing TCP
> >> fallback.
> >
> > Really almost no one has noticed it so far, and the places where it
> > was noticed were buggy (IIRC Google or Cloudflare) nameservers that
> > were sending an empty response on truncation rather than a properly
> > truncated response, which seems to have since been fixed. (And in this
> > case the fallback would have been a major performance hit, so it was
> > nice that it was caught and fixed instead).
> 
> SPF lookups for various domains return other TXT records, which push
> the size of the response over the limit.  There is no way to fix this
> on the recursive resolver side because the TXT RRset is itself larger
> than 512 bytes.
> 
> TXT RRsets for DKIM can also approach, but i have not seen them cross
> it.
> 
> This is just one application, receiving mail with some form of
> authentcation, that requires TCP fallback.  I'm sure there other
> applications.

Yes. I don't claim there aren't potential cases where it's wanted,
just that it hasn't come up aside from the buggy NS with empty TC
response.

Anything related to mail is a case where you really really should be
running a local DNSSEC-validating nameserver, which adds to the appeal
of just doing TCP to begin with (activated by use-vc) or not at all.
But I think before making any decisions I should get started on the
prereq work to make it even possible. The core is currently built
around having an array of up to 2 (for A and AAAA at same time) [512]
arrays the response packets go into. That's changeable without too
much work but requires some care since this is attack surface code.

Rich