thaJeztah
commented
6 years ago Hm, I actually think that documentation is incorrect (well, at least partially). I'm also not sure why that worked for you previously in 18.06.
Note that on systems that have systemd-resolvd enabled, /etc/resolv.conf is no longer the "leading" configuration file, but another file is used instead (/run/systemd/resolve/resolv.conf).
Docker 18.09 detects if systemd-resolvd is running and, if so, uses the correct one (code for that was added in https://github.com/moby/moby/pull/37485/commits/e353e7e3f0ce8eceeff657393cba2876375403fa)
Trying to reproduce the /etc/hosts issue, I tested this on Docker 18.06.1, 18.09.0, and even an old 17.06 docker, and all produce the same result;
Add an entry to /etc/hosts
echo "123.123.123.123 foo.bar" >> /etc/hostsPing that host from inside a container (on the default "bridge" network);
docker run --rm busybox sh -c 'ping -c1 foo.bar'
ping: bad address 'foo.bar'And the same, using a custom network
docker network create bla
docker run --rm --network=bla busybox sh -c 'ping -c1 foo.bar'
ping: bad address 'foo.bar'Adding a custom host to the container works;
docker run --rm --network=bla --add-host=foo.bar:123.123.123.123 busybox sh -c 'ping -c1 foo.bar'
PING foo.bar (123.123.123.123): 56 data bytes
--- foo.bar ping statistics ---
1 packets transmitted, 0 packets received, 100% packet lossWhen using the default (bridge) network;
- docker locates the active
resolv.conf, - creates the container, and creates a copy of the
resolv.conffor the container - starts the container, and (depending on the container configuration, for example if a custom
--dnsis set) rewrites the file - the container's
resolv.confis "mounted" from the host to the container (so that it can be accessed from inside the container)
When using "host" networking (--network=host);
- docker locates the active
resolv.confand/etc/hostsfile (if present) - creates the container
- starts the container, and mounts the active
resolv.confand/etc/hostsfiles rom the host to the container (so that it can be accessed from inside the container)
When using a custom bridge network;
- docker creates a
resolv.conffor the container, containing an entry for the embedded DNS - creates the container
- starts the container, and mounts the container's
resolv.conffrom the host to the container (so that it can be accessed from inside the container) - the embedded DNS is used to resolve other containers on the same network, but will forward other requests to the DNS that is configured on the host
The code to generate the initial /etc/hosts file in the container is in libnetwork: https://github.com/docker/libnetwork/blob/d0ae17dcfaa1f21e3b0f5d55bba4239f08489640/etchosts/etchosts.go#L27-L112
And the code to generate the container's /etc/resolv.conf file in the container https://github.com/docker/libnetwork/blob/d0ae17dcfaa1f21e3b0f5d55bba4239f08489640/resolvconf/resolvconf.go#L223-L254
Example; default bridge network
Add a comment to the end of /etc/resolv.conf on the host, and add a "search domain" (this will affect your networking, so this is just to illustrate :sweat_smile:)
echo "# Hello world" >> /etc/resolv.conf
echo "search localdomain.com" >> /etc/resolv.confCheck its content;
cat /etc/resolv.conf
nameserver 2001:4860:4860::8844
nameserver 2001:4860:4860::8888
nameserver 8.8.8.8
# Hello world
search localdomain.comNow, start a container on the default (bridge) network, and check the /etc/resolv.conf inside the container.
Notice that the IPv4 nameserver, and the search domain are copied from the host. Comments are also left in place:
docker run --rm busybox sh -c 'cat /etc/resolv.conf'
nameserver 8.8.8.8
# Hello world
search localdomain.comNow, start a container with a custom DNS set (also on the default "bridge" network);
docker run --rm --dns=1.1.1.1 busybox sh -c 'cat /etc/resolv.conf'
search localdomain.com
nameserver 1.1.1.1This time a fresh The custom DNS is written to the container's copy of resolv.conf, but the search domain is kept intact.
Example: host networking
In host networking, the container runs in the host's networking namespace, so will also use the same networking configuration as the host (hence the host's resolv.conf and /etc/hosts being mounted inside the container);
docker run --rm --network=host busybox sh -c 'cat /etc/resolv.conf'
nameserver 2001:4860:4860::8844
nameserver 2001:4860:4860::8888
nameserver 8.8.8.8
# Hello world
search localdomain.comAnd the /etc/hosts is also the same as on the host;
docker run --rm --network=host busybox sh -c 'cat /etc/hosts'
127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
123.123.123.123 foo.bar
fcrisciani
shubb30
5ilvers
Cheaterman
claytonlemons
tkrah
nikosT
frimik
Expected behavior
Works in Docker version 18.06.1-ce, build e68fc7a
/etc/hosts file contains some domains for development. When I ping such domain inside container (inside user defined network) I get the right IP address.
Docs says that container inherits DNS settings from Docker daemon inlcuding /etc/hosts and /etc/resolv.conf. (https://docs.docker.com/config/containers/container-networking/#dns-services)
I don't know exactly how that works but when I inspect the network, this is what happens when pinging domain from /etc/hosts:
Check the image above, you can see that something originating from 127.0.0.1 asks my local DNS resolver at 127.0.0.53, it returns back and then the container seems to already know the address.
Actual behavior
In updated version of docker the DNS query goes from container straight to DNS server outside my network. I know I can override this with --dns option and I do that now because I have no choice. But it was really convenient to just set up /etc/hosts real quick and go.
Steps to reproduce the behavior
Update docker to version 18.09, add record to /etc/hosts locally, ping that domain from container.
Output of
docker version:Output of
docker info:Additional environment details (AWS, VirtualBox, physical, etc.) Firewall is up, extra rules are: 22/tcp ALLOW Anywhere
Xdebug ALLOW Anywhere