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 9144 invoked from network); 21 Sep 2022 22:20:08 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 21 Sep 2022 22:20:08 -0000 Received: (qmail 10079 invoked by uid 550); 21 Sep 2022 22:20:05 -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 10038 invoked from network); 21 Sep 2022 22:20:04 -0000 Date: Wed, 21 Sep 2022 18:19:49 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20220921221949.GX9709@brightrain.aerifal.cx> References: <20220921160819.GU9709@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220921160819.GU9709@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Other DNS/stub resolver changes On Wed, Sep 21, 2022 at 12:08:19PM -0400, Rich Felker wrote: > 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). At least glibc seems to have no code paths that can produce EAI_FAIL, and empirically, their res_query returns -1/failure when the nameserver gives ServFail (tested with lookup of dnssec-failed.org) rather than making the error packet available to the caller. > 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. As such, I think perhaps I should just leave this alone. Leaving it alone saves 512 bytes of stack, and doesn't really make the work of adding TCP any harder. One remaining motivation for having our own buffer here is that, in the case where the caller of res_send only provides a small buffer (smaller than 512 bytes), we would not be able to determine if a packet equal to the buffer length had been truncated (by the recv function on the client side) without TCP fallback. This is a mess I don't want to get into. However, rather than spending an extra 512 bytes of stack in the __res_msend DNS query core, we can just make "buffer must be >= 512 bytes" part of __res_msend's contract, and res_send can be responsible for using a local buffer of its own if the application's buffer is too small, then copying the result. Rich