From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9224 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: Thu, 28 Jan 2016 19:57:30 -0500 Message-ID: <20160129005730.GQ238@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 1454029077 19769 80.91.229.3 (29 Jan 2016 00:57:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jan 2016 00:57:57 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9237-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jan 29 01:57:49 2016 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 1aOxNk-00008Z-IL for gllmg-musl@m.gmane.org; Fri, 29 Jan 2016 01:57:48 +0100 Original-Received: (qmail 15771 invoked by uid 550); 29 Jan 2016 00:57:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 15750 invoked from network); 29 Jan 2016 00:57:43 -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:9224 Archived-At: On Thu, Oct 22, 2015 at 10:37:53PM -0700, Tim Hockin wrote: > > right? So it should be at the name_from_dns stage in lookup_name.c. > > The simplest implementation approach is probably to wrap name_from_dns > > with a name_from_dns_search function that reads the search domains and > > repeatedly calls name_from_dns until it gets success. > > > > One oddity/ugliness of search that needs to be considered is that > > querying different address families may lead to differently-sourced > > results. For example if you query example.us with ndots=2, a search > > domain of example.com, and the following records present: > > > > example.us.example.com A > > example.us AAAA > > > > then an AF_UNSPEC or AF_INET query yields a v4-only result for > > example.us.example.com while an AF_INET6 query "sees through" to the > > example.us record because the search of example.com fails. This seems > > quite ugly and counter-intuitive, but I don't see any way to do better > > that makes sense. > > If that is how the records are laid out, I think you have to allow it. It turns out this is a non-issue. If a name lacks the requested A or AAAA record, but has some records, then we get rcode==0 rather than rcode==3 (success rather than NxDomain) with 0 results. In that case we can stop the search rather than continuing and there is no inconsistency. Making this work right required a small fix in musl's current rcode handling but it was easy. Rich