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:
> > > >
> > > > 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?