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 22977 invoked from network); 2 May 2020 15:29:04 -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; 2 May 2020 15:29:04 -0000 Received: (qmail 20082 invoked by uid 550); 2 May 2020 15:29:01 -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 20064 invoked from network); 2 May 2020 15:29:01 -0000 From: Florian Weimer To: Rich Felker Cc: musl@lists.openwall.com 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> <20200501220238.GP21576@brightrain.aerifal.cx> Date: Sat, 02 May 2020 17:28:48 +0200 In-Reply-To: <20200501220238.GP21576@brightrain.aerifal.cx> (Rich Felker's message of "Fri, 1 May 2020 18:02:38 -0400") Message-ID: <87wo5umk3z.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [musl] TCP support in the stub resolver * 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.