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 27799 invoked from network); 19 Apr 2020 08:13:12 -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; 19 Apr 2020 08:13:12 -0000 Received: (qmail 16234 invoked by uid 550); 19 Apr 2020 08:13:09 -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 16216 invoked from network); 19 Apr 2020 08:13:09 -0000 From: Florian Weimer To: Rich Felker Cc: musl@lists.openwall.com References: <20200413193505.GY11469@brightrain.aerifal.cx> <20200413214138.GG41308@straasha.imrryr.org> <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> Date: Sun, 19 Apr 2020 10:12:56 +0200 In-Reply-To: <20200419000347.GU11469@brightrain.aerifal.cx> (Rich Felker's message of "Sat, 18 Apr 2020 20:03:47 -0400") Message-ID: <871roj51x3.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [musl] TCP support in the stub resolver * 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? >> 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.