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.