Re: [musl] TCP support in the stub resolver

[Rich Felker <dalias@libc.org>]

On Sun, May 03, 2020 at 08:18:42PM +0200, Florian Weimer wrote:
> >> >> Why use use-vc at all?  Some software *will* break because it assumes
> >> >> that certain libc calls do not keep open some random file descriptor.
> >> >
> >> > Does use-vc do that (keep the fd open) in glibc? It doesn't seem to be
> >> > documented that way, just as forcing use of tcp, and my intent was not
> >> > to keep any fd open (since you need a separate fd per query anyway to
> >> > do them in parallel or in case the server closes the socket after one
> >> > reply).
> >> 
> >> Sorry, I thought you wanted to keep the connection open to reduce
> >> latency.
> >
> > No, the intent is that users only use this with localhost where the
> > result can be trusted and the latency is trivial and in theory can be
> > optimized out.
> 
> Can't you do DNS with really large packet sizes on localhost?
> 
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
> 
> That's the one place where TCP does not make much sense, except to get
> the last 30 or so bytes in packet size.

No, the protocol simply does not support it. Normal (non-EDNS) DNS
protocol forbids UDP packets over 512 bytes. A nameserver that replied
with them rather than with TC would be non-conforming and would break
conforming clients that expect to see the TC rather than a short read.
With EDNS0 longer packets can be sent but I think there's still a
limit of 4096 bytes or something. I don't understand this entirely so
I may be wrong and it may be possible to just support EDNS0 and say
"run a server with 64k EDNS0 limit on localhost if you want to
guarantee non-truncated replies".

However, this also runs into the issue that you have to mangle the
query (by adding OPT to it) and get back a response that's not going
to look like what the application requested (since it has extra OPT,
etc. in it) unless you do the work to reverse that and reformat the
response to look like what the application would have received if it
were using normal DNS protocol over TCP. So it's probably *more*
unwanted complexity and bug surface to do this right, even if it is
possible...

Rich