First, yes, I understand this is a very common problem that's been resolved before, but after digging through a bunch of previous posts and their solutions, I haven't been able to solve mine.
Expected Behaviour: I am utilizing the Pi Hole as DNS on my Windows 10 client (basic desktop environment connected to network via either 2.4 GHz or 5 GHz wireless - tried both). I'm expecting ads to be blocked when utilizing Pi Hole as my DNS but I can't find any example of them being blocked. Web interface proudly tells me 1,470 queries with 119 blocked, but I'm seeing none of this in my browsing. Optimally I want to run all traffic at the router level through the Pi Hole for DNS, blocking ads on all clients including smart TV apps, etc. Router is this one, a TP Link AC 1900: https://www.amazon.com/TP-Link-AC1900-Smart-Wireless-Router/dp/B0141JGYNM/ref=sr_1_3?dchild=1&keywords=archer+c9&qid=1630196335&sr=8-3)
Actual Behaviour:
Websites load, slowly, but are still full of ads.
Debug Token:
Tried to upload, got the below error. Removed Pi Hole as client DNS and tried to run debug again, upload failed again with same error.
[?] Would you like to upload the log? [y/N] y
* Using curl for transmission.
* curl failed, falling back to netcat for transmission.
nc: getaddrinfo for host "tricorder.pi-hole.net" port 9999: Temporary failure in name resolution
[✗] There was an error uploading your debug log.
Please try again or contact the Pi-hole team for assistance.
EDIT: I completely reimaged the SD card and debugging worked this time. Debug token prior to editing resolv.conf is cDR2Mgxx. After editing, debug token is BTM1oDPU. If that one doesn't work then maybe the 1 is a lowercase L?
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
Then do the following.
This will temporarily reset the nameserver on the Pi to bypass Pi-Hole DNS.
sudo nano /etc/resolv.conf
Edit the nameserver line to nameserver 9.9.9.9 or your preferred third party DNS service, save and exit
In the Advance>Network>DHCP Server section of the TPlink Router, the field labeled "Primary DNS:" is where you specify the PiHole IP address given when DHCP requests are answered. This will cause clients to make DNS requests to the PiHole.
Edited the nameserver to Quad9 as suggested. DNS on my router was Cloudflare if that matters.
I completely reimaged the SD card and debugging worked this time. Debug token prior to editing resolv.conf is cDR2Mgxx. After editing, debug token is BTM1oDPU. If that one doesn't work then maybe the 1 is a lowercase L?
Hi Butch, just trying to get things working client-side first before digging into router level, but appreciate the detail. That's what I had tried prior, though I was trying to run DHCP from the Pi Hole itself (and turned it off at the router level). Once I get things working client-side I'll try to make it network-wide and if I need to leave DHCP assignment on the router, that should be fine - I've heard any issues there are rare and less noticeable for the typical home user.
Your debug log shows that the Pi-hole is working normally. The output from the nlsookup is as expected - the client is using Pi-hole for DNS resolution (or was for at least that query).
Your router is the DHCP server, and it is passing out its own IP for DNS, rather than the Pi-hole IP.
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
Timeout: 10 seconds
* Received 300 bytes from wlan0:192.168.1.1
Offered IP address: 192.168.1.170
Server IP address: 192.168.1.1
Relay-agent IP address: N/A
BOOTP server: (empty)
BOOTP file: (empty)
DHCP options:
Message type: DHCPOFFER (2)
server-identifier: 192.168.1.1
lease-time: Infinite
netmask: 255.255.255.0
broadcast: 192.168.1.255
domain-name: "lan"
dns-server: 192.168.1.1
dns-server: 192.168.1.1
router: 192.168.1.1
--- end of options ---
DHCP packets received on interface lo: 0
DHCP packets received on interface wlan0: 1
Do you only see ads on certain browsers? If so, the browser might be using private DNS (DNS over https, typically) that would route browser DNS traffic around Pi-hole. This would be true even if the client OS is using Pi-hole for DNS.
Use the tools to determine where the ads are coming from, and to see if the DNS traffic from the client is even getting to Pi-hole.
Thanks for the link, it happens with multiple browsers. I've checked the DNS over https settings and updated them to point to the Pi Hole.
I did some random browsing around and in the logs I only see one reference to gravity, and that is Mozilla telemetry. I'm using these lists (green checkmarked): https://firebog.net/
Aug 29 13:30:05 dnsmasq[27615]: gravity blocked incoming.telemetry.mozilla.org is 0.0.0.0
In continuing to test I'm beginning to see some ads blocked (when comparing to Vanadium on GrapheneOS with no ad blocking extensions). Not sure what leaving it for half an hour did, but will continue to poke around and try to bring it to the router level if all looks good.
Perhaps, I was trying to be diligent about clearing/flushing any caches I could to get a true representation of what Pi Hole was doing but perhaps couldn't get them all. Thanks for all your help on this one - now to try to get it to the router level.
Previously my TP-Link router management software wouldn't assign a static IP outside the subnet, and then would not allow me to add a DNS server within the subnet, leaving me between a rock and a hard place as far as getting it to use the Pi Hole as the DNS server network wide.
Can give it a shot later though and make a separate post with the specific issue if I can't find anyone else who's tackled it.