Closed
Description
Hostname is not properly resolving within the container when setting --dns-search on Docker.
Docker settings:
DOCKER_OPTS="--bip=172.17.42.1/16 --dns=172.17.42.1 --dns=10.0.2.15 --dns-search=service.consul"
gliderlabs/alpine
vagrant@local:~$ docker run --rm -it gliderlabs/alpine sh
/ # ping consul
ping: bad address 'consul'
/ # ping consul.service.consul
PING consul.service.consul (10.211.55.22): 56 data bytes
64 bytes from 10.211.55.22: seq=0 ttl=64 time=0.045 ms
progrium/busybox
vagrant@local:~$ docker run --rm -it progrium/busybox
/ # ping consul
PING consul (10.211.55.22): 56 data bytes
Activity
andyshinn commentedon Feb 20, 2015
Looks like musl doesn't support
domain
andsearch
inresolv.conf
: http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc#Name_Resolver_.2F_DNS. We're researching workarounds to this issue. Thanks for reporting!brycekahle commentedon Mar 4, 2015
@andyshinn the musl behavior of querying all nameservers in
/etc/resolv.conf
in parallel and using the the first response is unexpected. Perhaps that could be added to the documentation?andyshinn commentedon Mar 5, 2015
Yep, agree it should be noted somewhere. I'll add some more information to the docs about the caveats soon.
pikeas commentedon Mar 22, 2015
@andyshinn The docs are a good start, but they raise further questions. It would be great if the section on dnsmasq (http://gliderlabs.viewdocs.io/docker-alpine/caveats) could be fleshed out to provide a full solution.
andyshinn commentedon Mar 24, 2015
I tried to provide a general example of the use case where you want to send internal requests to a Consul server and the rest out to upstream name servers. What specifically do you think the example is missing?
pikeas commentedon Mar 24, 2015
A brief description of dnsmasq and how to use it - on the host, as an additional container, etc. In other words, specific instructions on use, rather than "maybe try this workaround".
progrium commentedon Mar 24, 2015
I think it could use a full dnsmasq config for the custom+upstream DNS
scenario so people can figure out how to run it on the host, then a pointer
to a good generic dnsmasq Docker container that would be easy to apply that
configuration for people that want to run it in a container, and lastly,
once available, a pointer to our magic resolve container.
On Tue, Mar 24, 2015 at 3:36 PM, Aris Pikeas notifications@github.com
wrote:
Jeff Lindsay
http://progrium.com
thockin commentedon May 7, 2015
I was so hopeful for docker-alpine - I need a mini package for DNS utils. Alas, DNS in alpine seems to be totally busted. A shame.
tifayuki commentedon May 29, 2015
I set up a dnsmasq container. In
resolv.dnsmasq.conf
, I addedIn alpine container I set the dns pointing to that dnsmasq container.
The problem is when I do
ping base
in alpine container, the log of dnsmasq shows that onlybase
is sent to8.8.8.8
, butbase.example.com
is never queried.andyshinn commentedon May 29, 2015
The 3 dnsmasq options that might append a domain to unqualified names is
--expand-hosts
,--domain
, and--auth-zone
. Can you try setting these to see if it changes the behavior? Unfortunately, the only other way to do this is with some host file manipulation on the dnsmasq container.neilellis commentedon Jul 15, 2015
This cannot be solved using dnsmasq, dnsmasq assumes glibc has expanded the hostname from the search entry in /etc/resolv.conf.
If you are in an environment (like Tutum) where links don't work because of this:
https://gist.github.com/neilellis/8983d6977f45f126df28
Is my workaround in conjunction with running dnsmasq:
The full image is at https://github.com/vizzbuzz/base-alpine
128 remaining items
Jean85 commentedon Feb 6, 2018
I've stumbled onto this same issue, and I've solved it removing the a
search
directive, which was triggering a CloudFlare DNS (buggy) resolution.I've found out about the solution with this blog post: https://blog.maio.me/alpine-kubernetes-dns/
richfelker commentedon Feb 7, 2018
Cloudflare has EWONTFIX'd this issue according to:
kubernetes/dns#119 (comment)
Jean85 commentedon Feb 7, 2018
Exactly, that's why the only solution was removing the triggering domain from the
search
directive on my end.Update kafka 10 to newer alpine
inodb commentedon May 22, 2018
This is closed, but I'm still having problems in the latest release running on kubernetes (kops on AWS):
in busybox nslookup works fine:
Cloven commentedon May 22, 2018
inodb commentedon May 22, 2018
@Cloven nice, thanks for clarifying! Seems like it could be nice to have a p big warning sign for using alpine images on k8s somewhere
danlange commentedon Jun 20, 2019
I was experiencing a similar issue, and it was caused by a subtle configuration difference between alpine and glibc based linuxes.
If the "ndots" flag in /etc/resolv.conf is set to zero, then the search path will be disabled.
See: https://wiki.musl-libc.org/functional-differences-from-glibc.html