2

I have a CoreOS instance running a docker container which runs dnsmasq. Currently the dnsmasq configuration only set to log all queries and to run in debug mode, so it should just do the caching.

When I try to use this from a different container with dig, nslookup, or simply running ping google.com i get back Bad hostname: google.com and I can see in the log query that requests are coming in multiple times, as if being retried.

If I try to run same commands from the host machine running CoreOS, everything resolves no problem in single try.

My plan is to run the dnsmasq on each CoreOS machine in the cluster, and to have it backed by confd, so that all services can resolve appropriate counterparts.

I'm using Alpine linux for my base images, but I tried to run those commands inside an Ubuntu and a Debian image with the same result.

stefanobaghino
  • 11,253
  • 4
  • 35
  • 63
Vasili Sviridov
  • 191
  • 2
  • 4
  • 14
  • "so that all services can resolve appropriate counterparts"; be aware that docker 1.9 allows you to directly resolve other containers on the same network through their name. (e.g. `ping other-container`). Docker 1.10 has additional enhancements for that and allows you to set "container scoped aliases" and "network scoped aliases" for containers. – thaJeztah Mar 28 '16 at 20:18
  • Yeah, I'm aware, however, it's going to be part of CoreOS cluster, so I'm not sure how Docker will communicate that across multiple hosts. We're also planning to run CoreOS + Flannel, so each container gets a routable IP address, I think this mechanism is also outside of Docker's purview. – Vasili Sviridov Mar 29 '16 at 03:44
  • So, I'm getting closer to the answer. I've ran `nslookup` through `strace` inside one of the containers and one line was particularly interesting - `reply from unexpected source: 172.17.42.1#53, expected 10.137.64.102#53` Basically, the `10.` address is passed to the container as it's `--dns`. But the responses come from the host's `docker` network adapter, so it's being discarded and retried. When I set the resolver as an IP on internal docker network it works fine. – Vasili Sviridov Mar 29 '16 at 04:19

1 Answers1

0

The right thing to do was present in the following thread (Setting Up Docker Dnsmasq)

when exposing the port it should be explicitly bound to an IP address of the host (internal, in our case).

Invocation of the container looks something like this:

source /etc/environment
docker run -d --cap-add NET_ADMIN \
    -p "$COREOS_PRIVATE_IPV4:53:53" \
    -p "$COREOS_PRIVATE_IPV4:53:53/udp" \
    -e COREOS_PRIVATE_IPV4="$COREOS_PRIVATE_IPV4"\
    someorg/dnsmasq

Then all containers that are ran with --dns "$COREOS_PRIVATE_IPV4" get to resolve via machine-level dnsmasq correctly.

Community
  • 1
  • 1
Vasili Sviridov
  • 191
  • 2
  • 4
  • 14