From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5183 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: Requirements for new dns backend, factoring considerations Date: Sun, 1 Jun 2014 10:01:51 +0200 Message-ID: <20140601080150.GE31947@example.net> References: <20140601063103.GA12091@brightrain.aerifal.cx> 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 1401609816 11438 80.91.229.3 (1 Jun 2014 08:03:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Jun 2014 08:03:36 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5188-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 01 10:03:29 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 1Wr0jp-000868-8Y for gllmg-musl@plane.gmane.org; Sun, 01 Jun 2014 10:03:29 +0200 Original-Received: (qmail 24125 invoked by uid 550); 1 Jun 2014 08:03:18 -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 24067 invoked from network); 1 Jun 2014 08:03:12 -0000 X-T2-Spam-Status: No, hits=0.0 required=5.0 Received-SPF: none receiver=mailfe03.swip.net; client-ip=94.23.9.72; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140601063103.GA12091@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5183 Archived-At: Hello Rich, On Sun, Jun 01, 2014 at 02:31:03AM -0400, Rich Felker wrote: > process, and partly looking for feedback on some of these decisions Here you are: > 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. 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). So I would not care less about efficiency of an uncertain and inconsistent practice/tool :) > 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. > them). But if there is, or will be, demand for them, I don't want the > resolver overhaul design to preclude doing them This is surely reasonable. > (or preclude making > them perform decently). I guess it is very few people in rare situations who might be hit by performance issues there, which would most probably also imply that they have a badly thought-out setup. So much for the feedback. Thanks for your work Rich. Rune