From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5185 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Requirements for new dns backend, factoring considerations Date: Sun, 1 Jun 2014 10:36:39 -0400 Message-ID: <20140601143639.GE507@brightrain.aerifal.cx> References: <20140601063103.GA12091@brightrain.aerifal.cx> <20140601080150.GE31947@example.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1401633423 12068 80.91.229.3 (1 Jun 2014 14:37:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Jun 2014 14:37:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5190-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 01 16:36:54 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Wr6sX-0004tH-8Q for gllmg-musl@plane.gmane.org; Sun, 01 Jun 2014 16:36:53 +0200 Original-Received: (qmail 3367 invoked by uid 550); 1 Jun 2014 14:36:52 -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 3356 invoked from network); 1 Jun 2014 14:36:51 -0000 Content-Disposition: inline In-Reply-To: <20140601080150.GE31947@example.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5185 Archived-At: On Sun, Jun 01, 2014 at 10:01:51AM +0200, u-igbb@aetey.se wrote: > > As another alternative, we could drop the goal of doing search > > suffixes in parallel. This would have no bearing on lookups of fully > > qualified names using the default settings (ndots:1) since the > > presence of a dot suppresses search. Where it would negatively impact > > performance, though, is for users who want to have several search > > domains (think: home network, university network, department-specific > > university network, etc.) for quick shortcuts to machines on multiple > > different networks. > > My experience is that such kind of shortcuts is dangerous and inconsistent. > They stir different namespaces, this can not give a reliable outcome > in a general case. I tend to agree with this a lot. As long as you leave ndots=1, your shortcuts have no dots in them, and you only have one search domain, I think the results can be fairly reliable/consistent. But in general you're right. I'm not sure if other implementations fall back to searching when this_query.dots>=ndots and looking up this_query as a fqdn failed, but doing so sounds like bad and dangerous behavior and I'd strongly prefer not to do it. > What a certain shortcut resolves to depends on too many things and among > others on which changes are made by third parties to the contents of > the name spaces which you short-circuit (a new host in one's department > can easily take the place of a desired host at a different department). Yes, I think this feature is harmful whenever third-party changes can affect _which_ result you see and not just whether you see a result or not. Note that any use of ndots>1 leads to such issues (e.g. do you get google.com or google.com.example.com?). > > Another option still is leaving search domains unimplemented (musl has > > not supported them up til now, and there hasn't been much request for > > As I see this, spending your time on other things might be a better choice. If we don't want to accelerate it with parallel lookups, leaving it for later, and only if there's demand, is a perfectly viable strategy. It's only a consideration now if parallelism is considered important. Rich