From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8734 Path: news.gmane.org!not-for-mail From: u-uy74@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Would love to see reconsideration for domain and search Date: Fri, 23 Oct 2015 10:12:59 +0200 Message-ID: <20151023081259.GX28311@example.net> References: <20151022215608.GA8645@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 1445588015 6895 80.91.229.3 (23 Oct 2015 08:13:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Oct 2015 08:13:35 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8747-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 23 10:13:34 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZpXTd-0002kP-Cm for gllmg-musl@m.gmane.org; Fri, 23 Oct 2015 10:13:29 +0200 Original-Received: (qmail 14079 invoked by uid 550); 23 Oct 2015 08:13:27 -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 14046 invoked from network); 23 Oct 2015 08:13:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fripost.org; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=20140703; t=1445587994; x=1447402395; bh=CxkDN15uD yU2zrWYG8TfOnu0UliSY2W4hJdCtkY4VYo=; b=z5MTleXFtfz6nxGZQycGWSf+7 0lxfRM3v8FhpphrrnIMQgtuX5QkJtwni6/6cUHgjElVnplKcpJl9o4KVQ6zRiLGM QyBT71XyTDDkkZ71VRNDDLmagkgSP5B/h01Lg9U3/mcqzdNLsm3+IvCZF67qL+On sUIQtdjl8W61wXok5k= X-Virus-Scanned: Debian amavisd-new at fripost.org Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:8734 Archived-At: On Thu, Oct 22, 2015 at 11:00:32PM +0000, Josiah Worcester wrote: > > On Thu, Oct 22, 2015 at 02:24:11PM -0700, Tim Hockin wrote: > > But at least it works eventually. You're faced with a choice. Wait 2 > > seconds for ns1 to timeout and then fail in a way that most apps don't > > handle well or wait for 2 seconds and then (usually) get a fast > > response from ns2. > > > > It seems better in every way to eventually succeed, though I agree > > it's a bit less visible. > Consider what would happen if ns1 and ns2 have different responses, but ns1 > for whatever reason times out (potentially an attacker). Then you get the > results for ns2, even though ns1 is intended to override it. > > I have to disagree. Some non-forwarding DNS servers use SERVFAIL to > > indicate "I am not serving for that domain" specifically to make the > > client move to their next nameserver. if ns1 returns SERVFAIL, try > > ns2. If ns1 times out, try ns2. Otherwise what good is ns2? > Note that this means that any condition where ns1 can't be accessed changes > what DNS resolves to. If you wish to prevent unexpected behavior when ns1 > can't be accessed, you simply have to get a response from ns1 first, and > only ever query ns2 when the response from ns1 indicates you may. > > Sure it's faster but it's WRONG. Returning a random number would be > > faster, too, but it is equally wrong. This is why netstat (and myriad > > other tools) has a `-n` flag. > > Again, musl's design assumes that all nameservers are hosting the same > space, and thus a single nxdomain is authoritative. If this is the case, > then this is perfectly correct. If it's not the case, then it's wrong (and > you need to wait for literally everything to nxdomain, and if there's a > timeout from a single server you *need* to report that). > > search path. I might run 100 or more containers on a single machine - > > I can't run 100 DNS caches, and I can't put that back on users. > > Why not? 100 DNS caches shouldn't be particularly expensive. +1 to the level 1 comments +1 to solving the particular problem of a certain deployment (the massive reliance on search paths) inside the deployment, not in a general purpose library It looks unrealistic to both have redundancy and differing/conflicting data on different servers in a consistent fashion, by the mere mechanisms of resolv.conf. Nice that musl chose consistency and redundancy. Good if there is an option suitable for systems which need differing functionality, but please not at an extra cost for other parties. A DNS cache looks of course like the right option for fine tuning the desired resolution behaviour. Rune