Pihole has been installed and configured on my system. I'm able to access the web interface on port 80, and according to Test-NetConnection (PowerShell) port 53 is also open. When running nslookup - server I can see the request arrive in pihole.log, and can also see that it is forwarding the request and receiving the (correct) result.
Yet somehow pihole seems to not be sending out the results to the client, thus I'm getting DNS request timed out messages back.
My home network is on 192.168.2.x (/24), and pihole is running in a docker container on the host network on a Windows host with Docker Desktop running through WSL2.
https://tricorder.pi-hole.net/lQcvNMVL/
Run from a client in your network, please share the output of:
nslookup pi.hole
nslookup flurry.com
nslookup pi-hole.net
It does not matter which hostnames I try to look up, the DNS requests are not answered, even though they do show up in the logs.
What's that 192.168.2.28 showing up as DNS server with your interactive nslookups?
Your debug log shows your Pi-hole host machine to be listening on 192.168.4.3/24 (eth0) and 192.168.4.6/32 (services1). Both are on a different subnet than 192.168.2.28.
As for the nslookup results I've asked for:
They show that the Windows machine it runs on is not using Pi-hole for DNS, but an IPv6 address, which seems to belong to your router.
Since your router is advertising its own IPv6 address as DNS server, that would allow your clients to by-pass Pi-hole.
You'd have to find a way to configure your router to stop advertising its own IPv6 as DNS server, or to advertise your Pi-hole host machine's IPv6.
You'd have to consult your router's documentation sources on further details for its IPv6 configuration options.
If your router doesn't support configuring IPv6 DNS, you could consider disabling IPv6 altogether, provided you'd not depend on IPv6 for reasons.
If your router doesn't support that either, your IPv6-capable clients will always be able to bypass Pi-hole via IPv6.
You could then try to mitigate this, by setting Pi-hole as the only upstream of your router, provided your router supports it.
But note that you won't be able to attribute DNS requests to original individual IPv6 clients in such a configuration.
The interactive session is because I've not yet set up my router to only use Pi-hole as the DNS server. If I were to do this now, my entire network would stop working as I would get no DNS replies, which is why I've opened this topic.
The 192.168.2.28 is the ip-address of the Windows host on which Pi-hole is running.
The 192.168.4.x addresses are the internal Docker hosts network ip-addresses. I'm not sure why it has two interfaces on the same network, it has been this way since installation.
Yes, my clients are currently by-passing Pi-hole, as I've not yet configured to only use Pi-hole as that would stop my network from working. I'm aware I need to configure my router to only use Pi-hole to make sure DNS requests are properly handled, and am able to do so, but doing so at this moment breaks everything.
Your observation seems like a routing issue, rather than a Pi-hole one.
Your container's routing table looks like this:
*** [ DIAGNOSING ]: Network routing table
default via 192.168.4.1 dev eth0
127.0.0.0/8 dev lo scope host
172.17.0.0/16 dev docker0 scope link src 172.17.0.1
192.168.4.0/24 dev eth0 scope link
192.168.4.1 dev eth0 scope link
192.168.4.7 dev services1 scope link
Traffic to your 192.168.2.0/24 would be routed via the default route's 192.168.4.1, instead of docker's internal gateway.
Docker runs its internal networks on 172.16.0.0/12 subnet ranges, in your case on 172.17.0.1/16 for its default brigde network:
7: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
That would suggest that those 192.168.4.0/24 addresses would be the result of a custom configuration.
Please share your docker compose or docker run script for your Pi-hole container.
docker_inspect_pihole.txt (13.0 KB)
Only obscured my external IP-address here.
The only network it is connected to is "host":
That's neither a docker compose nor a docker run script.
How do you configure and start your Pi-hole container?
I've used Portainer to set up the container. The only settings I've configured are the ones showing in the documentation:
- Exposing ports (53, 67, 80, 123, 443, 546)
- Adding the volumes to mappings on my server (/etc/dnsmasq.d and /etc/pihole)
- Adding capabilities (NET_ADMIN)
- Setting the restart policy (unless-stopped)
The only thing not listed in the documentation is what network it should be connected to. I've chosen the "host" network hoping it would make accessing the Pi-hole the easiest. This does disregard the exposed ports, as all ports are directly mapped to the host system.
In host mode, the container would directly share the host's network, i.e. it would not have created additional IPs, but have had shared access to your 192.168.2.28.
Your docker inspect results show that your Docker host network is sparsely configured:
"Networks": {
"host": {
"Aliases": null,
"DNSNames": null,
"DriverOpts": null,
"EndpointID": "a1964731ec04ac49cbc2a95ef1670878363371639fbf1ec4068901950c0ffec5",
"Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAMConfig": {},
"IPAddress": "",
"IPPrefixLen": 0,
"IPv6Gateway": "",
"Links": null,
"MacAddress": "",
"NetworkID": "d84939c79d2832ea558248312d3507ed5b1220ab710adbb52cbb06b9fac8c1d9"
}
It's basically missing everything that would make it operational.
For a long time, Docker didn't support host network mode on Windows (as the docker daemon itself runs in a VM on Windows, i.e. it really can't share the host's network interfaces with its containers).
I think Docker started introducing host mode for its beta releases late 2024, but I wouldn't know whether that has GAed by now, nor how to enable it.
It would be easiest if you would run your Pi-hole container with Docker's default bridge network.
Just re-created the container with fresh volumes on the bridge network, and it seems to work.
Thanks for your time and effort!
