From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18218 invoked from network); 10 Oct 2022 15:07:53 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 10 Oct 2022 15:07:53 -0000 Received: (qmail 30108 invoked by uid 550); 10 Oct 2022 15:07:46 -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 30085 invoked from network); 10 Oct 2022 15:07:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665414458; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/FvfUwM8Ai6/XWPDBoWwsLBNMIkZpoQCfImSjPho7qQ=; b=PI5FOJ1UNU556eskn0UdFVmw8di7rpeI4WfZthYyR3fn38t2V+wPQ2c5jEaN7u8uOenS0h CoGJeqrEGb08SmG5ZEnIwgE7JtJkF/m0/A6rZP0nYAGLaXzqlosADlxcIZOP/brbIsTBPi 3Lr+SrevYJSBnS7l6wF0PxhpwZ7Dj3g= X-MC-Unique: SC_QRANtPnSMitLsrWUBFQ-1 From: Florian Weimer To: Rich Felker Cc: musl@lists.openwall.com References: <20220916041435.GL9709@brightrain.aerifal.cx> <87wn9yo00j.fsf@oldenburg.str.redhat.com> <20220920125317.GN9709@brightrain.aerifal.cx> Date: Mon, 10 Oct 2022 17:07:34 +0200 In-Reply-To: <20220920125317.GN9709@brightrain.aerifal.cx> (Rich Felker's message of "Tue, 20 Sep 2022 08:53:18 -0400") Message-ID: <87wn97yax5.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Subject: Re: [musl] TCP fallback open questions * Rich Felker: >> TCP DNS has pipelining. > > Has that always been a thing? If so, it might advise a different way > to do this. Like most things DNS, it's controversial. There's certainly the glibc precendent. I found this: | 6.2.1.1. Query Pipelining | | Due to the historical use of TCP primarily for zone transfer and | truncated responses, no existing RFC discusses the idea of pipelining | DNS queries over a TCP connection. | | In order to achieve performance on par with UDP, DNS clients SHOULD | pipeline their queries. When a DNS client sends multiple queries to | a server, it SHOULD NOT wait for an outstanding reply before sending | the next query. Clients SHOULD treat TCP and UDP equivalently when | considering the time at which to send a particular query. | | It is likely that DNS servers need to process pipelined queries | concurrently and also send out-of-order responses over TCP in order | to provide the level of performance possible with UDP transport. If | TCP performance is of importance, clients might find it useful to use | server processing times as input to server and transport selection | algorithms. | | DNS servers (especially recursive) MUST expect to receive pipelined | queries. The server SHOULD process TCP queries concurrently, just as | it would for UDP. The server SHOULD answer all pipelined queries, | even if they are received in quick succession. The handling of | responses to pipelined queries is covered in Section 7. But I'm too out-of-touch to tell whether this is good advice (for client behavior). >> The glibc stub resolver exercises that, sending >> the A and AAAA queries back-to-back over TCP, probably in the same >> segment. I think it should even deal with reordered responses (so no >> head-of-line blocking), but I'm not sure if recursive resolver code >> actually exercises it by reorder replies. > > Do real-world servers reliably do out-of-order responding, starting > multiple queries received over the same connection in parallel and > responding to them in the order answers become available? There's a security requirement to collapse multiple outgoing queries for the same QNAME/QCLASS/QTYPE, so strict sequential processing without updating global state isn't really possible. It's a small step from sending out the responses in parallel. Section 7 in RFC 7766 recommends this as well. >> Historically, it's unfriendly to keep TCP connections to recursive >> resolvers open for extended periods of time. Furthermore, it >> complicates the retry logic in the client because once you keep >> connections open, RST in response to a send does not indicate an error >> (the server may just have dropped the question), so you need to retry in >> that case with a fresh connection. > > We definitely wouldn't keep them open for an extended period since the > expectation is that they won't normally be used, and since tying up > fds is bad. But if there's nasty corner case handling for when the > server decides it doesn't want to answer more questions on your > existing socket (possibly even within a single run) the prospect of > using a single connection for multiple queries becomes less appealing. It's about reviving a connection that's been dormant for a while, not the case of back-to-back or parallel queries for A/AAAA. TCP treats uncoordinated connection close like a network error, and DNS doesn't have a coordination protocol. The DNS resolver eventually needs to shut down connections from clients that are inactive, which requires an uncoordinated close. On the client side, the BSD sockets API isn't really good at telling this from a bona-fide networking problem even if it has additional data. Thanks, Florian