From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8786 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: Mon, 26 Oct 2015 20:30:21 -0400 Message-ID: <20151027003021.GN8645@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 1445905837 23163 80.91.229.3 (27 Oct 2015 00:30:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Oct 2015 00:30:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8799-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 27 01:30:36 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 1Zqs9s-0003x2-FV for gllmg-musl@m.gmane.org; Tue, 27 Oct 2015 01:30:36 +0100 Original-Received: (qmail 18408 invoked by uid 550); 27 Oct 2015 00:30:34 -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 18386 invoked from network); 27 Oct 2015 00:30:33 -0000 Content-Disposition: inline In-Reply-To: <20151023053108.GG8645@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8786 Archived-At: On Fri, Oct 23, 2015 at 01:31:09AM -0400, Rich Felker wrote: > > > BTW I think there are other strong reasons to move to a model based on > > > a local nameserver that does the unioning, not just performance. The > > > most compelling is DNSSEC, which requires a trusted channel between > > > the nameserver and the stub resolver in order for results to be > > > meaningful/trusted. In the future everybody should be running a > > > nameserver on localhost to do DNSSEC signature validation. In that > > > scheme, resolv.conf would just contain 127.0.0.1 (or could be omitted > > > entirely since that's the default, at least on musl). > > > > I can see a local nameserver doing resolution, but doing search > > expansion seems like a stretch (and superfluous since it is local). > > Search would also get a lot of performance benefit from doing in the > caching nameserver, but I agree with your assessment that it's a > separate issue and that there's no _need_ to do it at that level to > ensure correctness. So for now let's focus on a plan for adding > suitable search domain support in musl. > > I believe search only affects DNS queries, not hosts file lookups, > 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. I noticed in the process of trying to draft code to do this that there will be a lot of code duplication with the resolv.conf parsing in res_msend.c, and that this code has some stupid bugs (for example it stops parsing after it gets 3 nameservers, so it might miss options later in the file), so I think I'll take a look at factoring it into a new function to gather all the interesting information from resolv.conf that can be used in both places. A couple additional things I noticed from resolv.conf(5): 1. The default domain used by glibc is not the dns root but rather the domain portion of the local hostname determined by gethostname(). Is there any value in duplicating this? Does anyone want/need it? 2. It's not clear from the documentation of "search" whether its presence overrides/suppresses the "domain" (default or set by resolv.conf) or adds additional searches before or after it. Which should it do? While glibc/legacy behavior is worth looking at, I don't think we need to look at things from a standpoint of exactly duplicating that. Meeting real-world modern application needs while avoiding inconveniencing users with stupid/unwanted behavior should be the primary goal. Rich