Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Sep 2015 03:25:20 +0000
From: Jameel Al-Aziz <me@...aziz.net>
To: musl@...ts.openwall.com
Subject: resolv.conf ordering

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!

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.