From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8729 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Would love to see reconsideration for domain and search Date: Fri, 23 Oct 2015 02:00:05 -0400 Message-ID: <20151023060005.GH8645@brightrain.aerifal.cx> References: <20151022215608.GA8645@brightrain.aerifal.cx> <20151023042720.GE8645@brightrain.aerifal.cx> <20151023053108.GG8645@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1445580026 17628 80.91.229.3 (23 Oct 2015 06:00:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Oct 2015 06:00:26 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8742-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 23 08:00:26 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZpVOm-0001AC-Pu for gllmg-musl@m.gmane.org; Fri, 23 Oct 2015 08:00:20 +0200 Original-Received: (qmail 9720 invoked by uid 550); 23 Oct 2015 06:00:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9700 invoked from network); 23 Oct 2015 06:00:18 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8729 Archived-At: On Thu, Oct 22, 2015 at 10:37:53PM -0700, Tim Hockin wrote: > I saw from a different thread that musl doesn't or didn't do TCP > fallbacks - is that still the case? I know we need that for things > like large multi-SRV sets (which I do not expect libc to support), and > we have some people who have large A sets (which I do expect libc to > support). Indeed. The only way you can overflow the UDP size limit with the records the stub resolver uses is with a max-length CNAME pointing to a max or near-max length record with little or no overlap to allow for compression. Of course you might run out of space for all the address results in other cases, but the truncated packet will still have usable results. While I'm not aware of any official document to this effect, for practical purposes you just have to avoid making names that long. There are too many nameservers that don't do TCP at all, as well as locked-down networks that don't allow TCP except on a few specific ports, to be able to rely on doing DNS over TCP. Naturally other non-stub-resolver things like zone transfers may need TCP, but that's outside the domain of the stub resolver. Note that the libc res_*/dn_*/ns_* APIs should be capable of working with longer messages over TCP as long as you setup the socket and do the send/recv yourself. Rich