Solve DNS Resolution in Other Containers when using Docker pihole

FAQs Community How-to's
1

Problem

When using docker pihole container as the sole DNS on the network, other containers cannot resolve DNS.

Symptoms

  • Other containers unable to resolve DNS
  • using nslookup in other containers gives erros stating something like
    ;; reply from unexpected source: 172.17.0.1#53, expected 192.168.1.2#53
    where 192.168.1.2 is the pihole DNS and 172.17.0.1 is the docker bridge network gateway
  • pihole logs show that the queries from other containers are arriving, forwarding, and being responded to as far as pihole knows.

Cause

I think it's because Docker does shenanigans with DNS so that it can do automated name resolution based on container names. The iptables Docker puts in place don't seem to be properly masquerading the IP of the DNS, so the container thinks its DNS request are being intercepted and ignores the responses.

Solution

Bind the DNS listening port to the specific external IP you want to listen on in the docker run or docker-compose file. e.g. my docker compose went from this:

ports:
      - "53:53/tcp"
      - "53:53/udp"
      #- "67:67/udp"
      - "81:80/tcp"
      - "443:443/tcp"

to this:

ports:
      - "53:53/tcp"
      - "192.168.1.2:53:53/udp"
      #- "67:67/udp"
      - "81:80/tcp"
      - "443:443/tcp"

I imagine the same might need to be done for 53/tcp as well, though I haven't worked that yet since I don't use DNS over TCP.

14 Likes
2

I had the very same problem: all devices in the network including the raspberry pi itself could use the pihole as the new DNS server... except inside the other containers running on the raspberry pi.

Your solution - using the local IP address of the raspberry pi - worked! I don't know how you manage to find that :slight_smile: .

Thank you very much! :pray:

3

Any thoughts as to get this working while using --net=host?

Found It - need to use listen-address and bind-interfaces[1] to force Pihole on the specific IP/Interface. Now containers can successfully resolve internally.

[1] Make pihole-FTL bind only on certain IPs [v4.0] - #4 by deHakkelaar

1 Like
4

Thank you. This solved my problem why Nextcloud and other containers couldn't resolve all addresses.

5

Thank You so much. This was driving me crazy and your solution worked perfectly.

6

Thanks! Saved the day, literally :slight_smile:

7

Thanks a bunch! This really should be documented somewhere.

1 Like
8

3 posts were split to a new topic: Issues when restarting image jacklul/pihole

11

THIS SOLVED MY ISSUES AS WELL!! :slight_smile:

... did you end up changing "53:53/tcp" to "192.168.1.2:53:53/tcp" as well?

12

Thanks for this! it appears 53/tcp doesn't need to be binded to the ip/interface. would love to know more details on why exactly is this happening

13

The above solution for me is NOT the best.I would like to suggest a solution much easier and with absolutely no editing in any docker-compose.yml.
In /etc/resolvconf.conf you just need to enable:
nameserver 127.0.0.1
... as written in this file itself:
# If you run a local name server, you should uncomment the below line and
# configure your subscribers configuration files below.

After this just do a
sudo resolvconf -u
to update the reslove-config. .. and of course redeploy your containers.

1 Like
14

Thank you 3lder

Updated my docker containers last night, including PiHole and for some reason I ended up with this issue.
The internal containers could no longer access the DNS port 53 on the host. I am running PiHole with the port exposed to the host.
I removed Resolvconf since it could not run at the same time as PiHole.

Passing the host IP as part of the export now resolved this issue, but I don't understand how a working system would break like this after updating.
I did try and roll back to last week's version, but it didn't help.
Statically setting the DNS worked on some containers, but on other it just timed out.

Thank you for the solution.

15

Greetings from the future...

I found this bug today. In my case, the server was with reserved DHCP. I think this does not write an address at some appropriate time and all the containers cannot find a resolve address.

When I made a fixed address in NetPlan, then it all came together. I'm sure there it a better way to fix it, but for me, I just assigned a static address.