PiHole Docker Compose not blocking anything but queries are hitting it

Help docker
1

Hi all

I had a running Pihole in my Rpi3 for some years, using docker-compose. Last week the sd died and, obviously, I forgot to back it up.

I reinstalled everything, but I didn't update anything on the router because I kept the Rpi IP address.

After reinstalling, I can see all queries in the PiHole dashboard, but 0 getting blocked.

Like I mentioned, I didn't modify anything at the router because it was working properly before, and I can still see the Rpi IP set as the primary DNS.

When I do a ipconfig /all from my devices, I can see the Rpi IP set as the primary DNS and the router IP as the secondary DNS. I remember I set this so if my RPI died, I wouldn't stop having internet, but in any case, even if some ads would filter through that secondary DNS (router IP) I should see some blocks in the PiHole, which is not the case.

The only thing I noticed is that when I try to update my Gravity, I get an error stating DNS couldn't be resolved.
Important thing to notice:
I can see all the queries hitting the pihole, but 0 getting blocked. If I do an nslookup, I can see the raspberry pi private IP used as the DNS Server and replying.
When I try to update Gravity, I see an error stating DNS Service not working.

I can also see that ftl is not working according to the debug, but not sure why

*** [ DIAGNOSING ]: Pi-hole processes

[✗] lighttpd daemon is inactive

[✗] pihole-FTL daemon is inactive

Here's my debug log:

Debug Log

And this is my docker-compose:

pihole:
container\_name:pihole
image:pihole/pihole:latest
ports:
	\- "53/53:tcp"
	\- "53/53:udp"
	\- "8080:80/tcp"
environment:
	TZ: 'America/Argentina/Buenos\_Aires'
volumes:
	\- './etc-pihole:/etc/pihole'
	\- './etc-dnsmasq.d:/etc/dnsmasq.d'
restart: unless-stopped
2

Your docker-compose looks a bit odd - with all those slashes in between, it seems more similar to a docker run output?

Also, your debug log shows you haven't set a FTLCONF_LOCAL_IPV4 environment variable yet:

-rw-rw-r-- 1 pihole root 131 Oct  6 23:11 /etc/pihole/pihole-FTL.conf
   LOCAL_IPV4=0.0.0.0

You should consider to set that recommended environment variable in your docker-compose file.

You should remove that secondary.
Any alternative DNS server will allow clients to by-pass your Pi-hole at their own discretion.

Pi-hole has to be the sole DNS server on your network, see also Post-Install - Pi-hole documentation.

This would suggest that Pi-hole couldn't populate ist gravity database, which would explain why even those DNS queries that actually make it to your Pi-hole appear to not being filtered, as there are no blocklist domains to match.

Your paraphrased error message hints at a problem with your Pi-hole host machine's DNS resolution, which in turn would explain why Pi-hole cannot populate gravity: The host cannot resolve Pi-hole's DNS requests for your gravity blocklists, and that prevents a successful download.

You'd have to address that issue with your Pi-hole host OS and/or Docker.
What machine and OS are you running your Docker on?

3

Sorry, the slashes are a bad copy, they are not there in my docker-compose
I added the Local_IPV4 variable (check below), but the debug still shows it as 0.0.0.0
I'm running this in Docker-compose in a Raspberry Pi 3 Raspbian 11
Not sure if this is an issue between Docker-compose networking and the OS or not
Just to clarify, my docker compose file is bare bones, it only has the following, I don't have any networking or volumes settings, just pihole under services.

pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
        - "53:53/tcp"
        - "53:53/udp"
        - "8080:80/tcp"
    environment:
        TZ: 'America/Argentina/Buenos_Aires'
        WEBPASSWORD: ''
        LOCAL_IPV4: '192.168.1.159'
    volumes:
        - './etc-pihole:/etc/pihole'
        - './etc-dnsmasq.d:/etc/dnsmasq.d'
    restart: unless-stopped
4

Ok, not entirely sure what I did but I had to enter the container, open resolv.conf in it, copy the contents (which had nameserver pointing to 127.0.0.11, which I guess is an ip in the docker network, not sure why .11 from stock installation though), create a resolv.conf in my host, make it point the nameserver to 127.0.0.1 (which I guess is the docker network gateway?), map it in the docker-compose yaml for pihole
And that fixed the issue
But not sure what's going on nor why I needed it to do it and not everyone has to (guessing that much because it's not part of the official instructions)

5

What was the original contents of your host's /etc/resolv.conf?

Both of 127.0.0.11 and 127.0.0.1 are loopback addresses, pointing to the executing machine itself, i.e. your host, or the container that your Pi-hole runs in, respectively.
If you did alter the contents of any files from within your Pi-hole container, you should be aware that those changes would be reverted once a container image is reapplied.

We'll take a closer look at the tool that populates resolv.conf on your OS later on (i.e. dhcpcd).

That env var name is missing a crucial prefix:

Also, you didn't mention addressing the other issues I mentioned:

Since you've stated that your host OS is Raspbian 11, what's the output of the following command, run from your Pi-hole host machine (so not from inside a Docker container):

grep -v '^#\|^$' /etc/dhcpcd.conf
6

This is the original content of resolv.conf
nameserver 127.0.0.11
options ndots:0

I modified it but not from within the container, but I created a file outside the container and in the host and mapped as a volume through docker-compose yaml, so that will prevent it from getting removed every time I reboot the container.

Thanks, I missed that variable name, not sure how.

This is the result (from Raspbian, not a container)

hostname
clientid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option interface_mtu
require dhcp_server_identifier
slaac private

7

Are you sure this is your host's resolv.conf?

127.0.0.11 is the loopback that Docker would inject into a container for hooking up with its docker-internal DNS services, so this looks more like Docker's internal resolv.conf file.

If you've removed that 127.0.0.11, you've likely stripped your Pi-hole container from being able to resolve docker-internal names, and thus to refer and connect to other containers by name. While that change may address your current issue, you'd want to keep that in mind if you are going to run other containers in conjunction with Pi-hole at some time in the future.

Your dhcpcd.conf shows that you haven't configured a static IP for your host, so that would suggest it would acquire its IP address as well as its gateway and DNS server from your router's DHCP server.
If that's the case, this would support my earlier suspicion that your host's resolv.conf would have looked differently.
You should also be aware that your host's resolv.conf is subject to being overwritten upon acquiring a DHCP lease, e.g. after a reboot.

8

No, sorry, that's the resolv.conf from the pihole container. I didn't read you asked for the host's one, sorry.

The host/RPi resolv.conf is this one:

# Generated by resolvconf
nameserver 192.168.1.159 
nameserver 192.168.1.1

159 is the RPi IP
1 is the Router
And that's correct, my router is set as DHCP and I've given the RPi a static IP.

I get your point about stripping my PiHole container of resolving docker internal names, but then how should I solve the DNS while keeping the internal docker names?
Should I keep both nameservers like my host resolv.conf?
nameserver 127.0.0.1
nameserver 127.0.0.11
?

9

I would recommend not touching the resolv.conf within Docker.
Depending on Docker's network mode, a container may use Docker's internal resolver at 127.0.0.11 in some mode, which would know how to resolve docker-internal names and forward anything else to your host system's resolver, i.e. the one from your host's resolv.conf, or Docker may just inject that file into a container in other modes.
Docker's documentation has the details, e.g. https://docs.docker.com/config/containers/container-networking/#dns-services.

This strongly suggests that your router is distributing its own IP address via DHCP, besides Pi-hole.
Pi-hole has to be the sole DNS resolver for your network, or else clients may by-pass Pi-hole via that alternative DNS resolver at their own discretion.

This is not so much an issue for Pi-hole's DNS resolver itself (as it will always use its configured upstream DNS resolvers), but it is crucial for all clients that you'd expect to use Pi-hole for DNS.

Your router appearing as a DNS resolver for your host and in turn a Docker container may have contributed to your observation:
If you'd have configured your router to use Pi-hole as its upstream DNS resolver, then this would have closed a DNS loop.
Now, if Pi-hole's container would have picked your router's IP to resolve blocklist domain names when updating gravity, then your router would have forwarded them back to Pi-hole, and so forth, ad infinitum or until time-out.

You should check whether your router would be using Pi-hole as upstream in your router's WAN DNS configuration.

In your router's LAN DHCP configuration, you absolutely have to remove your router from the list of DNS servers.

10

I checked the upstream DNS and that's not the case. The router is getting its upstream DNS from the ISP and those are external.
That also wouldn't explain why modifying the docker (not the host) DNS to the docker network gateway solved the issue.
However, after taking a look into the link you sent me, we might have a clue of whats going on:

DNS services

By default, a container inherits the DNS settings of the host, as defined in the /etc/resolv.conf configuration file. Containers that use the default bridge network get a copy of this file, whereas containers that use a custom network use Docker’s embedded DNS server, which forwards external DNS lookups to the DNS servers configured on the host.

if this is correct, then Pi-Hole container resolv.conf should had have the same DNS as the RPi:

192.168.1.159 - RPi private static ip . Would have caused a loop
192.168.1.1 - Router private ip. Wouldn't have caused a loop

But that was not the case, since the Pi-Hole container had this.

127.0.0.11

Which I guess is that Docker embedded DNS which should forward those requests to the host's nameservers.
But for some reason, which I still don't get, that doesn't work when you are using the container as a DNS resolver also. I suspect you are right about the loop, but we haven't found where is that loop happening, since the Router doesn't have the RPi as upstream, only as downstream.
I also don't understand why changing the container dns to 127.0.0.1 worked, but I think that address is "localhost" in a docker network, so basically pointing the container to itself as a DNS resolver fixes the issue?
I've done some searching and I found this to be the solution for several other people:
Docker container DNS not working with pihole
[DNS inside container not working when DNS Server is another container - General - Docker Community Forums](https://DNS inside container not working when DNS Server is another container)

I'm also not sure why is this happening to only some people and not everyone.
Maybe something related to how Docker-Compose creates networks?

11

Another Bug reported with this, related to the kind of networking:
Pi Hole containers cannot resolve DNS when using docker bridge network

12

(I took the freedom to change 172.0.0.x to 127.0.0.x in your post - correct?)

I think you've found it. :wink:

pihole-FTL listens on the 127.0.0.1 loopback address.
When you forced your container to use that 127.0.0.1 for DNS, updating gravity would have triggered the following resolution chain:
Pi-hole container :arrow_right: 127.0.0.1 (=pihole-FTL) :arrow_right: Pi-hole's upstream resolvers

By Docker's default, they may have travelled as followed:
Pi-hole container :arrow_right: 127.0.0.11 :arrow_right: 192.168.1.159 (i.e. Pi-hole again)

I'm not entirely sure that this may have closed the loop, but it could - if Docker's internal DNS resolver would intercept that DNS request before it gets to Pi-hole (I don't run a dockered PI-hole currently, so can't test myself).

To test this, you could try to alter the DNS servers that are used by your Docker host machine.

Since you are on Raspberry Pi OS, you could consider to edit /etc/dhcpcd.conf to append something similar to

interface eth0
        static domain_name_servers=9.9.9.9

Adjust eth0 for the actual network interface name on your RPi as applicable.

With those two lines, your host will still acquire its IP and other options via DHCP, but it will use 9.9.9.9 for DNS, overruling the nameserver your router is distributing.
Run sudo systemctl restart dhcpcd.service for the settings to take effect, verify that your resolv.conf has changed as intended, and restart your Docker container afterwards.