Score:0

Host's /etc/hosts affecting DNS resolution inside Docker containers

ru flag

I'm working on a project where I'm running one Nginx container (a load balancer) with ports 80 and 443 published to the host, and a few other application Nginx containers with unpublished ports. All three are part of a custom bridge network in Docker, and can communicate with one another using their container names.

I believe this happens thanks to Docker's internal DNS running on 127.0.0.11. One thing I noticed, however, is that whatever I put my FQDN to the host system's /etc/hosts and resolve it to 127.0.0.1 (or 127.0.1.1), it also causes the containers to resolve this FQDN to the local IP address.

That's fine for the load balancer - it will reach itself. It's also fine for the host system, as the load balancer's ports are published to the host system. But it breaks on the application containers, which can no longer reach the load balancer by the FQDN because it's resolving to themselves.

Here's my sample docker-compose.yaml:

version: "3.9"
services:
  lb:
    image: "bitnami/nginx:latest"
  app1:
    image: "bitnami/nginx:latest"
  app2:
    image: "bitnami/nginx:latest"

My host's /etc/hosts:

127.0.0.1 testing.org

Then inside one of the app containers:

# cat /etc/resolv.conf 
nameserver 127.0.0.11

The container hosts file:

# cat /etc/hosts 
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.23.0.2  67d3aaa71abb

And the resolution:

# dig testing.org
;; ANSWER SECTION:
testing.org.        0   IN  A   127.0.0.1

;; SERVER: 127.0.0.11#53(127.0.0.11)

I'm guessing this is mostly intended behavior, but I couldn't find much options to control this.

  1. I could remove the entry in the host's /etc/hosts file, in which case it'll be up to the real DNS servers to resolve the FQDN inside the containers, but also the host. Besides, I wasn't the one to put it there in the first place, it was done by my cloud provider via cloud-init I guess, not sure for what reasons.

  2. I could add explicit hosts entries to each container with the FQDN, pointing to a public IP, or perhaps the internal IP of the load balancer, or the internal IP of the host. This sounds like a nightmare to maintain.

  3. I could also not use Docker's DNS service, in which case I will lose the ability to reference linked containers by their names inside the containers, which is a really great feature I do not want to lose.

Are there any other options? Am I missing something? Docker version 20.10.9, compose version 1.29.2. Ubuntu 20.04 host.

P.S. No, testing.org does not actually resolve to 127.0.0.1, nice try though.

Thanks.

Score:0
cn flag

I'm facing the same issue on DigitalOcean, where the server name is added to /etc/hosts. If the server name is actually a hostname, then DNS resolution errors will occur. In my case, I decided to resolve the issue by modifying the server name.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.