Docker container unable to resolve localhost

Question

I have a docker image that I built from scratch, instead of basing it on an existing image like centos or ubuntu. Processes on the machine do not seem to be able to resolve localhost or the host name, although a mapping for both exists in /etc/hosts . Here the /etc/hosts on the container (generated by docker) looks like this:

 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters 172.17.0.3 39b50fcb603a 

Let's say, as an example, I want to use telnet (other commands fail similarly) to connect to port 80.

 $ telnet 127.0.0.1 80 Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused 

This is great because I am not running anything on port 80. However, let's say I use localhost instead:

 $ telnet localhost 80 telnet: localhost: Name or service not known localhost: Unknown host 

This does not make sense because the mapping from 127.0.0.1 to localhost set to /etc/hosts . Similarly, using the hostname of the container (set by docker) also fails:

 $ telnet $(hostname) 80 telnet: 39b50fcb603a: Name or service not known 39b50fcb603a: Unknown host 

Why does the /etc/hosts seem to not work?

Answer 1

Comes late, but you can / could you repeat with:

getent hosts localhost (or getent hosts <dns name> )?

(you will also need to install getent in your getent image along with any runtime dependencies (check ldd getent )

I'm not good at detail, but AFAIU glibc gethostbyname will use NSS as an implementation for name resolution (at least on my OS, RHEL7). Even without nsswitch.conf NSS 'plugins' libnss_files.so and libnss_dns.so represented by default, and therefore these shared objects will be libnss_dns.so dynamically loaded at runtime. If these shared libraries cannot be loaded at runtime (because they are not installed in your clean image), name resolution will fail.

Essentially, you also need to install these shared objects into the image (I also needed libresolv.so , as the dynamically linked libnss_dns.conf dependency). The details of how they probably differ in different OSs, so it’s not easy for me to immediately describe the exact process.

You can track which shared objects are trying to load using strace (using docker run --cap-add SYS_PTRACE <image> strace <command> ).

One final note: not to be confused with the aforementioned problem when dynamically loaded shared objects are missing at runtime. But if you install dynamically linked executables in a container, this blog post describes a way to automatically detect / set link time dependencies (in essence, it uses regular expressions to parse ldd output)