Re: [musl] TCP support in the stub resolver

[Florian Weimer <fw@deneb.enyo.de>]

* Rich Felker:

> I'm not sure what you're saying. Fastopen is only tried initially if
> the kernel previously got a TCP header from the remote host indicating
> support for it (and providing a cookie -- the kernel should have an
> option to only accept zero-length cookies since anything else is a
> tracking-vector/privacy-risk, but I'm not aware of such an option). If
> not available for the particular host, or not at all (due to the above
> global-disable heuristic or configuration), AIUI it just initially
> does normal TCP and puts the payload in the send buffer.

I find the global off switch a bit odd.  The implementation doesn't
really seem fully worked out to me.

>> >> 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.