The issue I am facing:
Today while I was browsing some sites I've noticed there were a lot of ads, which seemed strange (noticed this a few days ago, but ignored it)
When I logged in my pi, I noticed the blocking rate was very low (2.6%) and in past the numbers were much higher > 35%
Details about my system:
What I have changed since installing Pi-hole:
Upgraded a few time, no changes in list (besides the usual updates)
What can be impacting this?
https://tricorder.pi-hole.net/i4CMvNzg/
Thanks
Percentage blocked is primarily driven by your clients and their DNS activity.
If clients repeatedly request domains that are not blocked, that drives the rate down. An example would be spending a lot of time every day on pi-hole.net, which should contain no blocked domains.
Alternatively, if you frequently visit commercial websites that are chock full of ads (cnn.com, dailymail.uk, etc), your percentage blocked will go right up.
If you have clients that repeatedly request a blocked domain (IOT devices are frequent offenders), that can also quickly drive up your percentage blocked.
This would indicate that either the ads cannot be blocked by Pi-hole (they are served from the same domains as the content), or the client is not using Pi-hole for DNS. You could also be using a browser with secure or private browsing enabled, which sneds DNS traffic to a DNS other than Pi-hole.
These tools can help you determine the source of ads:
You can also see which DNS server a client is using with these commands:
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
In your specific case, you have IP's on two separate interfaces, and the IP's are on different private IP ranges:
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] ddi.msc-net.co.jp is 0.0.0.0 on lo (127.0.0.1)
[✓] ddi.msc-net.co.jp is 0.0.0.0 on enx002427fe4ab6 (192.168.0.92)
[✓] ddi.msc-net.co.jp is 0.0.0.0 on wlan0 (192.168.14.92)
[✓] doubleclick.com is 172.217.168.174 via a remote, public DNS server (8.8.8.8)
Pi-hole is configured for the ethernet connection:
PIHOLE_INTERFACE=enx002427fe4ab6
You have two DHCP servers operating on your network, and it doesn't appear that either is passing the IP of Pi-hole as DNS server:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
Timeout: 10 seconds
* Received 300 bytes from enx002427fe4ab6:192.168.0.101
Offered IP address: 192.168.0.117
Server IP address: 192.168.0.101
Relay-agent IP address: N/A
BOOTP server: (empty)
BOOTP file: (empty)
DHCP options:
Message type: DHCPOFFER (2)
lease-time: 14400 ( 4h )
server-identifier: 192.168.0.101
--- end of options ---
* Received 300 bytes from wlan0:192.168.14.1
Offered IP address: 192.168.14.220
Server IP address: 192.168.14.1
Relay-agent IP address: N/A
BOOTP server: (empty)
BOOTP file: (empty)
DHCP options:
Message type: DHCPOFFER (2)
lease-time: 14400 ( 4h )
server-identifier: 192.168.14.1
--- end of options ---
DHCP packets received on interface lo: 0
DHCP packets received on interface wlan0: 1
DHCP packets received on interface enx002427fe4ab6: 1
There are a lot of things impacting the blocked percentage:
There is nothing wrong if the percentage changes. You probably are seeing a combination of all of the possibilities above.
Note:
If you are seeing more ads, then you should use the tools recommended by jfb above.
I understand all of that, but the thing is that the block rate is now 10x (at least) lower and there were no changes in the browsing patterns.
Something must have changed, but I can't put the finger on it (plus the perception I'm seeing more ads as usual
Although I haven't blocked DOH at the firewall, i'm not aware of any client doing it.
That is ok, that is my router which then uses pi-hole anyway.
I didn noticed something, I have a process running 24/7 that is querying one my IoT local devices (1 req per second), and pi-hole shows a very high number of queries for that domain (tailing the logs I see a resolution per second for that name.
Currently I have 144914 queries today for which 76774 are for that name.
I've found this odd (should local domains be even accounted? (they are using Conditional forwarding) is there a way to ignore local domains?
Upon more investigation (the DNS for local domain is not the pi-hole) the TTL for this name is 1 day and yet pi is returning a 0s TTL.
So no wonder pi is getting pounded with that query.
Is there any way for pie to respect the TTL for local domains? Those can be perfectly cached
dig shows
Blockquote
;; ANSWER SECTION:
shelly-meter.local. 0s IN A 192.168.0.216
I have configured pi DNS for this particular host and it still returns a 0S TTL
The ODD thing is that for other hosts in the local domain have a much higher TTL, what makes this host special?
Thanks for the tips
All of the above are more or less the same. Same number of devices, same browsing patterns, no new ad lists (added by my that is)
a 10x decrease in block rates it's very very odd
Mine varied today from 2.8% blocked this morning to 21.4% blocked by this afternoon. One of the things that caused that was a single Windows 10 machine booting up and then doing its usual microsoft telemetry hammering which is all blocked. A single IoT type device could similarly account for such a change. Up and down 10x is normal here.
On the main dashboard you can see blocked vs permitted queries in the top graph, and if you click part of that graph it takes you to the queries from that time, and you'll be able to see the difference in what's generating these during the times of higher blocking vs lower blocking.
My Pi hole on a dedicated Pi shows between 10 and 40% blocked items depending of what my wife reads ,
The Pi should have one IPv4 and one IPv6 address notified in the router configuration.
Both IPv4 DNS servers should carry the Pi address.
So one for the Ethernet and one for wifi interface creates nonsense.
Also the missing ipv6 Pi address in router configuration opens a second path for advertisements which you try to avoid.
The admins here could help you analysing the misconfiguration by posting a debug log.
Pi-hole (your pie?) will do so automatically.
This:
pihole_FTL/dnsmasq's TTL for local DNS records that have been created within Pi-hole will be set to 0 by default, as that would allow local changes to propagate immediately:
-T, --local-ttl=<time>
When replying with information from /etc/hosts or configuration or the DHCP leases file dnsmasq by default sets the time-to-live field to zero, meaning that the requester should not itself cache the information. This is the correct thing to do in almost all situations. This option allows a time-to-live (in seconds) to be given for these replies. This will reduce the load on the server at the expense of clients using stale data under some circumstances.
To change that, you could consider adding a custom configuration file with a specific TTL value.
But .local domains shouldn't show up in DNS at all:
The .local TLD is reserved for mDNS usage and should NOT be used with plain DNS.
Maybe that's was causing your observation:
A single excessive query for a non-blocked domain would drive the relative blocked percentage substantially lower, even while the absolute number of blocked requests would stay about the same.
Ah that was it.... Thank you
Now I need to understand why python is ignoring the TTL. I guess it's because it's using pi-hole as the caching server (the scripts execute on same machine as the pie)
Yes. I'm aware of that... But after I realized, I was so much deep in it, changing it would be a pain (but it's on my todo list)
But assuming they are used (well not assuming. They are used) should be not counted for stats nor the in top permitted domains?
But even if I change the domain, they will still be accounted in the stats so what not using local change anything?
That is not it, since that behavior is there for years and years. the high number of calls for my local domain has this pattern.
I've tried to ignore both *.local as well client 127.0.0.1 in setings->api/web interface and now the local domain no longer shows in the top domain list (nice), however those queries are still being accounted in the total queries...
Is it case the case, the counters are not recounted to eliminate the ignored domain?, so I will have to wait until tomorrow? (That is perfectly fine by me)
I can still see the queries in the logs (but I think that is expected)
That is not a problem, since my non pie caching DNS all point to the pie anyway.
IPV6 is disabled on my network.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.
