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 12329 invoked from network); 3 May 2020 19:34:49 -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:34:49 -0000 Received: (qmail 9597 invoked by uid 550); 3 May 2020 19:34:43 -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 9579 invoked from network); 3 May 2020 19:34:43 -0000 From: Florian Weimer To: Rich Felker Cc: musl@lists.openwall.com 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> <20200503190941.GY21576@brightrain.aerifal.cx> Date: Sun, 03 May 2020 21:34:31 +0200 In-Reply-To: <20200503190941.GY21576@brightrain.aerifal.cx> (Rich Felker's message of "Sun, 3 May 2020 15:09:41 -0400") Message-ID: <87ees0ke2g.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [musl] TCP support in the stub resolver * Rich Felker: >> 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". On localhost, one could just disregard the protocol limit, perhaps with special configuration of the recursive resolver. (The stub resolver would not need configuration, it just has to accept the packets if they arrive.) The other option would be to use a UNIX Domain datagram socket instead of UDP. Since it is a new transport protocol, it's possible to make up different rules about packet sizes. (Even on localhost, TCP has some denial-of-service issues not shared by datagram transports, so there might be some other benefit of avoid TCP, not just reduction in implementation complexity.) > 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... True, if query mangling is required *and* TCP fallback is needed in some cases, there is little incentive to do this from a complexity point of view.