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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26955 invoked from network); 21 Sep 2022 16:08:35 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 21 Sep 2022 16:08:35 -0000 Received: (qmail 22011 invoked by uid 550); 21 Sep 2022 16:08:32 -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 21975 invoked from network); 21 Sep 2022 16:08:31 -0000 Date: Wed, 21 Sep 2022 12:08:19 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20220921160819.GU9709@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [musl] Other DNS/stub resolver changes In the process of working out TCP fallback support, some other potential/likely changes to the DNS/stub resolver behavior are emerging, which I'd like to document here and open for feedback. The EAI_NODATA is already covered in an existing thread. One weird thing I noticed is that, while lookup_name.c's name_from_dns is processing error RCODE values, it actually never sees them because __res_msend just treats errors as non-answers. This probably doesn't matter, but it does prevent us from ever issuing EAI_FAIL. And from the standpoint of the res_* API (res_query/res_send) the caller may be expecting to see specific errors and to be able to act on them (todo: check what other implementations do here). The reason __res_msend doesn't return errors packets is a consequence of implementation details, specifically, that it considers erroring slots unanswered, and reuses the buffer for them as temp space to receive answers that might turn out to be for another query, which clobbers them. This is rather ugly, and I think I'd like to give __res_msend its own 512-byte receive buffer to receive into. This would give us the choice to keep error results or not, as we see fit, rather than tying us to the current behavior. I almost said this would also avoid tying the receive logic to a choice to use one socket per TCP query vs doing multiple queries over the same TCP socket, since all reads could just take place into this buffer. However, that ignores pathological partial reads, whereby we might have to wait after receiving the first 1-3 bytes to get the 4th byte and know which query the answer belongs to. So if we want to do that, we need a 3-byte buffer for each tcp socket where we might have received data but not yet know which query it goes with. However we can still recv into the 512-byte receive buffer, and then only move to a 3-byte pending buffer if it's <=3 bytes, and otherwise move to the appropriate answer buffer.