[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAO_Rewb8=V2EN03jyQ4f8bXr0nEXB+fsipgojefzsgiqmeV1Bw@mail.gmail.com>
Date: Sat, 24 Oct 2015 15:32:14 -0700
From: Tim Hockin <thockin@...gle.com>
To: musl@...ts.openwall.com
Subject: Re: Re: Would love to see reconsideration for domain and search
On Oct 24, 2015 3:02 PM, "Rich Felker" <dalias@...c.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@....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?
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
