From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 29862 invoked from network); 21 Apr 2020 17:26:23 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 21 Apr 2020 17:26:23 -0000 Received: (qmail 20288 invoked by uid 550); 21 Apr 2020 17:26:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 20264 invoked from network); 21 Apr 2020 17:26:20 -0000 From: Florian Weimer To: Rich Felker Cc: musl@lists.openwall.com References: <20200417034059.GF11469@brightrain.aerifal.cx> <878siucvqd.fsf@mid.deneb.enyo.de> <20200417160726.GG11469@brightrain.aerifal.cx> <87o8ro67in.fsf_-_@mid.deneb.enyo.de> <20200419000347.GU11469@brightrain.aerifal.cx> <871roj51x3.fsf@mid.deneb.enyo.de> <20200420012441.GW11469@brightrain.aerifal.cx> <87a736y8nu.fsf@mid.deneb.enyo.de> <20200420173920.GD11469@brightrain.aerifal.cx> <87mu75uq3p.fsf@mid.deneb.enyo.de> <20200421150241.GL11469@brightrain.aerifal.cx> Date: Tue, 21 Apr 2020 19:26:08 +0200 In-Reply-To: <20200421150241.GL11469@brightrain.aerifal.cx> (Rich Felker's message of "Tue, 21 Apr 2020 11:02:41 -0400") Message-ID: <87zhb4px73.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [musl] TCP support in the stub resolver * 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.