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 13697 invoked from network); 3 May 2020 19:46:06 -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:46:06 -0000 Received: (qmail 13980 invoked by uid 550); 3 May 2020 19:46:04 -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 13958 invoked from network); 3 May 2020 19:46:03 -0000 Date: Sun, 3 May 2020 15:45:50 -0400 From: Rich Felker To: Florian Weimer Cc: musl@lists.openwall.com Message-ID: <20200503194550.GZ21576@brightrain.aerifal.cx> References: <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> <87ees0ke2g.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ees0ke2g.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 09:34:31PM +0200, Florian Weimer wrote: > * 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.) No you can't because it's a permanent public interface contract. You may have foreign-libc binaries or static linked binaries from before that policy change or from a party who disagrees (rightly so) with that policy change. > 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. Putting unix domain nameservers in resolv.conf directly would likewise be incompatible with the above. You could do it in some way that they don't see/care about, but then it's a matter of inventing new policy mechanisms which musl explicitly seeks to avoid. (E.g. that's why we used nscd protocol for alternate passwd/group backends rather than NIH'ing something.) Rich