Re: [musl] TCP support in the stub resolver

[Rich Felker <dalias@libc.org>]

On Sat, May 02, 2020 at 05:28:48PM +0200, Florian Weimer wrote:
> * 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.

According to this it does:

https://wiki.archlinux.org/index.php/Systemd-resolved#DNSSEC

However it's subject to downgrade attacks unless you edit a config
file. Note that the example shows:

    ....
    -- Data is authenticated: yes

so it looks like it's setting the AD bit like it should.

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

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.

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

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. (Kernel can in theory do the whole handshake with itself
during the connect syscall or just high-level emulate it if you didn't
care about seeing it on "tcpdump -i lo". Not sure if it does this but
I wouldn't be surprised.)

Rich