Concerned pihole is misconfigured

I am experiencing multiple issues with my pihole and I've lost confidence it is configured correctly. I know enough to be a danger to myself, but am by no means an expert.

Issues at a high level:

  1. My pihole does not seem to be blocking common ads. I've added some ad domains to the block list (such as tpc.googlesyndication.com and googleads.g.doubleclick.net) but this has had no effect in blocking the ads. It seems only a small % of ads are being successfully blocked.
  2. At one point I configured Cloudflared, now I'm using Unbound which I believe is configured correctly. I removed Cloudflared, yet during Pi-hole debug, it states the following ports are in use:
    127.0.0.1:42783 cloudflare (IPv4)
    127.0.0.1:54 cloudflare (IPv4)
    Could this be causing an issue? Is it possible to remove ports? If so, how?
  3. https://pi.hole/admin and http://pi.hole/ do not resolve, I get a server not found error. http://<IP_ADDPRESS_OF_YOUR_PI_HOLE>/admin/ does work and I can ssh into pihole. Per my understanding, if the Pi-hole is serving as the DNS server, those URLs should work.

High level network configuration:
Router: Google Fiber router pointing to pihole IP address for DNS. DHCP has been disabled on Google Router (in actuality limited to one address, the same address I've reserved for pihole given Google's router doesn't allow DHCP to be disabled - just range limited).
Pi-Hole: Severing up DHCP successfully IP addresses issued, and Upstream DNS Server set as 127.0.0.1#5335 per Unbound documentation.

I really don't want to reinstall from scratch, but I don't know what I don't know.

Debug Token:

https://tricorder.pi-hole.net/YMBAcHhA/

1 Like

You have two DHCP servers active on your network, the router and Pi-hole. This can cause problems unless you have deliberately set them up for non-overlapping IP ranges.

*** [ DIAGNOSING ]: Ports in use
127.0.0.1:42783 cloudflare (IPv4)
127.0.0.1:54 cloudflare (IPv4)

You don't appear to have completely removed this software.

The rest of your debug log shows that Pi-hole is working properly and has processed the following DNS traffic in the past 24 hours:

   [2021-11-21 14:47:14.014 534M] Imported 3454 queries from the long-term database
   [2021-11-21 14:47:14.014 534M]  -> Total DNS queries: 3454
   [2021-11-21 14:47:14.014 534M]  -> Cached DNS queries: 704
   [2021-11-21 14:47:14.014 534M]  -> Forwarded DNS queries: 2651
   [2021-11-21 14:47:14.014 534M]  -> Blocked DNS queries: 87
   [2021-11-21 14:47:14.014 534M]  -> Unknown DNS queries: 12
   [2021-11-21 14:47:14.015 534M]  -> Unique domains: 447
   [2021-11-21 14:47:14.015 534M]  -> Unique clients: 14
   [2021-11-21 14:47:14.015 534M]  -> Known forward destinations: 3

From a client that you believe should be connected to the Pi-Hole for DNS, from the command prompt or terminal on that client (and not via ssh or Putty to the Pi), what is the output of

nslookup pi.hole

nslookup flurry.com 192.168.1.100

1 Like

Thank you for the quick reply.

It looks like two DHCP servers are my only option given my Google Fiber router does not allow to disable DHCP outright. What I've done on the Google Fiber router is set the DHCP Start Address and End Address to the same IP: 192.168.1.100 which is the IP address of the Pi-Hole. I've also reserved the 192.168.1.100 IP address for the Pi-Hole on the Google Fiber router which is the best I can come up with vs. trying to use a different router than the one provided by Google. If I'm off base here, please let me know.

I agree with you assessment regarding Cloudflared not being completely removed. I followed the removal guide found at https://docs.pi-hole.net/guides/dns/cloudflared/ and ran the following commands:

sudo cloudflared service uninstall
sudo systemctl daemon-reload

I also ran the following commands to ensure everything was removed:

sudo systemctl stop cloudflared
sudo systemctl disable cloudflared
sudo systemctl daemon-reload
sudo deluser cloudflared
sudo rm /etc/default/cloudflared
sudo rm /etc/systemd/system/cloudflared.service
sudo rm /usr/local/bin/cloudflared

What additional steps I can take to completely remove this software?

From my mac laptop that should be connected to the Pi-Hole, I ran the two commands from the terminal (not via ssh into the Pi-Hole), but on the laptop itself, and received the following output:

nslookup pi.hole

Server: 2605:a601:ab5f:2d00::1
Address: 2605:a601:ab5f:2d00::1#53

** server can't find pi.hole: NXDOMAIN

nslookup flurry.com 192.168.1.100

Server: 192.168.1.100
Address: 192.168.1.100#53

Name: flurry.com
Address: 0.0.0.0

Neither of these DNS servers is Pi-hole. It is likely that these IPv6 IP's are provided by the router.

This is the expected and correct reply. (the query was forced to go to Pi-hole). If you configure your network or the Mac so that Pi-hole is the DNS server, then Pi-hole will block ads for that client.

This command from the Mac terminal will show the DNS servers in use by the Mac:

scutil --dns

1 Like

Use htop or top to list running processes and in most cases their path, and probably you find the Cloudflare executable that is still running and from htop can easily kill it. It may also still run while the executable got removed already so that a reboot would solve it as well. Since Unbound and Pi-hole both listen on different ports, the Cloudflare daemon does no harm, but of course for the sake of a clean system you may want to assure start it does not and all related files got removed.

Another way to show all services is the systemctl command without arguments. To check whether there is any service like cloudflare present:

systemctl | grep cloudflare
1 Like

It looks like I've found some resolution at this time, but far from a ideal resolution.

@jfb As you alluded to, my client (Mac laptop) was picking up IPv6 from the Google Router. There is no way to disable DHCP completely on the Google Router and/or disable IPv6, instead the only option presented is to restrict DHCP to an IPv4 address range. While I did reserve the IPv4 address for my Pi-Hole (192.168.1.100) with the Google Router and restrict my DHCP IPv4 range to the same address (DHCP Start Address = 192.168.1.100; DHCP Stop Address = 192.168.1.100), it seems the router was still leaking IPv6 and my client was picking up the IPv6 address, thus failing to block ads. My temporary workaround has been to disable IPv6 on my client. As such the ads are now being blocked now and http://pi.hole/ resolves successfully. This is not ideal as the very idea behind the Pi-Hole is to apply settings at the network level vs. making individual configurations on each client. Given this is a limitation with the Google-provided router, it seems my only option is to replace it with a more configurable router so I can disable DHCP completely. This post was helpful as well: Google fiber leaking ipv6 DNS - #3 by Chris_Anthony

I ran nslookup pi.hole and received the following output.. I assume this is correct?

Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	pi.hole
Address: 127.0.0.1
Name:	pi.hole
Address: ::1

@MichaIng Your post was very helpful, I'm not sure why I didn't think to use htop. I had two directories still intact after following the cloudflared removal instructions I listed above:

/home/pi/cloudflared
/home/pi/argo-tunnel/cloudflared

After removing both directories, the processes are no longer running and I seem to have completely removed cloudflared.

Note that DHCP is strictly IPv4.

If you want to handle local DNS for IPv6 correctly, switching off DHCP is not enough, even if it means switching off DHCPv6 as well in your router (not all routers clearly make that DHCP/DHCPv6 distinction).

You have to stop your router from offering its IPv6 address as DNS server.

If your router has no separate IPv6 DNS configuration options, you may consider switching off IPv6 altogether.

If your router offers neither, your IPv6 clients will continue to bypass Pi-hole via IPv6 on occasions.

1 Like

As far as I can tell the only device leaking IPv6 are Android devices on my Google fiber and that's because they will fall back to Google DNS (I think this is hard coded into the software and other apps can be used to bypass this issue or use Pi VPN)

On my Google fiber

I have the DHCP range set to two or three IP addresses. One of them is the static IP address of the Pi Hole. The other is the static IP address of one of my laptops ethernet connections meant for troubleshooting if there's ever problems.
The DNS is set to only the Pi Hole IP address.

Pi Hole setup

The Pi Hole is set with an IP range for DHCP far outside the Google fiber and "Enable IPv6 support (SLAAC + RA)" is checked. All DHCP requests are then handled by the Pi Hole. The Pi Hole is setup to use unbound defaults except this one setting is set to "do-ip6: Yes" and IPv6 DNS set to ::1#5335.
The Pi Hole appears to be blocking both IPv4 and IPv6 requests

I recently went from SD card to USB booting (USB key) on the Raspberry Pi (no idea if I even did it right). After an update to the latest Raspberry Pi OS I was getting large Pi Hole log files taking up about 21gb of space on the SD card. So I did a rebuild of my entire setup on a USB key from scratch.

1 Like

@Bucking_Horn thank you for the reply that was helpful. I am clearly not a network engineer and doing my best to learn as I go.

@Chris_Anthony thank you for your reply.

I tried changing "do-ipv6: Yes" in Unbounded' settings and went into the Pi-Hole's GUI and set Custom 3 (IPv6) to "::1#5335" under Upstream DNS Servers settings. Doing so made http://pi.hole/ unresolvable.

Any ideas?

I haven't had that issue. Only time unresolvable is if the device for some reason is set to use a different DNS server.

How Pi-hole is communicating with Unbound and how Unbound forwards requests doesn't matter at all. All that is relevant here seems to be that the router is sending out RAs, offering itself as local DNS server, and clients usually store multiple nameservers to have a fallback.

If I'm not mistaken, this PR aim to solve such issue by setting the Pi-hole via DHCP three times as local nameserver so that clients cannot store or use any other fallback.

That PR is mainly addressing the IPv4 side of things, at least originally.

As far as IPv6 is concerned, even pushing additional servers via DHCPv6 may only mitigate the issue for clients that use Stateful or Stateless DHCPv6 to join the network, and only if the router's DHCPv6 server is indeed disabled.

It will and can do nothing about SLAAC (NDP/RDNSS).
This has to be disabled in the router, or else IPv6 clients will still learn the router's IPv6 as DNS server.

But one can also provide IPv6 DNS servers via DHCP(v4) isn't it? I'm not sure where the information about available IPv6 DNS servers received via RA is actually stored, but I'd assume that a list of DHCP(v4) leased DNS servers, especially when it contains one reachable via IPv6 as well (e.g. stored in /etc/resolv.conf) would have a higher priority than an IPv6 DNS server received by any random RA. Also when it's IPv4 DNS servers only, a full list should rule out that a client is trying to rely on a random RA, but maybe different clients do different.

No.
Though they serve a similar purpose, DHCP and DHCPv6 are really two separate things - different ports, different protocols.

You're probably biased by dnsmasq being able to support them all (DHCP, DHCPv6 as well as SLAAC), or because quite a few routers may not make that a clear distinction.
They may combine both protocols in one option, or leniently label the DHCPv6 option with DHCP as well (which is one of the reasons why I usually refrain from commenting router screenshots and refer to the router's documentation instead).

DHCP isn't capable of distributing IPv6 addresses (see RFC 1533 section 3.8).

No, it's not that easy

Since a client is not required to use all available options (DHCP, Stateful DHCPv6, Stateless DHCPv6 or NDP), you may not assume that it would request DNS servers via DHCPv6 at all (e.g. Android will never do so, exclusively employing SLAAC/NDP).

And when it comes to dual stack clients, a client's IPv6 prefix policies may impact which DNS server is chosen based on the client's origin and a target's destination IP, which may well displace RA priorities.

No.
IPv4 DNS server addresses as distributed via DHCP have no impact at all on how, how many and which IPv6 DNS server addresses a client would acquire.

Yes, that's always a thing to consider:
Different clients may behave differently, by virtue of their OS and chosen network stack, and how that specific client would have been configured.

However, IPv4 DNS server configuration will never impact IPv6 DNS server configuration.
They are independent from each other.

1 Like

Thanks for clarifications. It actually makes sense that it is strictly distinct as an IPv4-only interface cannot make use of an IPv6 nameserver address and the other way round.

I still wonder how/where the DNS nameserver addresses received via RAs are stored. At least on all networks I can observer, on Linux clients it is not written to /etc/resolv.conf, only DHCP and DHCPv6 leases are written there, depending on the used DHCP client. So the RAs are used to obtain the own IPv6 GUA, in case ULA and the IPv6 gateway on initial interface configuration (SLAAC), but the provided DNS nameserver address (the routers IPv6 address) is ignored, all client requests use the routers IPv4 address only, as received via DHCP(v4) and listed in /etc/resolv.conf, for resolving hostnames to IPv4 and IPv6.

They certainly get written to resolv.conf on my systems:

(click for samples)
[zeropi] $ cat /etc/resolv.conf
# Generated by resolvconf
domain fritz.box
nameserver 192.168.178.28
nameserver fd08::5142
[nanopi] $ cat /etc/resolv.conf
# Generated by NetworkManager
search fritz.box
nameserver 192.168.178.28
nameserver fd08::5142

Maybe your router does not issues RAs then, or your client is configured to ignore RAs?