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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26808 invoked from network); 4 Jul 2023 03:29:33 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 Jul 2023 03:29:33 -0000 Received: (qmail 26616 invoked by uid 550); 4 Jul 2023 03:29:30 -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 26584 invoked from network); 4 Jul 2023 03:29:29 -0000 Date: Mon, 3 Jul 2023 23:29:19 -0400 From: Rich Felker To: Hamish Forbes Cc: musl@lists.openwall.com Message-ID: <20230704032918.GB4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] DNS answer buffer is too small Thanks for sending an email where we can document this. On Tue, Jul 04, 2023 at 12:17:05PM +1200, Hamish Forbes wrote: > In lookup_name.c the DNS answer buffer (ABUF_SIZE) is currently > hardcoded to 768 bytes, increased from 512 after TCP DNS was > implemented. > > The DNS RFC is, unfortunately, not very explicit about the size of TCP > responses. > However it does have this little line: > > > RFC 1035 4.2.2. > > The message is prefixed with a two byte length field which gives the message length, excluding the two byte length field. > > Which you could interpret as the TCP response length is a 16bit > unsigned int, so 64K. > But that's also the raw (potentially compressed) DNS response, the > uncompressed response could be larger still. "Compression" is not relevant; there is no "decompressed state" the message is converted into. Everything is processed in the original DNS protocol form, with "compression" (backpointers). > As best I can tell (I am not a C programmer!) glibc is using a scratch > buffer which grows when the parsing function returns an ERANGE error. > > If that's more complex than you want, maybe a good compromise would be > allocating 768 (or 512?) for UDP queries and expanding to 64k when a > query falls back to TCP? Your report here is missing the motivation for why you might care to have more than 768 bytes of response, which, as I understand it, is because of CNAME chains. Otherwise, the buffer size is chosen to hold the number of answer records the stub resolver is willing to accept, and there is no problem. Long CNAME chains are rather hostile and are not guaranteed to be well supported -- AIUI recursive nameservers already impose their own limits on the number of redirections in a chain, though I cannot find any specification in the RFCs for this behavior or suggesting a value for that limit, so if you can dig up what they actually do, this would be useful to know. But it seems there are chains longer than what we currently support out in the wild, which most software does support. So the next step is nailing down exactly what the "requirement" here is, so we can figure out what's the most reasonable and least costly way to do it. If there's some moderately small limit on the number of redirections that recursive software supports, it may make sense to just increase the buffer size to match that. If there really can be very large chains, this is a mess. Rich