Currently if /etc/resolv.conf contains only localhost nameservers, the following error occurs when starting containers (from the docker daemon logs):

time="2017-02-19T16:10:50.505005194Z" level=info msg="No non-localhost DNS nameservers are left in resolv.conf. Using default external servers: [nameserver 8.8.8.8 nameserver 8.8.4.4]"

The problem with this behaviour is that in some company networks access to all non-managed DNS servers. Compounded with the changes to systemd-resolved which as of version 232 of systemd no longer uses a symlinked resolv.conf but proxies through a server running on 127.0.0.53, I can't create containers without specifying the DNS for every container I start (which is not tolerant to my development laptop moving between the company and my personal network and is pretty inconvenient).

In my opinion, the behaviour that should be adopted is that a DNS proxy (like the one that is used on the default network) runs on the network's default gateway and that all embedded DNS server instances forward to this server which can then use the host machine's DNS configuration. In general, I don't really feel like setting the nameservers to a fixed value by default is a good practice, even if it is Google DNS which you set it to.

Note that containers on the default network, do not have this problem as they presumably do not use the embedded DNS server and route their DNS requests to the gateway IP.

Is there a reason (a security one maybe) that you don't allow localhost DNS nameservers other than the fact they would not be available to the container using the localhost IP?

I am not sure if it's related to #1548 but no one there is reporting the log error I have mentioned and are in fact saying that adding 8.8.8.8 to their /etc/resolv.conf is helping, so probably not.

This issue would be helped with the resolution of #1046 which would allow alternate but is still not useful for a mobile device where the private DNS server is only available on the network that is forcing the use of it.