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,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 4105 invoked from network); 1 May 2020 22:02:55 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 May 2020 22:02:55 -0000 Received: (qmail 9278 invoked by uid 550); 1 May 2020 22:02:52 -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 9260 invoked from network); 1 May 2020 22:02:51 -0000 Date: Fri, 1 May 2020 18:02:38 -0400 From: Rich Felker To: Florian Weimer Cc: musl@lists.openwall.com Message-ID: <20200501220238.GP21576@brightrain.aerifal.cx> References: <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> <87zhb4px73.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zhb4px73.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] TCP support in the stub resolver 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? > >> > 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. > >> 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). > >> 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. Yes, and currently we do them anyway and just don't care. It's possible that there are users who are just working around this by not configuring IPv6 and only using apps that call gethostbyname (ipv4 only) or use AI_ADDRCONFIG, but the latter was not supported at all in musl until fairly recently, and it only takes effect if you _fully_ disable IPv6 (including on lo and link-local addrs), so I'd think someone would complain if it were a real problem. If sending queries with AD bit set is less of a compatibility issue than parallel queries, I think we can probably just do it unconditionally. And if anyone really _really_ wants to run in an environment with broken nameservers, iptables should be able to reject, redirect, or rewrite packets as needed to get something the broken server can handle... Rich