Re: [musl] TCP support in the stub resolver

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

* Rich Felker:

> On Tue, Apr 21, 2020 at 07:26:08PM +0200, Florian Weimer wrote:
>> * Rich Felker:
>> 
>> >> I'm excited that Fedora plans to add a local caching resolver by
>> >> default.  It will help with a lot of these issues.
>> >
>> > That's great news! Will it be DNSSEC-enforcing by default?
>> 
>> No.  It is currently not even DNSSEC-aware, in the sense that you
>> can't get any DNSSEC data from it.  That's the sad part.
>
> That's really disappointing. Why? Both systemd-resolved and dnsmasq,
> the two reasonable (well, reasonable for distros using systemd already
> in the systemd-resolved case :) options for this, support DNSSEC fully
> as I understand it. Is it just being turned off by default because of
> risk of breaking things, or is some other implementation that lacks
> DNSSEC being used?

It's systemd-resolved.  As far as I can tell, it does not provide
DNSSEC data on the DNS client interface.

>> >> > BTW, am I mistaken or can TCP fastopen make it so you can get a DNS
>> >> > reply with no additional round-trips? (query in the payload with
>> >> > fastopen, response sent immediately after SYN-ACK before receiving ACK
>> >> > from client, and nobody has to wait for connection to be closed) Of
>> >> > course there are problems with fastopen that lead to it often being
>> >> > disabled so it's not a full substitute for UDP.
>> >> 
>> >> There's no handshake to enable it, so it would have to be an
>> >> /etc/resolv.conf setting.  It's also not clear how you would perform
>> >> auto-detection that works across arbitrary middleboxen.  I don't think
>> >> it's useful for an in-process stub resolver.
>> >
>> > The kernel automatically does it,
>> 
>> Surely not, it causes too many interoperability issues for that.  It's
>> also difficult to fit it into the BSD sockets API.  As far as I can
>> see, you have to use sendmsg or sendto with MSG_FASTOPEN instead of a
>> connect call to establish the connection.
>> 
>> (When the kernel says that it's enabled by default, it means that you
>> can use MSG_FASTOPEN with sysctl tweaks.)
>
> What I mean is that, if you use MSG_FASTOPEN on a kernel new enough to
> understand it, I think it makes a normal TCP connection and sends the
> data if fastopen is not enabled or not supported by the remote host,
> but uses fastopen as long as it's enabled and supported. In this sense
> it's automatic. But of course we'd have to fallback explicitly anyway
> if it's not supported in order to maintain compatibility with older
> kernels.

I found this in the kernel sources.  It's a bit worrying.

/*
 * The following code block is to deal with middle box issues with TFO:
 * Middlebox firewall issues can potentially cause server's data being
 * blackholed after a successful 3WHS using TFO.
 * The proposed solution is to disable active TFO globally under the
 * following circumstances:
 *   1. client side TFO socket receives out of order FIN
 *   2. client side TFO socket receives out of order RST
 *   3. client side TFO socket has timed out three times consecutively during
 *      or after handshake
 * We disable active side TFO globally for 1hr at first. Then if it
 * happens again, we disable it for 2h, then 4h, 8h, ...
 * And we reset the timeout back to 1hr when we see a successful active
 * TFO connection with data exchanges.
 */

It's possible that the retransmit with TCP Fast Open happens as part
of the regular TCP state machine.  I can't find an explicit fallback
handler.

>> >> Above 4096 bytes, pretty much all recursive resolvers will send TC
>> >> responses even if the client offers a larger buffer size.  This means
>> >> for correctness, you cannot do away with TCP support.
>> >
>> > In that case doing EDNS at all seems a lot less useful. Fragmentation
>> > is always a possibility above min MTU (essentially same limit as
>> > original UDP DNS) and the large responses are almost surely things you
>> > do want to avoid forgery on, which leads me back around to thinking
>> > that if you want them you really really need to be running a local
>> > DNSSEC validating nameserver and then can just use-vc...
>> 
>> 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.