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 9559 invoked from network); 3 May 2020 19:09:59 -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 19:09:59 -0000 Received: (qmail 32657 invoked by uid 550); 3 May 2020 19:09:57 -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 32634 invoked from network); 3 May 2020 19:09:56 -0000 Date: Sun, 3 May 2020 15:09:41 -0400 From: Rich Felker To: Florian Weimer Cc: musl@lists.openwall.com Message-ID: <20200503190941.GY21576@brightrain.aerifal.cx> References: <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> <87y2q8khkt.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y2q8khkt.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] TCP support in the stub resolver On Sun, May 03, 2020 at 08:18:42PM +0200, Florian Weimer wrote: > >> >> 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. No, the protocol simply does not support it. Normal (non-EDNS) DNS protocol forbids UDP packets over 512 bytes. A nameserver that replied with them rather than with TC would be non-conforming and would break conforming clients that expect to see the TC rather than a short read. With EDNS0 longer packets can be sent but I think there's still a limit of 4096 bytes or something. I don't understand this entirely so I may be wrong and it may be possible to just support EDNS0 and say "run a server with 64k EDNS0 limit on localhost if you want to guarantee non-truncated replies". However, this also runs into the issue that you have to mangle the query (by adding OPT to it) and get back a response that's not going to look like what the application requested (since it has extra OPT, etc. in it) unless you do the work to reverse that and reformat the response to look like what the application would have received if it were using normal DNS protocol over TCP. So it's probably *more* unwanted complexity and bug surface to do this right, even if it is possible... Rich