Pi-hole not blocking ads

Hello there.

Before I decided to post this, I read several forum topics containing similar problems with the general resolution being things I have definitely already tried. I have resorted to asking for help from much more intelligent people than I in the attempt to resolve these issues I can not get to the bottom of. I appreciate your patience, as I am not expert.

I am struggling to get Pi-Hole to block ads (and several other issues, but one at a time).

Pi-hole is installed via docker compose on Ubuntu Server 22.04.3.
The device I am using is on Windows 10 with Chrome.
I have set my Windows machine to use DNS servers
I have installed pi-hole via docker-compose with the following .yaml file.

    container_name: pihole
    image: pihole/pihole:latest
    env_file: .env
      - ""
      - ""
      - ""
      WEBPASSWORD: secret
      TZ: ${TZ}
      PUID: ${PUID}
      PGID: ${PGID}
      - ./etc-pihole:/etc/pihole
      - ./etc-dnsmasq.d:/etc/dnsmasq.d
    restart: unless-stopped

PUID/PGID is a user I have made specifically for docker. is my routers address. I have also tried setting PIHOLE_DNS_ to my local DNS server and is my server with Pi-Hole installed on it.
This is my only container.

I have used the Pi-hole web UI to change the DNS settings Interface listening behavior to "Listen on all interfaces, permit all origins" as suggested by https://hub.docker.com/r/pihole/pihole.

Browsing to http://pi.hole/admin/ does not work, but browsing to does.

I saw the following advice on https://github.com/pi-hole/docker-pi-hole#readme. I have followed it. It has not worked before or after following these steps. I am unsure if this is outdated. Please advise.

Installing on Ubuntu or Fedora

Modern releases of Ubuntu (17.10+) and Fedora (33+) include systemd-resolved which is configured by default to implement a caching DNS stub resolver. This will prevent pi-hole from listening on port 53. The stub resolver should be disabled with: sudo sed -r -i.orig 's/#?DNSStubListener=yes/DNSStubListener=no/g' /etc/systemd/resolved.conf

This will not change the nameserver settings, which point to the stub resolver thus preventing DNS resolution. Change the /etc/resolv.conf symlink to point to /run/systemd/resolve/resolv.conf, which is automatically updated to follow the system's netplan: sudo sh -c 'rm /etc/resolv.conf && ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf' After making these changes, you should restart systemd-resolved using systemctl restart systemd-resolved

I am using https://www.speedtest.net/ as my test site if that makes a difference. My machine shows up as a client in the query log, just nothing (noticeable) is blocked.

Apologies for the wall of text. I thought the more information the better.

Really appreciate anyone willing to walk me through some further troubleshooting :smiley:

Kindest regards.

Just to make sure I do understand your setup:
You are hosting your Pi-hole DNS server as a Docker container on the very same machine that is to be the only client of Pi-hole?

Which tool is tasked with creating TZ, PUID and PGID environment variables?
What's the contents of that .env file:

Run from that client, what is the output of:

nslookup pi.hole
nslookup pi.hole
nslookup flurry.com

Hello Bucking_Horn. Thanks so much for getting back to me.

I am hosting my Pi-hole DNS server as a Docker container (via compose) on Ubuntu Server. The client I am testing this with is a separate Windows machine.

The contents of the .env file in my compose.yaml directory is:

TZ=My Time Zone

This is a user I've specifically made for docker.

nslookup pi.hole=

Server:  homerouter.cpe
Address:  I have left this out in case security sensitivity. It looks ipv6

*** homerouter.cpe can't find pi.hole: Non-existent domain

nslookup pi.hole

Server:  UnKnown

Name:    pi.hole

nslookup flurry.com

Server:  UnKnown

Name:    flurry.com
Addresses:  ::

Again, I can access the pi.hole dashboard by browsing to on my windows client I'm doing these lookups from and have seen flurry.com has been blocked.

Hope this helps.

It looks like it blocks a lot but not potentially my local ad content? It's strange because ublock origin works perfectly, and if I browse to speedtest.net and check which domains ublock has blocked, these domains are also in piholes default adlist but somehow they get through.

I think I have discovered the issue here.

My clients are being auto-configured with additional ipv6 DNS servers. It's not elegant, but I've just had to blanket disable all ipv6 on all clients to fix this. Turns out it was breaking pihole AND lancache. Not quite sure how to solve this elegantly but at least the problem is now known.

If you have any ideas, please let me know.

That sounds as if your router is advertising its own IPv6 address as DNS server, allowing your clients to by-pass Pi-hole.

You'd have to find a way to configure your router to advertise your Pi-hole host machine's IPv6 as DNS server or to stop advertising its own.

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.

If your router doesn't support that either, your IPv6-capable clients will always be able to bypass Pi-hole via IPv6. Manually configuring each client's IPv6 DNS would also work, but that option may not be available on any device.

1 Like

Thanks so much. I thought that may be the case. Looks like I'm out of luck in terms of an elegant solution.

I have a B818 LTE router which doesn't display options for DNS or ipv4/ipv6 by default, but I managed to expose the options though Chromes 'Inspect' option, make a new 'Internet Connection' Profile with IPv4 only and manual DNS settings set to the pihole, but still when I use nslookup (my router address) it still shows the router as having an ipv6 address (the same address as my clients listed ipv6 DNS) so I think I'm out of luck.

So I guess my only options are setting manual ipv6 DNS settings on every device or disabling ipv6 entirely on devices that allow this. I think I'll just do the latter and be done with it. A shame.

Really appreciate the help :slight_smile:

Kindest regards.