Re: [musl] TCP support in the stub resolver

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

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

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

>> The other problem with EDNS is that for sizes on the large end
>> (certainly above the MTU), it depends on fragmentation.  Fragmentation
>> is completely insecure because in DNS packets, all the randomness is
>> in one fragment, so packet spoofing only needs to guess the fragment
>> ID (and the recipient IP stack will provide the UDP port for free).
>> Some of us have been working on eliminating fragmented DNS responses
>> for that reason, which unfortunately reduces the reach of EDNS
>> somewhat.
>
> Well DNS is completely insecure anyway unless you're validating DNSSEC
> locally.

It's not, it works quite well actually in the absence of on-path
attackers.

Even DNSSEC still needs that level of security because a resolver
often has to use unsigned data to figure out where to send the next
query.  If DNS were completely insecure, DNSSEC would still break
because it's prone to denial-of-service attacks on the unsigned
routing data.

> Yes the fragmentation issue makes it a lot easier to blindly
> spoof (as opposed to needing ability to intercept/MITM).

And that difference does matter.

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

>> Some implementations have used a longer sequence of transports: DNS
>> over UDP, EDNS over UDP, and finally TCP.  That avoids EDNS
>> pseudo-negotiation until it is actually needed.  I'm not aware of any
>> stub resolvers doing that, though.
>
> Yeah, each fallback is just going to increase total latency though,
> very badly if they're all remote.
>
> Actually, the current musl approach adapted to this would be to just
> do them all concurrently: DNS/UDP, EDNS/UDP, and DNS/TCP, and accept
> the first answer that's not truncated or broken server
> (servfail/formerr/notimp), basically same as we do now but with more
> choices. But that's getting heavier on unwanted network traffic...

Aggressive parallel queries tend to break middleboxes.  Even A/AAAA is
problematic.  Good interoperability and good performance are difficult
to obtain, particularly from short-lived processes.