Google ads not blocked on Pi-hole

Please follow the below template, it will help us to help you!

If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.

Expected Behaviour:

Google ads blocked

Actual Behaviour:

Google ads shown? Error message of "[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)" when verifying "Name resolution (IPv6) using a random blocked domain and a known ad-serving domain"

Debug Token:

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

In case you are just worried about that specific failure, that is not an issue:
That would just indicate that your Pi-hole wasn't able to request DNS resolution through a public DNS resolver via IPv6.

In conjunction with your debug log's Network interfaces and addresses section, this would indicate that your network has link-local IPv6 connectivity only.

By itself, this has no bearing on Pi-hole's filtering operaton - forwarding to Pi-hole's upstreams only occurs after filtering, for allowed domains.

Okay, then it must be a different issue as google ads are not being blocked. Any idea what the actual problem could be?

Run from a client in your network that is showing ads where you expect it should not, what is the output of the following commands:

nslookup pi.hole
nslookup flurry.com

Server: pi.hole
Address: 192.168.50.212

Name: pi.hole
Addresses: fe80::3727:bb73:22c2:4485
192.168.50.212

Server: pi.hole
Address: 192.168.50.212

Name: flurry.com
Addresses: ::
0.0.0.0

That client has correctly been using your Pi-hole for DNS, at least for those two requests.

Just to be sure:
Run from the same client, please share the DNS server section from the following command's output:

ipconfig /all

DNS Servers . . . . . . . . . . . : 192.168.50.212
8.8.8.8

I just tried to remove 8.8.8.8 as a backup dns and it seems like it's the only one my pc is using because the pihole dns isn't working. When I made it the only dns for my pc, I got a message saying "Maximum number of concurrent DNS queries reached (max: 150)" in pihole tools. Any ideas why it might not be working?

Pi-hole can't block the sponsored ads on Google showing up in the search results. They are served from the same domain as the search results. However, if you click on such an ad link it should not open the page.

If you want to hide the ads you need a brower based adblocker.

That's a good idea - clients would by-pass Pi-hole via 8.8.8.8 otherwise.
Pi-hole has to be the sole DNS server for your clients.

Usually, that is caused by a DNS loop, where at least one of Pi-hole's upstreams would send DNS queries back to Pi-hole which again forwards them to the upstream, and so forth, forever or until time-out.
Less commonly, Pi-hole is flooded by an excessive amounts of DNS requests from particular clients desperate for resolving a domain.

It seems you are intending to use unbound as Pi-hole's upstream?
If so, you probably may be affected by both.

Your debug log shows you have configured your Pi-hole for a sole upstream at 127.0.0.1:

*** [ DIAGNOSING ]: Setup variables
    PIHOLE_DNS_1=127.0.0.1#5335

However, your debug log's Ports in use section shows there is no process listening on 127.0.0.1#5335.
That would also explain why Pi-hole is starving on forwards:

*** [ DIAGNOSING ]: Pi-hole log

-rw-r----- 1 pihole pihole 242K Apr  9 13:36 /var/log/pihole/pihole.log
   -----head of pihole.log------
   Apr  9 00:00:05 dnsmasq[257638]: query[HTTPS] iphone-ld.apple.com from 192.168.50.157
   Apr  9 00:00:05 dnsmasq[257638]: forwarded iphone-ld.apple.com to 127.0.0.1#5335
   Apr  9 00:00:05 dnsmasq[257638]: query[A] iphone-ld.apple.com from 192.168.50.157
   Apr  9 00:00:05 dnsmasq[257638]: forwarded iphone-ld.apple.com to 127.0.0.1#5335
   Apr  9 00:00:05 dnsmasq[257638]: query[SVCB] _dns.resolver.arpa from 192.168.50.157
   Apr  9 00:00:05 dnsmasq[257638]: forwarded _dns.resolver.arpa to 127.0.0.1#5335
   Apr  9 00:00:07 dnsmasq[257638]: query[A] iphone-ld.apple.com from 192.168.50.157
   Apr  9 00:00:07 dnsmasq[257638]: forwarded iphone-ld.apple.com to 127.0.0.1#5335
   Apr  9 00:00:07 dnsmasq[257638]: query[HTTPS] iphone-ld.apple.com from 192.168.50.157
   Apr  9 00:00:07 dnsmasq[257638]: forwarded iphone-ld.apple.com to 127.0.0.1#5335
   Apr  9 00:00:07 dnsmasq[257638]: query[SVCB] _dns.resolver.arpa from 192.168.50.157
   Apr  9 00:00:07 dnsmasq[257638]: forwarded _dns.resolver.arpa to 127.0.0.1#5335

If you intend to use unbound as Pi-hole's upstream DNS server, you'd have to find out why it would not be running. In case you aren't already aware of it, you may also refer to our guide on unbound.

Try:

sudo service unbound restart

and verify by running:

dig dnssec.works @127.0.0.1 -p 5335

In the meantime, you may tick one of Pi-hole's public Upstream DNS Servers to allow forwards to succeed, in order to re-enable full DNS resolution for your clients.

It isn't blocking google play ads on websites, I know it can't block sponsored search results.

I got this as a result of the second command:

; <<>> DiG 9.16.37-Debian <<>> dnssec.work @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16836
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dnssec.work.                   IN      A

;; AUTHORITY SECTION:
work.                   900     IN      SOA     a.nic.work. admin.tldns.godadd 1681175813 1800 300 604800 1800

;; Query time: 116 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Mon Apr 10 21:23:05 EDT 2023
;; MSG SIZE  rcvd: 101

Typo, maybe? Your dig query showed "dnssec.work" but the command per @Bucking_Horn should have been:

dig dnssec.works @127.0.0.1 -p 5335
1 Like

that's definitely possible... I thought I copied and pasted it, but maybe I didn't. I'll try again when I can access my pi again.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.