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 4001 invoked from network); 3 May 2020 18:18:57 -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; 3 May 2020 18:18:57 -0000 Received: (qmail 7852 invoked by uid 550); 3 May 2020 18:18:55 -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 7834 invoked from network); 3 May 2020 18:18:54 -0000 From: Florian Weimer To: Rich Felker Cc: musl@lists.openwall.com References: <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> <87wo5umk3z.fsf@mid.deneb.enyo.de> <20200502154429.GU21576@brightrain.aerifal.cx> Date: Sun, 03 May 2020 20:18:42 +0200 In-Reply-To: <20200502154429.GU21576@brightrain.aerifal.cx> (Rich Felker's message of "Sat, 2 May 2020 11:44:29 -0400") Message-ID: <87y2q8khkt.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 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. I find the global off switch a bit odd. The implementation doesn't really seem fully worked out to me. >> >> 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. Can't you do DNS with really large packet sizes on localhost? 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 That's the one place where TCP does not make much sense, except to get the last 30 or so bytes in packet size.