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 17614 invoked from network); 20 Apr 2020 01:24:56 -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 UTF8ESMTPZ; 20 Apr 2020 01:24:56 -0000 Received: (qmail 32354 invoked by uid 550); 20 Apr 2020 01:24:54 -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 32336 invoked from network); 20 Apr 2020 01:24:54 -0000 Date: Sun, 19 Apr 2020 21:24:41 -0400 From: Rich Felker To: Florian Weimer Cc: musl@lists.openwall.com Message-ID: <20200420012441.GW11469@brightrain.aerifal.cx> References: <20200414035303.GZ11469@brightrain.aerifal.cx> <87v9m0hdjk.fsf@mid.deneb.enyo.de> <20200415180149.GH11469@brightrain.aerifal.cx> <87imi0haf7.fsf@mid.deneb.enyo.de> <20200417034059.GF11469@brightrain.aerifal.cx> <878siucvqd.fsf@mid.deneb.enyo.de> <20200417160726.GG11469@brightrain.aerifal.cx> <87o8ro67in.fsf_-_@mid.deneb.enyo.de> <20200419000347.GU11469@brightrain.aerifal.cx> <871roj51x3.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871roj51x3.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, Apr 19, 2020 at 10:12:56AM +0200, Florian Weimer wrote: > * Rich Felker: > > >> No, you can reuse the connection for the second query (in most cases). > >> However, for maximum robustness, you should not send the second query > >> until the first response has arrived (no pipelining). You may still > >> need a new connection for the second query if the TCP stream ends > >> without a response, though. > > > > That's why you need one per request -- so you can make them > > concurrently (can't assume pipelining). > > Since the other query has likely already been cached in the recursive > resolver due to the UDP query (which is already in progress), the > second TCP query only saves one round-trip, I think. Is that really > worth it? If the nameserver is not local, absolutely. A round trip can be over 500 ms. > >> Then it might be possible that no one will notice the missing TCP > >> fallback. > > > > Really almost no one has noticed it so far, and the places where it > > was noticed were buggy (IIRC Google or Cloudflare) nameservers that > > were sending an empty response on truncation rather than a properly > > truncated response, which seems to have since been fixed. (And in this > > case the fallback would have been a major performance hit, so it was > > nice that it was caught and fixed instead). > > SPF lookups for various domains return other TXT records, which push > the size of the response over the limit. There is no way to fix this > on the recursive resolver side because the TXT RRset is itself larger > than 512 bytes. > > TXT RRsets for DKIM can also approach, but i have not seen them cross > it. > > This is just one application, receiving mail with some form of > authentcation, that requires TCP fallback. I'm sure there other > applications. Yes. I don't claim there aren't potential cases where it's wanted, just that it hasn't come up aside from the buggy NS with empty TC response. Anything related to mail is a case where you really really should be running a local DNSSEC-validating nameserver, which adds to the appeal of just doing TCP to begin with (activated by use-vc) or not at all. But I think before making any decisions I should get started on the prereq work to make it even possible. The core is currently built around having an array of up to 2 (for A and AAAA at same time) [512] arrays the response packets go into. That's changeable without too much work but requires some care since this is attack surface code. Rich