Soo. Strange behaviour here.
My Pi-Hole is running on Proxmox (mini PC with intel CPU). Normal queries during 24 hours likely 25.000.
There was a log delete yesterday so there were only the approx. 25.000 entries.
This morning my Proxmox server warned me, that the disk is full and Pi-Hole said over 2GB in log files.
Pi-Hole couldn't load the web GUI properly but i saw 40 million queries.
WTF?! Thats 55k per minute for approx. 6 hours, twice as much as a whole day
I couldn't see any entries because nothing was working until i deleted the log file.
Question: What can lead to this amount in such a short time?
Running:
Pi-hole [v5.15]
FTL [v5.20.1]
Web Interface [v5.18.1]
pihole_debug.zip (9.8 KB)
Here you go. And no, 53 is not accesible. Only 80,443,5613 and passive FTP ports. And all these are forwarded to my NAS and not the Proxmox-Server (Pi-Hole especially)
Hm... my router is 192.168.1.1 and its DNS is both (1st and 2nd) 192.168.1.29 (Pi-Hole)
So my clients are routed to my router and from there to Pi-Hole.
The router is my DHCP server with several static IPs and the rest dynamic.
I've activated conditional forwarding due to this statement:
"If not configured as your DHCP server, Pi-hole typically won't be able to determine the names of devices on your local network. As a result, tables such as Top Clients will only show IP addresses."
But I'm not seeing an overall loop, every querie shows up exactly once or - if more often - with a more elapsed time (15 seconds). For a loop, the time stamps would be more like the same seconds but different ms, or am I wrong?
FYI: all the dns.msftncsi.com are single requests from the ASUS router. I will deactivate this later. It's not a loop.
Right now after 5 hours of operation, Pi-Hole has recorded 13.602 queries. After 24 hours it should be somewhere around 65.000. But not 40 Million over night.
No, your clients are talking to directly to PI-hole for DNS, as your router's DHCP server is telling them to:
*** [ DIAGNOSING ]:e[0m Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
* Received 315 bytes from eth0:192.168.1.1
Offered IP address: 192.168.1.29
DHCP options:
Message type: DHCPOFFER (2)
dns-server: 192.168.1.29
dns-server: 192.168.1.29
router: 192.168.1.1
--- end of options ---
PromoFaux asked about the DNS server that your router itself is using as upstream DNS. Commonly, that is a WAN/Internet setting in your router.
Conditional Forwarding may cause a partial loop if your router would be using Pi-hole as its upstream.
If that would be the case, you should be able to trigger it by requesting resolution of a non-existent local hostname, e.g. nslookup bogus-hostname. If that request would be looping, it would become rate-limited by Pi-hole (if you'd reverted your Pi-hole's rate-limit setting), and it should show up in Pi-hole's diagnosis pane as well.
Let me try the nslookup when I'm back home.
The router is using Pi-Hole as DNS but the upstream (Gateway) comes from my ISP.
Let's say my current WAN IP is 1.2.3.100, then the gateway is 1.2.3.254. That's something I can't edit.
That could well be the case, but you may want verify that via your router.
The screenshot you've shared above quite likely shows your router's DHCP server DNS configuration, as the information (double .129) nicely aligns with your DHCP server's response I've quoted above from your debug log.
I'd expect the DNS servers that your router itself would be using to be shown on a different screen, commonly a WAN/Internet setting.
I can only see the ISP's gateway in LAN/WAN settings and the DHCP DNS.
LAN gateway is my router: 192.168.1.1 (changeable)
DNS is 192.168.1.29 (Pi-Hole, changeable)
Upstream Link is 31.xx.xx.254 (gateway from ISP and not changeable by me)
WAN IP is 31.xx.xx.146 (provided by ISP, non static and not changeable)
Right now im a little bit confused. The requests go to Pi-Hole and Pi-Hole itself uses Cloudflare.
Even the router is using Pi-Hole (seen in the log files) and therefore everything goes via Cloudflare.
These show apparently normal traffic volume - nothing close to 40 million entries. This information is taken from the query database at /etc/pihole/pihole-FTL.db.
What log file did you delete? The query database? The dnsmasq log at /var/log/pihole/pihole.log?
C:\Windows\system32>nslookup 192.168.1.222
Server: pi.hole
Address: 192.168.1.29
*** 192.168.1.222 wurde von pi.hole nicht gefunden: Non-existent domain.
C:\Windows\system32>nslookup https://www.gagle.de/
Server: pi.hole
Address: 192.168.1.29
*** https://www.gagle.de/ wurde von pi.hole nicht gefunden: Non-existent domain.
C:\Windows\system32>
and
C:\Windows\system32>tracert -d www.firebog.net
Routenverfolgung zu www.firebog.net [104.21.76.113]
über maximal 30 Hops:
1 2 ms 2 ms 2 ms 192.168.1.1
2 20 ms 47 ms 17 ms 31.16.10.252
3 19 ms 17 ms 18 ms 83.169.174.130
4 19 ms 18 ms 17 ms 145.254.3.128
5 26 ms 27 ms 26 ms 145.254.2.195
6 * 27 ms * 80.81.194.180
7 30 ms 29 ms 26 ms 162.158.84.53
8 29 ms 27 ms 27 ms 104.21.76.113
Ablaufverfolgung beendet.
whereas 31.16.10.254 is my gateway. So Hop 1 is my router, Pi-Hole shows the request
The pihole-FTL.db was over 2GB. And my VM was full so nothing worked anymore.
I will observe this topic. Maybe there was a problem with Proxmox or my ISP had some issues.
Does that mean that your router is using yor Pi-hole as upstream DNS server?
Your following statement would suggest that:
When Conditional Forwarding is enabled, this would close aforementioned partial DNS loop.
None of your commands matches the one that I've suggested.
To trigger the loop, the query has to take its path to your router (via CF), and your router has to lack information about the requested domain, so that it would forward that query to its upstream (i.e. back to your Pi-hole, if your router is using Pi-hole as upstream).
A query for an unknown plain hostname, or an unknown qualified hostname matching your CF's local domain name may trigger it.
According to your debug log, that would suggest something like:
nslookup unknown.nanotekdynamic
Please share the respective log lines from /var/log/pihole/pihole.log, or from monitoring Tools|Tail pihole.log during that nslookup.
Jan 18 18:31:49 dnsmasq[267]: query[PTR] lb._dns-sd._udp.104.89.70.100.in-addr.arpa from 192.168.1.95
Jan 18 18:31:49 dnsmasq[267]: forwarded lb._dns-sd._udp.104.89.70.100.in-addr.arpa to 1.1.1.1
Jan 18 18:31:49 dnsmasq[267]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.95
Jan 18 18:31:49 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
Jan 18 18:31:49 dnsmasq[267]: query[PTR] lb._dns-sd._udp.RT-AC87u from 192.168.1.95
Jan 18 18:31:49 dnsmasq[267]: forwarded lb._dns-sd._udp.RT-AC87u to 1.1.1.1
Jan 18 18:31:49 dnsmasq[267]: reply lb._dns-sd._udp.104.89.70.100.in-addr.arpa is NXDOMAIN
Jan 18 18:31:49 dnsmasq[267]: reply lb._dns-sd._udp.RT-AC87u is NXDOMAIN
[...]
Jan 18 19:09:15 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
Jan 18 19:09:15 dnsmasq[267]: exiting on receipt of SIGTERM
My file is over 2GB again and Pi-Hole says:
There was a problem applying your settings.
Debugging information:
PHP error (2): fsockopen(): Unable to connect to 127.0.0.1:4711 (Connection refused) in /var/www/html/admin/scripts/pi-hole/php/FTL.php:47
There's your loop, initiated by 192.168.1.95, and then forwarded from Pi-hole to your router to Pi-hole to your router...:
Jan 18 18:31:49 dnsmasq[267]: query[PTR] lb._dns-sd._udp.RT-AC87u from 192.168.1.95
Jan 18 19:09:15 dnsmasq[267]: forwarded lb._dns-sd._udp.0.1.168.192.in-addr.arpa to 192.168.1.1
--------------
Jan 18 19:09:15 dnsmasq[267]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.1
----------------
If you'd put the rate-limit back in, those queries would have been cut at a few hundreds.
To address this, you should consider to remove Pi-hole from your router's upstream DNS server configuration.