From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8509 Path: news.gmane.org!not-for-mail From: Jameel Al-Aziz Newsgroups: gmane.linux.lib.musl.general Subject: resolv.conf ordering Date: Tue, 15 Sep 2015 03:25:20 +0000 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113d51b2e3689e051fc0bbc9 X-Trace: ger.gmane.org 1442287559 28578 80.91.229.3 (15 Sep 2015 03:25:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Sep 2015 03:25:59 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8521-gllmg-musl=m.gmane.org@lists.openwall.com Tue Sep 15 05:25:53 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 1ZbgsQ-0005Y4-Ez for gllmg-musl@m.gmane.org; Tue, 15 Sep 2015 05:25:50 +0200 Original-Received: (qmail 7472 invoked by uid 550); 15 Sep 2015 03:25:48 -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 7421 invoked from network); 15 Sep 2015 03:25:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jalaziz.net; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=twRasBC8nUYsaSsKftUxmyLajNdH4YdRwvpOkngQfIc=; b=cLTytQ8Z6dBXVzwdXc8VGeaW+ggeFvVjfH4HoICPRRpoJ+wSC/XafDJ9+pysDcGiZ5 dXZAA4LGmkZpT8oY29oZvk4qC45VuXM2R2v3PcwhHqTvaSw7hKVuIaN0uDrhEzXu9TWP SUlKdHks+rAZtwOkiwnk6+WmqrETl8g7ls7B4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=twRasBC8nUYsaSsKftUxmyLajNdH4YdRwvpOkngQfIc=; b=OuVnnaXgbk7jF1/mSgKZzDaw6cIOzpzljaJI+hVL+tz2a4mO76Md8I4v+FlhcczoyF PP4sqyGQYz+fTDAm86La7xVslb/sccjij7nxME/jasKcS3M49MxJU5tdNtX/QCXC4K5a AoRSeUfG7WZTColrv6ygnK/AQ957LEO3qR6y4DeXqVH+7xu/M+j2UHDtEw3ieOV/Z8Um CvijiXHobU+8hinxWUS7VsheAf7c8YUsIDVNWeDj2b/M0RNFVRohWHkQKY9MyarDz3Xd 1Ra1Z07JIdAK8nL2Efbpg6RWRieT0B098ivRyNjJxLZMGj7LTmkHX3OT7iO2Fu1ULGts 8VPQ== X-Gm-Message-State: ALoCoQmlzkoIyRWsn1ih0rDcv9utNd8ZjcFSeMxaI/Qgh7Qzb6czYNMYEFq/wInNTBxVVWicZrF2 X-Received: by 10.202.215.68 with SMTP id o65mr14301076oig.100.1442287529970; Mon, 14 Sep 2015 20:25:29 -0700 (PDT) Xref: news.gmane.org gmane.linux.lib.musl.general:8509 Archived-At: --001a113d51b2e3689e051fc0bbc9 Content-Type: text/plain; charset=UTF-8 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! --001a113d51b2e3689e051fc0bbc9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm sure this has been brought up before, but just tho= ught I'd reach out see if there's a solution.

I = use musl on Alpine via Docker. I encountered issues today where DNS wasn= 9;t resolving the way we expect in our images. I finally managed to trace i= t down to musl's resolver (http://wiki.musl-lib= c.org/wiki/Functional_differences_from_glibc#Name_Resolver_.2F_DNS).

We configure resolv.conf with three DNS servers: Con= sul 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 ca= n be served via Consul DNS. Putting aside that the musl resolver logic brea= ks 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 recurs= ors, we run the risk of failing to resolve anything if Consul fails. Settin= g 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 see= ms to me that we have to give up reliability for predictability, which is n= ot what this feature was intended to do from my understanding.
Any help on this matter would be greatly appreciated!


--001a113d51b2e3689e051fc0bbc9--