From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8772 Path: news.gmane.org!not-for-mail From: Jan Broer Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Would love to see reconsideration for domain and search Date: Sun, 25 Oct 2015 14:06:29 +0100 Message-ID: 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: multipart/alternative; boundary=001a114032704f97750522ed8305 X-Trace: ger.gmane.org 1445778414 18506 80.91.229.3 (25 Oct 2015 13:06:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Oct 2015 13:06:54 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8785-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 25 14:06:48 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 1ZqL0W-0005gq-Nq for gllmg-musl@m.gmane.org; Sun, 25 Oct 2015 14:06:44 +0100 Original-Received: (qmail 1620 invoked by uid 550); 25 Oct 2015 13:06:42 -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 1600 invoked from network); 25 Oct 2015 13:06:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Y1Bds7i8TixPg2auAmxldgReXwhZcszCs6veMMcwOnk=; b=tpvuYVAMV8BEKWUTTbWt2SQclpm+Oayyol1JDAPzZLaflKEXgMbcAu3RtX3KS9RS4g Ll2usBXAj5UorB6jYFt50UGhMX+uzNZGEMwwL9B9UdTmzwI/VgWyxz1+ZfejEpOVxUzr Xz/y3w6bVE875qpBUTuCGwiXTwk+XFqvEwDTUJX1dpQDlF6//48sLYO7LdV2SIMVeFLw eZwBaPfWYUQUYV89OLixznu6M3g1qPAHnZCoTLWXrdivrynpJXrsfFtVEXiSL5wCVTu6 XqlqxbehirUS9cHUTaA6cXJgu1ZrzEmQ/PtVPSB1APL8ftCpx9YV5O/jFGC3FT9bWyQj O0tw== X-Received: by 10.107.34.149 with SMTP id i143mr34679228ioi.195.1445778389176; Sun, 25 Oct 2015 06:06:29 -0700 (PDT) In-Reply-To: <20151024220215.GV8645@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:8772 Archived-At: --001a114032704f97750522ed8305 Content-Type: text/plain; charset=UTF-8 > 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. 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. On Sun, Oct 25, 2015 at 12:02 AM, Rich Felker wrote: > On Sat, Oct 24, 2015 at 02:33:31PM -0700, Tim Hockin wrote: > > On Oct 24, 2015 12:20 PM, "Kurt H Maier" wrote: > > > > > > On Thu, Oct 22, 2015 at 02:24:11PM -0700, Tim Hockin wrote: > > > > > > > > I understand your point, though the world at large tends to disagree. > > > > > > The world at large uses bad software. Please don't use this sort of > > > reasoning as a justification for and embrace-extend operation on actual > > > standards. > > > > Where is the standard that defines ordering semantics in resolv.conf? > > I don't think it's useful to argue about intent unless someone wants > to dig up history and find out what the original implementors > intended, and even then it's rather arbitrary whether people would > care about that intent since it doesn't seem to have been documented > explicitly. My view is that it's more useful to consider the > consequences of both interpretations and draw a conclusion that one > should be preferred from the bad consequences of the other. > > > > > The real world is not ideal. Not all nameservers are identically > > > > scoped - you MUST respect the ordering in resolv.conf - to do > > > > otherwise is semantically broken. If implementation simplicity means > > > > literally doing queries in serial, then that is what you should do. > > > > > > You absolutely cannot respect the ordering in resolv.conf; at least not > > > if you're relying on someone else's resolver. If the orchestration > > > software depends on specific results being returned in particular > > > orders, the orchestration software should provide a mechanism to > > > generate them. > > > > > > > Similarly, you can't just search all search domains in parallel and > > > > take the first response. The ordering is meaningful. > > > > > > It should not be, and more to the point will not reliably be, > > > meaningful. > > > > Search has to be ordered. You can not possibly argue otherwise? > > Indeed, search certainly has to be ordered. Otherwise results are most > definitely non-deterministic. The trivial example would be looking up > "www" with 2 or more search domains. > > In any case, it was discussed way back that, while parallel search > could be implemented as long as a result from search domain N is not > accepted until negative results from domains 1 to N-1 are received, > the implementation complexity cost was too high relative to the value > of such a feature. > > > > You are arguing for introducing performance penalties into musl that do > > > not affect you but do very much affect lots of other users. I hope > they > > > do not happen -- musl is not the right place to fix your problem. > > > > I am arguing for adding a very standard feature (search) to open musl to > a > > whole new space of users. Nobody is forcing you to use search paths or > > ndots. > > 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? > > Rich > --001a114032704f97750522ed8305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> The only place adding search support might negat= ively 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=3D0 rather than ndots=3D1 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=3D0. T= his 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 l= east one entry in the domain-search option returned by the DHCP server. The= re is no DHCP option for configuring ndots (see http://linux.die.net/man/5/dhcp-options) and t= herefore search would not work in these configurations when ndots defaults = to 0.

Also, i don't think your argument for setting n= dots to 0 by default is valid:

Search always = to be enabled explicitly even when the default for ndots=3D1:
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 v= ia DHCP.
So the resolvers search functionality is already som= ething the user has to enable explicitely.


On Sun, Oct 25, 2015 at 12:02 = AM, Rich Felker <dalias@libc.org> wrote:
On Sat, Oct 24, 2015 at 0= 2:33:31PM -0700, Tim Hockin wrote:
> On Oct 24, 2015 12:20 PM, "Kurt H Maier" <khm@sdf.org> wrote:
> >
> > On Thu, Oct 22, 2015 at 02:24:11PM -0700, Tim Hockin wrote:
> > >
> > > I understand your point, though the world at large tends to = disagree.
> >
> > The world at large uses bad software.=C2=A0 Please don't use = this sort of
> > reasoning as a justification for and embrace-extend operation on = actual
> > standards.
>
> Where is the standard that defines ordering semantics in resolv.conf?<= br>
I don't think it's useful to argue about intent unless someo= ne wants
to dig up history and find out what the original implementors
intended, and even then it's rather arbitrary whether people would
care about that intent since it doesn't seem to have been documented explicitly. My view is that it's more useful to consider the
consequences of both interpretations and draw a conclusion that one
should be preferred from the bad consequences of the other.

> > > The real world is not ideal.=C2=A0 Not all nameservers are i= dentically
> > > scoped - you MUST respect the ordering in resolv.conf - to d= o
> > > otherwise is semantically broken.=C2=A0 If implementation si= mplicity means
> > > literally doing queries in serial, then that is what you sho= uld do.
> >
> > You absolutely cannot respect the ordering in resolv.conf; at lea= st not
> > if you're relying on someone else's resolver.=C2=A0 If th= e orchestration
> > software depends on specific results being returned in particular=
> > orders, the orchestration software should provide a mechanism to<= br> > > generate them.
> >
> > > Similarly, you can't just search all search domains in p= arallel and
> > > take the first response.=C2=A0 The ordering is meaningful. > >
> > It should not be, and more to the point will not reliably be,
> > meaningful.
>
> Search has to be ordered.=C2=A0 You can not possibly argue otherwise?<= br>
Indeed, search certainly has to be ordered. Otherwise results are mo= st
definitely non-deterministic. The trivial example would be looking up
"www" with 2 or more search domains.

In any case, it was discussed way back that, while parallel search
could be implemented as long as a result from search domain N is not
accepted until negative results from domains 1 to N-1 are received,
the implementation complexity cost was too high relative to the value
of such a feature.

> > You are arguing for introducing performance penalties into musl t= hat do
> > not affect you but do very much affect lots of other users.=C2=A0= I hope they
> > do not happen -- musl is not the right place to fix your problem.=
>
> I am arguing for adding a very standard feature (search) to open musl = to a
> whole new space of users. Nobody is forcing you to use search paths or=
> ndots.

The only place adding search support might negatively impact existin= g
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=3D0 rather than ndots=3D1 so that search has to be enabled
explicitly. Are there any reasons this would be undesirable?

Rich

--001a114032704f97750522ed8305--