Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

docker-compose internal DNS server 127.0.0.11 connection refused

Suddenly when I deployed some new containers with docker-compose the internal hostname resolution didn't work.
When I tried to ping one container from the other using the service name from the docker-compose.yaml file I got ping: bad address 'myhostname' I checked that the /etc/resolv.conf was correct and it was using 127.0.0.11 When I tried to manually resolve my hostname with either nslookup myhostname. or nslookup myhostname.docker.internal I got error

nslookup: write to '127.0.0.11': Connection refused
;; connection timed out; no servers could be reached

Okay so the issue is that the docker DNS server has stopped working. All already started containers still function, but any new ones started has this issue. I am running Docker version 19.03.6-ce, build 369ce74

I could of course just restart docker to see if it solves it, but I am also keen on understanding why this issue happened and how to avoid it in the future.
I have a lot of containers started on the server and a total of 25 docker networks currently. Any ideas on what can be done to troubleshoot? Any known issues that could explain this? The docker-compose.yaml file I use has worked before and no changes has been done to it.

Edit: No DNS names at all can be resolved. 127.0.0.11 refuses all connections. I can ping any external IP addresses, as well as the IP of other containers on the same docker network. It is only the 127.0.0.11 DNS server that is not working. 127.0.0.11 still replies to ping from within the container.

like image 217
Johnathan Avatar asked Sep 22 '20 10:09

Johnathan


Video Answer


2 Answers

Make sure you're using a custom bridge network, NOT the default one. As per the Docker docs (https://docs.docker.com/network/bridge/), the default bridge network does not allow automatic DNS resolution:

Containers on the default bridge network can only access each other by IP addresses, unless you use the --link option, which is considered legacy. On a user-defined bridge network, containers can resolve each other by name or alias.

like image 66
Daniel Lo Nigro Avatar answered Sep 16 '22 13:09

Daniel Lo Nigro


I'm having exactly the same problem. According to the comment here I could reproduce the setting without docker-compose, only using docker:

docker network create alpine_net
docker run -it --network alpine_net  alpine /bin/sh -c "cat /etc/resolv.conf; ping -c 4 www.google.com"

stopping docker (systemctl stop docker) and enabling debug output it gives

> dockerd --debug 
[...]
 [resolver] read from DNS server failed, read udp 172.19.0.2:40868->192.168.177.1:53: i/o timeout 
[...]

where 192.168.177.1 is my local network ip for the host that docker runs on and where also pi-hole as dns server is running and working for all of my systems.

I played around with fixing iptables configuration. but even switching them off completely and opening everything did not help.

The solution I found, without fully understanding the root case, was to move the dns to another server. I installed dnsmasq on a second system with ip 192.168.177.2 that nothing else than forwarding all dns queries back to my pi-hole server on 192.168.177.1

starting docker on 192.168.177.1 again with dns configured to use 192.168.177.2 everything was working again

with this in one terminal

dockerd --debug --dns 192.168.177.2

and the command from above in another it worked again.

> docker run -it --network alpine_net  alpine /bin/sh -c "cat /etc/resolv.conf; ping -c 4 www.google.com"
search mydomain.local
nameserver 127.0.0.11
options ndots:0
PING www.google.com (172.217.23.4): 56 data bytes
64 bytes from 172.217.23.4: seq=0 ttl=118 time=8.201 ms

--- www.google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 8.201/8.201/8.201 ms

So moving the the dns server to another host and adding "dns" : ["192.168.177.2"] to my /etc/docker/daemon.json fixed it for me

Maybe someone else can help me to explain the root cause behind the problem with running the dns server on the same host as docker.

like image 40
CKolumbus Avatar answered Sep 19 '22 13:09

CKolumbus