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 11497 invoked from network); 21 Apr 2020 09:48:25 -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; 21 Apr 2020 09:48:25 -0000 Received: (qmail 9559 invoked by uid 550); 21 Apr 2020 09:48:23 -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 9538 invoked from network); 21 Apr 2020 09:48:23 -0000 From: Florian Weimer To: Rich Felker Cc: musl@lists.openwall.com References: <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> <20200420012441.GW11469@brightrain.aerifal.cx> <87a736y8nu.fsf@mid.deneb.enyo.de> <20200420173920.GD11469@brightrain.aerifal.cx> Date: Tue, 21 Apr 2020 11:48:10 +0200 In-Reply-To: <20200420173920.GD11469@brightrain.aerifal.cx> (Rich Felker's message of "Mon, 20 Apr 2020 13:39:20 -0400") Message-ID: <87mu75uq3p.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [musl] TCP support in the stub resolver * Rich Felker: > On Mon, Apr 20, 2020 at 08:26:45AM +0200, Florian Weimer wrote: >> * Rich Felker: >> >> > 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. >> >> Sure, but you have to put this into context. In this situation, you >> already need three roundtrips (UDP query, TCP handshake, TCP query). >> The other TCP handshake increases the packet count quite noticeably. > > Yes but they happen concurrently. Of course it's possible that you > have bandwidth so low that latency is affected by throughput, but I > think the far more common case nowadays is moderately fast connection > (3G cellular, possibly rate-limited, or DSL) but saturated with other > much-higher-volume traffic causing the latency. I'm not sure. It should be possible to measure this. Generally, once you have to use TCP, performance will not be good in any case, especially if the recursive resolver is not local. I'm excited that Fedora plans to add a local caching resolver by default. It will help with a lot of these issues. > BTW, am I mistaken or can TCP fastopen make it so you can get a DNS > reply with no additional round-trips? (query in the payload with > fastopen, response sent immediately after SYN-ACK before receiving ACK > from client, and nobody has to wait for connection to be closed) Of > course there are problems with fastopen that lead to it often being > disabled so it's not a full substitute for UDP. There's no handshake to enable it, so it would have to be an /etc/resolv.conf setting. It's also not clear how you would perform auto-detection that works across arbitrary middleboxen. I don't think it's useful for an in-process stub resolver. > Do you think EDNS support eliminates the need for TCP? There is a window of package sizes where it avoids TCP and works (from 512 to something between 1200 and 1500 bytes) *if* the recursive resolver does EDNS at all. For decent compatibility, you would have to have heuristics in the stub resolver to figure out if FORMERR/NOTIMP and missing responses are due to lack of EDNS support. The other problem with EDNS is that for sizes on the large end (certainly above the MTU), it depends on fragmentation. Fragmentation is completely insecure because in DNS packets, all the randomness is in one fragment, so packet spoofing only needs to guess the fragment ID (and the recipient IP stack will provide the UDP port for free). Some of us have been working on eliminating fragmented DNS responses for that reason, which unfortunately reduces the reach of EDNS somewhat. Above 4096 bytes, pretty much all recursive resolvers will send TC responses even if the client offers a larger buffer size. This means for correctness, you cannot do away with TCP support. Some implementations have used a longer sequence of transports: DNS over UDP, EDNS over UDP, and finally TCP. That avoids EDNS pseudo-negotiation until it is actually needed. I'm not aware of any stub resolvers doing that, though. (Things change if you connect to a local stub resolver, of course.)