Skip to content

Not resolving using search domain #8

Closed
@NoumanSaleem

Description

@NoumanSaleem

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

gliderlabs/registrator#111

Activity

andyshinn

andyshinn commented on Feb 20, 2015

@andyshinn
Contributor

Looks like musl doesn't support domain and search in resolv.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

brycekahle commented on Mar 4, 2015

@brycekahle

@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

andyshinn commented on Mar 5, 2015

@andyshinn
Contributor

Yep, agree it should be noted somewhere. I'll add some more information to the docs about the caveats soon.

pikeas

pikeas commented on Mar 22, 2015

@pikeas

@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

andyshinn commented on Mar 24, 2015

@andyshinn
Contributor

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

pikeas commented on Mar 24, 2015

@pikeas

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

progrium commented on Mar 24, 2015

@progrium
Contributor

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:

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".


Reply to this email directly or view it on GitHub
#8 (comment)
.

Jeff Lindsay
http://progrium.com

thockin

thockin commented on May 7, 2015

@thockin

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

tifayuki commented on May 29, 2015

@tifayuki

I set up a dnsmasq container. In resolv.dnsmasq.conf, I added

nameserver 8.8.8.8
search example.com

In 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 only base is sent to 8.8.8.8, but base.example.com is never queried.

andyshinn

andyshinn commented on May 29, 2015

@andyshinn
Contributor

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

neilellis commented on Jul 15, 2015

@neilellis

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:

dnsmasq --resolv-file=/etc/dnsmasq-resolv.conf --addn-hosts=/etc/hosts.links --no-daemon

The full image is at https://github.com/vizzbuzz/base-alpine

128 remaining items

Jean85

Jean85 commented on Feb 6, 2018

@Jean85

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

richfelker commented on Feb 7, 2018

@richfelker

Cloudflare has EWONTFIX'd this issue according to:

kubernetes/dns#119 (comment)

Jean85

Jean85 commented on Feb 7, 2018

@Jean85

Exactly, that's why the only solution was removing the triggering domain from the search directive on my end.

added a commit that references this issue on Mar 25, 2018
inodb

inodb commented on May 22, 2018

@inodb

This is closed, but I'm still having problems in the latest release running on kubernetes (kops on AWS):

kubectl run -i --tty alpine --image=alpine --restart=Never -- nslookup kubernetes.default
nslookup: can't resolve '(null)': Name does not resolve

Name:      kubernetes.default
Address 1: 100.64.0.1 kubernetes.default.svc.cluster.local

in busybox nslookup works fine:

kubectl run -i --tty busybox --image=busybox --restart=Never -- nslookup kubernetes.default
Server:    100.64.0.10
Address 1: 100.64.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes.default
Address 1: 100.64.0.1 kubernetes.default.svc.cluster.local
Cloven

Cloven commented on May 22, 2018

@Cloven
inodb

inodb commented on May 22, 2018

@inodb

@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

danlange commented on Jun 20, 2019

@danlange

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @progrium@naturalethic@trashpanda001@matsuu@jwangnz

        Issue actions

          Not resolving using search domain · Issue #8 · gliderlabs/docker-alpine