Resolve links set as DNS to their ip address.

[rubenbe]

When a dns section contains names of linked services,
the names are replaced with the container addresses.

Example:

mydns:
    image: ubuntu:14.04
    command: sleep 300 
web:
    image: ubuntu:14.04
    command: cat /etc/resolv.conf
    links:
      - mydns:dns
    dns:
       - dns
       - 8.8.8.8

This will configure the following resolv.conf in the "web" container:

nameserver 172.17.10.113
nameserver 8.8.8.8

[dnephin]

Interesting idea, I can see this being quite useful, especially if you want to integrate with one of the many dynamic-dns-for-containers-as-a-container options.

It might be worth it to make the syntax container:dns to be a bit more explicit (I believe this is the syntax for net).

@aanand @bfirsh what do you think?

[dnephin]

This could use a bit more documentation, maybe an example below?

[thaJeztah]

Won't this be a problem if the linked service is restarted and changes its IP address?

Also (not sure if that would help here), I think some changes were made recently to dynamically update resolv.conf in some cases.

[dnephin]

Ya, I don't think this should use linked services. It should work with a container outside of the composition.

[thaJeztah]

Well, then fun thing of course is that a linked container will be in /etc/hosts and automatically updated on changes; in which case using just "dns" for the DNS (in stead of the IP-address) would make sense.

[rubenbe]

@thaJeztah I've tried adding "dns" directly in /etc/resolv.conf, but that didn't work.
This is also according to the resolv.conf(5) man page (http://linux.die.net/man/5/resolv.conf) which states that nameservers should be defined by their ip address.

[qzio]

I'm 👍 on this, or at least something like this.

I want to run a dns resolver container that can be used by all the other containers, to be able to take advantage of the dns part of consul.

[aanand]

Interesting idea. @dnephin's container:<name> syntax makes sense.

Two things:

• It seems like this change should be made in Docker, i.e. docker run --dns=container:<name>
• How hard is it to use a linked container as a DNS server without this change?

[lalyos]

The usual workaround for using a dns runing in a container from other containers is to let the dns container:

• expose the port 53:53 and bind to 0.0.0.0 insisde
• expose the port 53 explicitly to 172.17.42.1:53/udp

This way other containers can refer to it as --dns 172.17.42.1 or whatever your bridge_ip is. As an alternative you can use --net=host so can bind to the host ip.

As a consul specific description see the README at https://github.com/progrium/docker-consul

[sttts]

👍 this feature would be great, in my case to model distributed systems with circular dependencies. Manual links don't work in that case.

[steve-jansen]

@lalyos Thank you for highlighting the 172.17.42.1:53:53/udp workaround! Helped me solve a problem with binding the network to the host on CircleCI! 🍻

[thaJeztah]

@steve-jansen @lalyos please note that with docker 1.9, the IP-address is not guaranteed to be 172.17.42.1; moby/moby#17305

[dnephin]

Thanks again for the PR.

Since this PR was first opened a lot has changed. We now have user defined networks in Docker, and in the next release they should be using an embedded DNS server to handle "discovery".

There should be much less of a need for these dns discovery services now that it's built into Docker.

I'm going to close this PR since this functionality should be handled in the next release. If you're interested in following the proposals you can find more information here:

• Support for container aliases when joining a network moby/libnetwork#737
• Proposal: DNS service discovery in Docker to replace /etc/hosts moby/libnetwork#767
• Proposal : Container alias moby/moby#18699