Pi Hole containers cannot resolve DNS when using docker bridge network #1166
Comments
|
What do you have the Interface Listening Behavior set to on the web interface? Settings > DNS > Interface settings |
I don't think using |
I currently have this set to, "Respond only on interface eth0"
I had pihole DNS running in a different container on the same host. My example was meant to show sibling containers are also affected. I was unclear what to try for the "docker run example(s) in the readme" |
|
attempted to recreate this from scratch today.
Gravity update and dns worked fine at step 5, but when I took the container down, and brought it back up: It failed. DNS on the host works. Using the host as a DNS server from another host works. DNS within the container fails. |
|
Ah, sorry missed the 'host' part. I'm not sure why you are changing that file if everything is working on step 5? You might need to change the Interface Listening Behavior to a more open configuration. Try the other steps. |
At home, I want pihole to serve DNS to the entire network. The router uses the pihole as the primary DNS, so the host uses it as the primary DNS: it's a bit of a chicken-and-egg situation. In testing, I was recreating the problem of my home network.
I'll try a new test changing the interface listening behavior and report back. Which other steps are you referring to? Thanks for your time and attention! |
|
So. I just spent way too much time on this. But I still don't know how to fix it. First thing, step 5 in my recreation procedure is a red-herring. The container DNS works at that point because dockerd doesn't seem to notice updates to Pihole does resolve DNSNext, pihole DOES resolve DNS BUT the container does not accept the response. Here's what So you can see the container But it doesn't make it back to the containerI can watch this route through netfilter logging:
I could set DNS on the host to be the local IP of the pihole container. I think that might work. But this setup should work. I should be able to set the DNS of a machine to its public IP, have dnsmasq/pihole run in a container and expose the ports on the host, and have that container able to resolve DNS. It seems like it should be possible. Is this missing a masquerade rule somewhere? Is that the problem? |
|
Here are the masquerade rules installed by docker, FWIW:
|
|
Since you are using a user-defined network, why don't you try to use a |
|
I am able to resolve this but entering the pi-hole container with: Then I modify etc/resolv.conf The default resolv.conf contains this:
I change it to this:
After making that change I am able to update gravity. Since this is done inside the container the fix has to be applied every time the container restarts. |
|
I was reading this issue again and I think the problem is you are trying to use ports already in use, causing conflicts. Can you please try this? version: "3"
# https://github.com/pi-hole/docker-pi-hole/blob/master/README.md
services:
pihole:
container_name: pihole
image: pihole/pihole:latest
ports:
- "5053:53/tcp"
- "5053:53/udp"
- "67:67/udp" # Only required if you are using Pi-hole as your DHCP server
- "8080:80/tcp"
environment:
TZ: 'America/Denver'
# Volumes store your data between container upgrades
volumes:
- './etc-pihole:/etc/pihole'
- './etc-dnsmasq.d:/etc/dnsmasq.d'
- './var-log/pihole.log:/var/log/pihole.log'
# Recommended but not required (DHCP needs NET_ADMIN)
# https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
cap_add:
- NET_ADMIN
restart: unless-stopped |
|
Hi, I think I have the same issue here every time I restart the container (e.g. after update) or the whole system pi-hole states, it can't resolve any DNS. I can fix it manually by restating the DNS resolver via the settings menu. Sorry I can't provide any logs currently at least not much more then above. But I can say I have quite a similar setting, using docker compose, not using piholes dhcp. Mathes |
|
Hitting this issue as well. |
|
I was just hitting this issue, exact same symptoms and configuration. This happened to be the only container I am running at the moment, so not sure if effects others. here is my compose file edit edit 2 The problem seems to be the user defined bridge created, maybe? |
|
This issue has been mentioned on Pi-hole Userspace. There might be relevant details there: |
|
I believe my issue was of a similar nature. I had to add the dns section to my docker-compose: I spent several hours trying to figure this one out. It would be very helpful if something like this was posted to the docs or part of the example compose file. |
|
This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days. |
|
Commenting something to un-stale this |
|
Does this need un-staling? The OP has long since stopped replying (even to a tagged question...) And other people are suggesting the solution is to set the DNS of the container with the configuration flag. (Or set up a macvlan network as suggested in another comment by @rdwebdesign) This certainly appears to be a docker configuration issue rather than a bug. Setting DNS of your container to is event a documented (optional) step on the readme:
What more needs doing here? |
|
The original issue was probably a config problem with ports (never confirmed or denied by the OP). My suggestion is to close this issue and ask users to open new issues, case by case. |
|
If anything this is something that needs to be (imo) addressed in docs clearly. This isn't really such a limited use case, I came across this a couple months ago. The issue here is that with a container running without host network access, using a Adding 127.0.0.1 to pihole container docker dns config does not resolve the underlying issue here because this isn't what's effectively causing it. The issue is that traffic from other containers arrives from an unexpected (for DNS server) interface as the solution is outlined at https://discourse.pi-hole.net/t/solve-dns-resolution-in-other-containers-when-using-docker-pihole/31413 To explain let's set some assumptions:
127.0.0.11:53 => 10.0.3.14:53 => 172.19.0.1:53 => 172.19.0.2:53 => result is Now there are 2 scenarios:
Sorry if I'm not explaining this better, bit convoluted and I'm most likely not fully understanding the routing here, but hopefully this makes sense |
Each docker network driver has its upsides and downsides. Maybe all this can be avoided if the user chooses to use |
|
This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days. |
This ^ is exactly right—this is a NAT problem. And it even has the solution I used: "make sure the container forwarded port is bound to a host IP". That is, I changed: To (in my setup— Things I did NOT do:
Sorry for disappearing on my own issue—I wanted to do more testing and propose some kind of fix or documentation update here. But that kept slipping down the todo list. I hope this reply is useful, at least. |
|
I was able to get this up and running successfully in docker on a Synology today. Thanks for clarifying this. It appears to be working great for me. For others attempting it, you'll most likely need to map port 80 to a different port, and when accessing the UI, add I'm gonna run this with one or two devices for a few days before pointing the whole-home router's DNS to it. Thanks again! |
|
I had a similar issue. My solution was to simply add "search host" to the /etc/resolv.conf of my Raspberry Pi. As such, the current version of /etc/resolv.conf (the version that fixed the problem) looks like this: |
This is a: Bug
Details
When using a user-defined bridge network (which is the default with docker-compose) the pi hole container cannot resolve DNS (although it can serve DNS traffic from outside the bridge network).
This means Gravity update fails:
Related Issues
Also, googling "127.0.0.11 pihole" comes back with a bunch of related issues:
How to reproduce the issue
I run this with
docker-compose up -dThese common fixes didn't work for my issue
docker runexample(s) in the readme (removing any customizations I added)A simple docker run fails on the same host, likely also due to weird iptables mangling:
None of the other containers on that host work either. If I run this same command on another host in my LAN: works fine. Even with the 127.0.0.11 nameserver.
If the above debugging / fixes revealed any new information note it here.
Add any other debugging steps you've taken or theories on root cause that may help.
Wild speculation
When using a user-defined bridge network, the DNS nameserver inside containers is set to 127.0.0.11. Docker's built-in dns server resolves DNS and passes queries it cannot resolve to the host (i.e., if they're not the name of the other containers on the network).
This fails inside the pi-hole container. Other containers are also unable to resolve DNS. The host and the rest of the LAN are able to use pihole.
This may have something to do with docker's manipulation of iptables the nat table's DOCKER chain—I see its DNAT rules DNAT traffic NOT originating from the docker network's interface on port 53 to the container IP (which might mean everything but the DNS requests of the container). I tried fiddling with it to no avail.
Here's the docker bridge network 🌉
Here's the interface that bridge nework uses:
And, finally, relevant iptables rules
If I start a new container using the same network (
docker run --rm -it --name asdf --network pi-hole_default debian) I can resolve the nameasdfin the pihole container:The text was updated successfully, but these errors were encountered: