Would it be out of the scope of this PR to add support for /etc/resolv.docker as well?

I don't see what you mean. Can you elaborate?

@creack Instead of attempting to read /etc/resolv.conf on the host, docker could look for /etc/resolv.docker first and use that instead of resolv.conf if it exists.

Basically, we'd be giving everyone who's running docker on a desktop machine a really simple way of setting up their DNS resolution for containers without passing -dns to the server.

If this file doesn't exist, the rest of the code path proposed by this PR would be followed. I've described this in #759.

I don't like the idea to add a new file just for this. If we are to add a new file, it would be better to be a /etc/docker.conf or something in order to handle the config.

Fair enough, I'm looking forward to docker.conf.

We won't add a config file in a while (need to stabilize several things first).

If we need this feature in the next 4-8 weeks, we should create the resolv.docker. Otherwise we'll wait for the config file.
—
@solomonstre
@getdocker

On Mon, Jun 10, 2013 at 11:11 AM, unclejack notifications@github.com
wrote:

Fair enough, I'm looking forward to docker.conf.

Reply to this email directly or view it on GitHub:
#832 (comment)

Adding resolv.docker now and having it deprecated when docker.conf support is added would be a nice thing. Of course, this is just my opinion and the best option should be chosen.

resolv.docker would be better than the default 8.8.8.8 for me because that pair of public nameservers is much slower than my local nameserver. Having to pass -dns 192.168.1.1 all the time to docker -d would make things a bit more annoying because I build docker from master often and I have to restart it.

Ha, what are you complaining about, I have a couple of bridges on my
machine, so I have to specify "-b br0" all the time when I start docker! ;-)
(And I ended up putting it in the startup script, and symlinking
/usr/local/bin/docker to the build repo, if that can help in the
meantime...)

I'm not sure that the current behavior pays any attention to /etc/resolv.conf inside the container at all. (Current as of git master a few days ago)

My experiments show that
a) the presence of a /etc/resolv.conf is necessary to start the container.
b) you can put anything you like in that file because..
c) docker replaces /etc/resolv.conf inside the container, with the contents of /etc/resolv.conf outside of the container.
d) /etc/resolv.conf is read-only inside the container.

I like that the inner resolv.conf is populated with the host's, but perhaps an easier trick would be to
a) only copy over the resolv.conf if it doesn't exist in the container already and
b) let resolv.conf inside the container be writable (so that we can then commit it to a new image).

@bencord0 Container specific DNS settings can be used by passing -dns to docker run. This PR is about fixing DNS resolution globally for all docker containers on desktop machines which are using dnsmasq and have "nameserver 127.0.0.1" in their /etc/resolv.conf.

Using an /etc/resolv.conf which originates from the container will break portability of images and containers.

If some kind of special DNS server has to be used for the containers, perhaps a separate docker specific resolv.conf could be introduced.

@jpetazzo Yes, that can be done, but it'd be nice to not have to use such a setup for something so simple on a few boxes. If it's too much to ask for, I'll just redirect 8.8.8.8 and 8.8.4.4 via iptables to 192.168.1.1.

If using /etc/resolv.conf inside the container is not portable, then so is any docker specific resolv.conf.
I might not want to use whatever dns servers that a bundled resolv.conf.docker file provides, and we're back to the original problem.

I would rather create images that don't have /etc/resolv.conf (at the moment, I am using an empty /etc/resolv.conf).
Then if /etc/resolv.conf exists, use it. If not, then generate it from the host or generate it from an override such as -dns.

Would you mind describing your particular use case which requires custom resolv.conf within the containers? There have been 2 or 3 persons who've asked about this, but nobody described an use case.

Having /etc/resolv.docker on the host and using it in the container wouldn't make anything any less portable. It would be the exact same thing as using /etc/resolv.conf from the host within the container.

edit: The point is that resolving www.somesite.com doesn't work by default if you have "nameserver 127.0.0.1" in your /etc/resolv.conf right now. This PR will fix this.

Allowing resolv.conf to be overidden in the container can introduce docker host and environment specific DNS resolver configuration and this can break portability far too easily. That means I could upload an image with a custom resolv.conf to the registry and it wouldn't work for anyone who doesn't have a DNS resolver at whatever IP/IPs I set up in resolv.conf. That means they wouldn't be able to resolve www.somesite.com when running a container from my image.

Allowing people to set up DNS resolvers in /etc/resolv.docker on the host would be only an extension of the current tools which allow us to specify what DNS resolver to use.

If relying on some kind of custom DNS resolver is needed for some applications without that being global to all docker containers, then that should be handled by passing -dns to docker run.

Let's say that container nodeA needs to find container nodeB. If my app depends on hostnames to connect from nodeA to nodeB and vice versa, a custom /etc/resolv.conf has no business being within the container. It should be passed via -dns if it's specific only to a few containers.

Having -dns on the server is also useful regarding docker build.
currently you can't set the dns when using docker build.

Just to clarify @unclejack and @bencord0, I think nobody is proposing custom resolv.conf inside the containers. We're discussing the possibility of a custom resolv.conf on the host. In any case, let's maybe keep that part of the discussion for another issue.

Shit I thought @vieux had already LGTM this one. Sorry.