From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8765 Path: news.gmane.org!not-for-mail From: Tim Hockin Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Would love to see reconsideration for domain and search Date: Sat, 24 Oct 2015 15:32:14 -0700 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=001a114364f6cef22b0522e14c93 X-Trace: ger.gmane.org 1445725973 1271 80.91.229.3 (24 Oct 2015 22:32:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Oct 2015 22:32:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8778-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 25 00:32:38 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 1Zq7MU-00070J-82 for gllmg-musl@m.gmane.org; Sun, 25 Oct 2015 00:32:30 +0200 Original-Received: (qmail 22387 invoked by uid 550); 24 Oct 2015 22:32:28 -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 22363 invoked from network); 24 Oct 2015 22:32:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RwLbP0Iflb6RjgmUWTJTc61NnIZ8sGj8ytKbm+4VU+Y=; b=V97J9uizHFzykn4Admp/KwQTe1XvZHZ8NTFypQQZ06QEVHZMfu/8Ty/HJB76gX5p/r ZqbcfDdp2a0Noc75cRdQxWj44tWvHKyduEFXZ+SHjkVrux5Ebpk60KR9JyEnGJogb8My LDBWl/3hlLJfsDJkQFYJ718XbFlloMHS2Pe126Kq7XtAN8IZAsEyaP58fsvMf9P+yqhw EfBjNSbAi1PtCuueFnJmODnQkr6vwfXA2h5+ARiMTYQhKN5NGPC6WJTAFlKAddykyVhA wu/c02FkXxlt4FSkEhNt8A4r7H4qv2Q6NWVDODHN1n6OaV8k3JCBBL5XRPgVI5vEdlgI Ezuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=RwLbP0Iflb6RjgmUWTJTc61NnIZ8sGj8ytKbm+4VU+Y=; b=RizByLj0LS5Cj7yA7kdiC6CLDNKdv8ynkZZVK1fNjN0pkJXnVOGpTfPsZR4Ysb0jvu pfdISCTDUnatqVfxjIRsLAYlC8tgnYAu69jPDyoC7b+vLe/9K1CLbTbdkYano1TVFObO Ey/acsGAkv4PHTZCkgvyh+FCys5D+Mu7CZlvRYxwU8EhIYjmSwdJIemSxTXpojfAIeJw r4i3axe0d6ODNJd4MMjK/JiVh5rmyJadOot7y5A1DKx9wloRX0EWyMkkL3oECASBKSMS MT81VfpAjOByCDNyKXvBQrsWQ4RI/N/rOCJhJuV3pRjn4qTdmv0T0jjj78cYnBDoUK4O PnvA== X-Gm-Message-State: ALoCoQko8ap8Z3Z/h2V+d2WliQVfAOT7VE3BtlgE6Pr/aaAeSzKPbpue/zeV01gCq7Qr2uKWlXJp X-Received: by 10.31.16.3 with SMTP id g3mr16463090vki.83.1445725935147; Sat, 24 Oct 2015 15:32:15 -0700 (PDT) In-Reply-To: <20151024220215.GV8645@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:8765 Archived-At: --001a114364f6cef22b0522e14c93 Content-Type: text/plain; charset=UTF-8 On Oct 24, 2015 3:02 PM, "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 My point was only that you can't call this "embrace and extend" of a "standard" when no such standard exists AND the most widely used software doesn't conform to your supposed standard. I can see both sides of the argument and have already conceded this as the least important part of the proposal, for our use case. > 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. OK, I thought for a minute you went off the deep end :) > 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. Agree > > > 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? So you want "naked" names to not use search at all? Is that really useful? --001a114364f6cef22b0522e14c93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 24, 2015 3:02 PM, "Rich Felker" <dalias@libc.org> wrote:
>
> On Sat, Oct 24, 2015 at 02: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:<= br> > > > >
> > > > I understand your point, though the world at large tend= s 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 operatio= n on actual
> > > standards.
> >
> > Where is the standard that defines ordering semantics in resolv.c= onf?
>
> 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

My point was only that you can't call this "embrace= and extend" of a "standard" when no such standard exists AN= D the most widely used software doesn't conform to your supposed standa= rd.

I can see both sides of the argument and have already conced= ed this as the least important part of the proposal, for our use case.

> intended, and even then it's rather arbitrary wheth= er people would
> care about that intent since it doesn't seem to have been document= ed
> 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 identically
> > > > scoped - you MUST respect the ordering in resolv.conf -= to do
> > > > otherwise is semantically broken.=C2=A0 If implementati= on simplicity means
> > > > literally doing queries in serial, then that is what yo= u should do.
> > >
> > > You absolutely cannot respect the ordering in resolv.conf; a= t least not
> > > if you're relying on someone else's resolver.=C2=A0 = If the orchestration
> > > software depends on specific results being returned in parti= cular
> > > orders, the orchestration software should provide a mechanis= m to
> > > generate them.
> > >
> > > > Similarly, you can't just search all search domains= in parallel and
> > > > take the first response.=C2=A0 The ordering is meaningf= ul.
> > >
> > > 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 otherw= ise?
>
> Indeed, search certainly has to be ordered. Otherwise results are most=
> definitely non-deterministic. The trivial example would be looking up<= br> > "www" with 2 or more search domains.

OK, I thought for a minute you went off the deep end :)

> In any case, it was discussed way back that, while para= llel 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<= br> > of such a feature.

Agree

> > > You are arguing for introducing performance p= enalties into musl that 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 pro= blem.
> >
> > 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 pat= hs or
> > ndots.
>
> The only place adding search support might negatively impact existing<= br> > 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?

So you want "naked" names to not use search at all= ?=C2=A0 Is that really useful?

--001a114364f6cef22b0522e14c93--