Then the log file may just have been rotated.
Please try
zgrep rt-ac68u-1f10 -m 1 -B2 /var/log/pihole.log*
Unfortunately, the behavior is the same:
iosif@DNS-3:~$ zgrep rt-ac68u-1f10 -m 1 -B2 /var/log/pihole.log*
iosif@DNS-3:~$
Are there any log files at all?
ls -lah /var/log/pihole.log*
Yes, they are:
iosif@DNS-3:~$ ls -lah /var/log/pihole.log*
-rw-r--r-- 1 pihole pihole 746K Feb 21 13:22 /var/log/pihole.log
-rw-r--r-- 1 pihole pihole 8.1M Feb 21 10:32 /var/log/pihole.log.1
-rw-r--r-- 1 pihole pihole 15M Feb 21 00:00 /var/log/pihole.log.2.gz
-rw-r--r-- 1 pihole pihole 204K Feb 20 00:00 /var/log/pihole.log.3.gz
-rw-r--r-- 1 pihole pihole 141K Feb 19 09:42 /var/log/pihole.log.4.gz
-rw-r--r-- 1 pihole pihole 16M Feb 19 00:00 /var/log/pihole.log.5.gz
iosif@DNS-3:~$
Could be that I misspelled the name we search for.
It should be the very same as reported by the top-domains call.
Alternatively, you could try to find the matching lines by searching for your router's IPv6 instead (as reported by the top-clients call), but you may then have to look for just the lines involving your router's hostname.
Here it comes:
iosif@DNS-3:~$ zgrep fe80::aa5e:45ff:fe9b:1f10 -m 1 -B2 /var/log/pihole.log*
/var/log/pihole.log:Feb 21 10:41:23 dnsmasq[11168]: config 24.0.168.192.in-addr.arpa is <PTR>
/var/log/pihole.log:Feb 21 10:41:23 dnsmasq[11168]: query[PTR] 0.1.f.1.b.9.e.f.f.f.5.4.e.5.a.a.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa from 127.0.0.1
/var/log/pihole.log:Feb 21 10:41:23 dnsmasq[11168]: config fe80::aa5e:45ff:fe9b:1f10 is NXDOMAIN
/var/log/pihole.log.1:Feb 21 09:53:26 dnsmasq[8688]: query[PTR] 153.0.168.192.in-addr.arpa from 127.0.0.1
/var/log/pihole.log.1:Feb 21 09:53:27 dnsmasq[8688]: forwarded 153.0.168.192.in-addr.arpa to 192.168.0.1
/var/log/pihole.log.1:Feb 21 09:53:27 dnsmasq[8688]: query[PTR] 153.0.168.192.in-addr.arpa from fe80::aa5e:45ff:fe9b:1f10
/var/log/pihole.log.2.gz:Feb 20 00:47:57 dnsmasq[9125]: query[AAAA] 192-168-0-55.4c41cc7fdcec46beb87831f8566ada7f.plex.direct from 192.168.0.63
/var/log/pihole.log.2.gz:Feb 20 00:47:57 dnsmasq[9125]: cached 192-168-0-55.4c41cc7fdcec46beb87831f8566ada7f.plex.direct is NODATA-IPv6
/var/log/pihole.log.2.gz:Feb 20 00:48:03 dnsmasq[9125]: query[AAAA] edge-mqtt.facebook.com from fe80::aa5e:45ff:fe9b:1f10
/var/log/pihole.log.3.gz:Feb 19 09:43:21 dnsmasq[9125]: read /etc/pihole/custom.list - 0 addresses
/var/log/pihole.log.3.gz:Feb 19 09:43:21 dnsmasq[9125]: read /etc/pihole/local.list - 0 addresses
/var/log/pihole.log.3.gz:Feb 19 09:43:22 dnsmasq[9125]: query[A] p16-sign-va.tiktokcdn.com from fe80::aa5e:45ff:fe9b:1f10
/var/log/pihole.log.4.gz:Feb 19 00:01:02 dnsmasq[3520]: query[AAAA] auth.docker.io from 192.168.0.21
/var/log/pihole.log.4.gz:Feb 19 00:01:02 dnsmasq[3520]: cached auth.docker.io is NODATA-IPv6
/var/log/pihole.log.4.gz:Feb 19 00:01:03 dnsmasq[3520]: query[AAAA] outlook.office365.com from fe80::aa5e:45ff:fe9b:1f10
/var/log/pihole.log.5.gz:Feb 18 00:29:28 dnsmasq[349928]: forwarded youtubei.googleapis.com to 1.1.1.1
/var/log/pihole.log.5.gz:Feb 18 00:29:28 dnsmasq[349928]: reply youtubei.googleapis.com is 142.250.185.170
/var/log/pihole.log.5.gz:Feb 18 00:29:32 dnsmasq[349928]: query[A] connectivity-check.ubuntu.com from fe80::aa5e:45ff:fe9b:1f10
iosif@DNS-3:~$
iosif@DNS-3:~$ grep fe80::aa5e:45ff:fe9b:1f10 -m 1 -B2 /var/log/pihole.log
Feb 21 10:41:23 dnsmasq[11168]: config 24.0.168.192.in-addr.arpa is <PTR>
Feb 21 10:41:23 dnsmasq[11168]: query[PTR] 0.1.f.1.b.9.e.f.f.f.5.4.e.5.a.a.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa from 127.0.0.1
Feb 21 10:41:23 dnsmasq[11168]: config fe80::aa5e:45ff:fe9b:1f10 is NXDOMAIN
iosif@DNS-3:~$
That's a start, but you'd need to search differently here, as we'd still need the resolution logs for rt-ac68u-1f10 or whatever that is spelled correctly.
If you are not really familiar with grep and sed, it may be easier to use the correct spelling of the hostname instead.
If you can't establish what the correct name would be, you'd have to search for requests from that IPv6, e.g.:
grep -n -e "query\[A.* fe80::aa5e:45ff:fe9b:1f10" /var/log/pihole.log*
Note the file name and the line number of a matching entry.
You'd then have to narrow down that list to requests for that rt-ac68u-1f10 hostname by looking at the corresponding lines after that line number, e.g. for a hit in line number 1000 in pihole.log.1:
sed -n '1000,1010p;1011q' /var/log/pihole.log.1
So this morning I woke up and found the below errors in the PiHole interface:
Disk shortage (/var/log/pihole-FTL.log) ahead: 99% used
/var/log: 33.0GB used, 33.1GB total
Disk shortage (/etc/pihole/pihole-FTL.db) ahead: 99% used
/etc/pihole: 33.0GB used, 33.1GB total
So I used the commands from yesterday to make a backup of the FTL db and then I delete it:
sudo service pihole-FTL stop
sudo mv /etc/pihole/pihole-FTL.db /etc/pihole/pihole-FTL-old.db
sudo reboot now
sudo rm /etc/pihole/pihole-FTL-old.db
Here is a fresh debug token. How is my config now?
Thanks.
LE: The interface looks weird:
In the total queries I see only green although I see that there were some blocked ads (12.8%)
Your debug log shows that you seem to have allocated more memory and disk space to your VM and you still have enabled Conditional Forwarding.
Increasing your VM resources will not alleviate your issue (it may only make it occur less often, perhaps).
Your issue is an excessive amount of DNS queries, caused by either a partial DNS loop closed by CF or by a misbehaving client.
Your previous top-domain and top-client API call results make the former more likely.
Keep Conditional Forwarding disabled for now and see if this solves your issue.
Your debug log also shows that your router is distributing its own IP as DNS server via DHCP in addition to Pi-hole:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
* Received 300 bytes from eth0:192.168.0.1
Offered IP address: 192.168.0.24
DHCP options:
dns-server: 192.168.0.24
dns-server: 192.168.0.1
router: 192.168.0.1
This will allow clients to by-pass your Pi-hole.
Pi-hole has to be your only DNS server for your clients.
Hey there,
I didn't touched the CF since yesterday. This is what I see in the GUI:
The Asus routers are famous for insisting to advertise their own IP address as a DNS unfortunately.
Also, Ubuntu OS seems to see the HDD as yesterday (34GB), weird that Pihole sees it but Ubuntu doesn't.
My mistake - I may have mixed up your debug logs when comparing for differences.
That would exclude a CF induced DNS loop from causing your issue, making client behaviour the next suspect.
What does your router return when queried for a name for its IPv4 and IPv6 address?
nslookup 192.168.0.1 192.168.0.1
nslookup fe80::aa5e:45ff:fe9b:1f10 192.168.0.1
They shouldn't trigger any corresponding PTR requests to Pi-hole, but please also watch Pi-hole's Query Log when running those commands.
It seems that PiHole didn't displayed anything related to this:
Both commands were issued from 192.168.0.55
LE: By following this link I was able to replace my second DNS (the one that is not accessible through the router's interface) with the Cloudflare one (just so that I have a backup in case something goes terrible wrong with my PiHole).
That's good.
It could be that the capitals thwarted our earlier grep attempts.
Could you try to run
zgrep RT-AC68U-1F10 -m 1 -B2 /var/log/pihole.log*
Also, if you rerun the top-clients and top-domains calls, would they still return your router's IP and its name as top entries?
This morning I didn't find any diagnostic messages, but I've found that the DNS was down since yesterday. Basically I've had a hole from midnight until this morning when PiHole didn't worked at all.
I solved it with restartdns without issues:
$ pihole restartdns
[sudo] password for iosif:
[✓] Restarting DNS server
$
Fresh debug log: https://tricorder.pi-hole.net/8LeIWsGl/
$ zgrep RT-AC68U-1F10 -m 1 -B2 /var/log/pihole.log*
/var/log/pihole.log.3.gz:Feb 21 10:41:23 dnsmasq[11168]: query[PTR] 1.0.168.192.in-addr.arpa from 127.0.0.1
/var/log/pihole.log.3.gz:Feb 21 10:41:23 dnsmasq[11168]: forwarded 1.0.168.192.in-addr.arpa to 192.168.0.1
/var/log/pihole.log.3.gz:Feb 21 10:41:23 dnsmasq[11168]: reply 192.168.0.1 is RT-AC68U-1F10
/var/log/pihole.log.4.gz:Feb 21 09:53:27 dnsmasq[8688]: query[PTR] 153.0.168.192.in-addr.arpa from fe80::aa5e:45ff:fe9b:1f10
/var/log/pihole.log.4.gz:Feb 21 09:53:27 dnsmasq[8688]: forwarded 153.0.168.192.in-addr.arpa to 192.168.0.1
/var/log/pihole.log.4.gz:Feb 21 09:53:27 dnsmasq[8688]: reply 192.168.0.1 is RT-AC68U-1F10
/var/log/pihole.log.5.gz:Feb 20 01:00:00 dnsmasq[9125]: query[PTR] 1.0.168.192.in-addr.arpa from 127.0.0.1
/var/log/pihole.log.5.gz:Feb 20 01:00:00 dnsmasq[9125]: forwarded 1.0.168.192.in-addr.arpa to 192.168.0.1
/var/log/pihole.log.5.gz:Feb 20 01:00:00 dnsmasq[9125]: reply 192.168.0.1 is RT-AC68U-1F10
Stats:
$ echo ">stats >quit" | nc localhost 4711
domains_being_blocked 1297740
dns_queries_today 23513
ads_blocked_today 831
ads_percentage_today 3.534215
unique_domains 1285
queries_forwarded 8176
queries_cached 14480
clients_ever_seen 25
unique_clients 24
dns_queries_all_types 23513
reply_NODATA 3386
reply_NXDOMAIN 283
reply_CNAME 666
reply_IP 873
privacy_level 0
status enabled
Top Clients:
~$ echo ">top-clients >quit" | nc localhost 4711
0 13026 192.168.0.21
1 2935 192.168.0.55
2 1970 192.168.0.63
3 1637 192.168.0.212
4 981 192.168.0.19
5 951 192.168.0.9
6 892 192.168.0.24 pi.hole
7 390 fe80::aa5e:45ff:fe9b:1f10
8 268 192.168.0.90
9 254 127.0.0.1 localhost
Top Domains:
$ echo ">top-domains >quit" | nc localhost 4711
0 3882 registry-1.docker.io
1 2036 daisy.ubuntu.com
2 1998 auth.docker.io
3 1963 192-168-0-55.4c41cc7fdcec46beb87831f8566ada7f.plex.direct
4 1569 api.snapcraft.io
5 795 connectivity-check.ubuntu.com
6 620 www.google.com
7 564 ghcr.io
8 406 api.intelsa.intel.com
9 263 55.0.168.192.in-addr.arpa
@Bucking_Horn I believe that now I have an IPv6 issue on my hands. I did a test on https://www.test-ipv6.ro/ and I got a red message saying "Our tests show that you will have a broken or misconfigured IPv6 setup, and this will cause problems as web sites enable IPv6."
How can I troubleshoot this?
Thanks.
Your current telnet API stats look normal.
Did you perhaps run those after clearing your pihole-FTL.db?
They wouldn't contain the potentially offending domains and clients then.
Your zgrep results show that your router's excessive requests for its own name seem to have ceased after about February 21st, which could be about the time when you've disabled CF.
This would still allow your clients to by-pass your Pi-hole (via Cloudflare this time).
As mentioned:
Ok, let's take it one step at a time.
Yes, my router stopped being chatty since I disabled CF and yes, I cleared the FRL.db that day due to space issues. So now I have fresh stuff there.
I replaced the second DNS server on my router with Cloudflare (instead of the router's IP address) thinking that this should provide me with a backup solution in case PiHole stops working (for various reasons). Like for example yesterday morning Pihole stopped working although the VM was ok (restartdns solved the issue).
The idea is that in case PiHole misbehaves I do not want for my entire network to have issues until I fix it (my wife and daughter would kill me).
What about IPv6? I tried to follow all the guides and post I've found on this topic but I still can't seem to find the culprit. Must be something between my Router and PiHole or a little bit on both.
Many thanks for your help.
That may be sound while you sort your issues.
Just keep in mind that it is not a backup - your clients are free to pick any DNS server they are aware of for any individual DNS request at their own discretion. Pi-hole will be by-passed if it isn't the only DNS server.
In that case, it may be better to continue this as a separate topic, so we could mark this one as solved.
Your public IPv6 connectivity would be outside of Pi-hole's scope.
Pi-hole could be only involved here if it would block any domains that the tesing website would try to access, in which case How do I determine what domain an ad is coming from? could help to identify those domains.
For the moment everything seems stable enough with my little PiHole VM. Hence, I marked your post with "Disable CF" as the Solution.
Any chance there is a workaround for that CF? I keep forgetting which IP is for each host when I look through the Dashboard.
Many thanks.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.