From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8510 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: resolv.conf ordering Date: Tue, 15 Sep 2015 00:43:21 -0400 Message-ID: <20150915044321.GM17773@brightrain.aerifal.cx> References: 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 1442292218 26304 80.91.229.3 (15 Sep 2015 04:43:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Sep 2015 04:43:38 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8522-gllmg-musl=m.gmane.org@lists.openwall.com Tue Sep 15 06:43:38 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 1Zbi5i-00080j-BM for gllmg-musl@m.gmane.org; Tue, 15 Sep 2015 06:43:38 +0200 Original-Received: (qmail 7836 invoked by uid 550); 15 Sep 2015 04:43:35 -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 7801 invoked from network); 15 Sep 2015 04:43:33 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8510 Archived-At: On Tue, Sep 15, 2015 at 03:25:20AM +0000, Jameel Al-Aziz wrote: > I'm sure this has been brought up before, but just thought I'd reach out > see if there's a solution. > > I use musl on Alpine via Docker. I encountered issues today where DNS > wasn't resolving the way we expect in our images. I finally managed to > trace it down to musl's resolver ( > http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc#Name_Resolver_.2F_DNS > ). > > We configure resolv.conf with three DNS servers: Consul DNS, AWS VPC DNS, > Google DNS. It turns out that the AWS VPC DNS is the fastest to respond and > therefore causes results to fail even though they can be served via Consul > DNS. Putting aside that the musl resolver logic breaks convention (which > many people rely on), it seems that in this case it is more unpredictable > than simply following the order. > > The host DNS is Consul, and while we could just setup Consul with > recursors, we run the risk of failing to resolve anything if Consul fails. > Setting up a local caching DNS is also overkill (we're in Docker > containers). > > Is there no way to force musl to follow the order of nameservers in > resolv.conf? Or even if not, to allow musl to accept the first successful > response instead of failing on the first response? It seems to me that we > have to give up reliability for predictability, which is not what this > feature was intended to do from my understanding. > > Any help on this matter would be greatly appreciated! Someone else raised this question on our IRC channel a week or two ago, and in short, the answer is no. Basically this setup does not make sense, even if you do have a resolver (glibc) that does do ordered fallback: - If you expect to sometimes need the second or third nameserver for queries the first cannot answer, then you're going to have terrible performance (multi-second delay before falling back to the second one). - Unless all the nameservers agree on the records they're serving (in which case you wouldn't care about order), your query results will be unstable/inconsistent when the first server fails to respond. The typical result is that you will wrongly get NxDomain instead of a failed/timed-out query. The second issue is really the motivation for what musl is doing: musl is assuming that all the nameservers have consistent records, because if they didn't, actual positive/negative results would be affected by transient failures rather than transient failures being reported to the calling program. This is a serious class of robustness (and possibly security, since DoS can translate into false results) failure. If you really need to union inconsistent records from multiple nameservers, the right way to do this is with a dns proxy/cache. Assuming no _conflicting_ positive responses, it would need to do something like forward positive responses as soon as it has at least one positive response from upstream, but only forward negative responses once it has a negative response from _all_ upstream sources. Of course these are the constraints to do it "right"/robustly. If all you want is something that works at least as well as glibc is working for you now, dnsmasq is probably sufficient. The conversation about all this on IRC was actually quite interesting. We have a no-public-logging policy so there are not logs posted anywhere, but if you're interested in more of what was discussed I could try to summarize it or see if the people involved would be ok with sharing a log excerpt. Rich