From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8776 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: Sun, 25 Oct 2015 15:08:46 -0400 Message-ID: <20151025190846.GB8645@brightrain.aerifal.cx> References: <20151023052625.GD55813@wopr.sciops.net> <20151024220215.GV8645@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 1445800155 11090 80.91.229.3 (25 Oct 2015 19:09:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Oct 2015 19:09:15 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8789-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 25 20:09:04 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 1ZqQf9-0001Mc-Ku for gllmg-musl@m.gmane.org; Sun, 25 Oct 2015 20:09:03 +0100 Original-Received: (qmail 22063 invoked by uid 550); 25 Oct 2015 19:09:01 -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 22031 invoked from network); 25 Oct 2015 19:09:00 -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:8776 Archived-At: On Sun, Oct 25, 2015 at 02:06:29PM +0100, Jan Broer wrote: > > The only place adding search support might negatively impact existing > > musl users is by causing hostnames with no dots to be queried with the > > (often useless and unwanted) default domain set by dhcp before > > failing. My preference would probably be having musl default to > > ndots=0 rather than ndots=1 so that search has to be enabled > > explicitly. Are there any reasons this would be undesirable? > > > I don't think it is a good idea do default to ndots=0. This would > essentially break search for systems where resolv.conf values are managed > by the DHCP server. DHCP expects search to work when there is at least one > entry in the domain-search option returned by the DHCP server. There is no > DHCP option for configuring ndots (see > http://linux.die.net/man/5/dhcp-options) and therefore search would not > work in these configurations when ndots defaults to 0. What I've found is that almost all dhcp setups include a search domain, and dhcp clients set it in resolv.conf, but it's rare that the user actually wants to search this domain. For example do Comcast (random ISP to pick on) customers actually want random bare (no domain) queries like "foo" to be tried as "foo.comcast.com"? Almost surely not. Of course, as noted before, only bare queries are affected if ndots=1, so the only behavioral change is that some such queries may unexpectedly succeed (if they exist in the search domain) or take longer to fail (since two or more queries have to fail). > Also, i don't think your argument for setting ndots to 0 by default is > valid: > > Search always to be enabled explicitly even when the default for ndots=1: > There is no search unless the user explicitely writes search paths in his > resolv.conf or configures his DHCP client to get the domain-search option > via DHCP. > > So the resolvers search functionality is already something the user has to > enable explicitely. My experience is that dhcp clients do this by default. Of course there's a good argument to be made that fixing this should be done at the dhcp client level (or resolv.conf updating system level) rather than having libc try to 'fix' it. There's certainly value to having consistent behavior between programs using different libcs on the same system, so perhaps sticking with ndots=1 is better. Rich