well that didn't happen obviously. the connection to my Raspberry Pi, be it SSH or the Pi-hole interface is slow. and half the times when I try to open another page the DNS doesn't resolve anything. the request doesn't even show up in Tail pihole.log. I'm getting warnings about long load times and that the CPU load on the raspberry pi is high.
I'm pretty much a noob with raspberry pi so any help would be appreciated because I'm plainly stumped on this.
Your debug log shows that your query database has some problems:
-rw-r--r-- 1 pihole pihole 4.2K Nov 3 03:38 /var/log/pihole/FTL.log
-----head of FTL.log------
[2022-11-03 03:00:01.125 4452/T4470] SQLite3 message: database is locked in "SELECT name FROM network_addresses WHERE name IS NOT NULL AND ip = ?;" (5)
[2022-11-03 03:00:01.125 4452/T4470] getNameFromIP("192.168.1.21") - SQL error prepare: database is locked
You can try to fix this with the following:
Run these commands to move the existing database to a new file name and create a fresh database.
sudo service pihole-FTL stop
sudo mv /etc/pihole/pihole-FTL.db /etc/pihole/pihole-FTL-old.db
sudo service pihole-FTL start
The rest of your debug log is normal and shows that Pi-hole is receiving queries from network clients and is properly resolving them:
-----tail of pihole.log------
Nov 3 03:37:48 dnsmasq[4452]: query[A] api.dropboxapi.com from 192.168.1.8
Nov 3 03:37:48 dnsmasq[4452]: forwarded api.dropboxapi.com to 8.8.8.8
Nov 3 03:37:48 dnsmasq[4452]: forwarded api.dropboxapi.com to 8.8.4.4
Nov 3 03:37:48 dnsmasq[4452]: reply api.dropboxapi.com is <CNAME>
Nov 3 03:37:48 dnsmasq[4452]: reply api.dropbox.com is <CNAME>
Nov 3 03:37:48 dnsmasq[4452]: reply api-env.dropbox-dns.com is 162.125.65.19
This is a very good indicator that the client is using a different DNS than Pi-hole.
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
Thanks for the quick reply JFB, so 192.168.1.8 is my PC.
even in my PC's network adaptor, it says that my DNS is raspberry pi that's running Pi-hole (192.168.1.9)
I did the commands to create a fresh database
and ran the different nslookup's, here is the results:
C:\WINDOWS\system32>nslookup pi.hole
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.1.9
DNS request timed out.
timeout was 2 seconds.
Name: pi.hole
Addresses: fe80::f196:2503:f70e:1815
192.168.1.9
The time-out you saw there happens intermittently. An this is also the time that the DNS request won't show up on the tail log.
Side note, I noticed that my Raspberry Pi, aside from eth0 connection also has a lo connection. this lo is just a loopback to 127.0.0.1 no idea what its doing or what its there for but could that be a reason as to why the whole thing is running so slow?
This part of the debug log hasn't changed since I've been using Pi-hole:
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] d1dqhap8oaa6aodwplsa.qwo231sdx.club is 0.0.0.0 on lo (127.0.0.1)
[✓] d1dqhap8oaa6aodwplsa.qwo231sdx.club is 0.0.0.0 on eth0 (192.168.1.9)
[✓] doubleclick.com is 216.58.208.110 via a remote, public DNS server (8.8.8.8)
Locking up and failing to respond to queries. the DNS resolve is slow to where it takes a while to start receiving a page. (850 Mbps up and down connection) and quite often the pages fail to load and a "failed to resolve DNS" message popping up in my browser. (Opera GX)
Not sure what to look for in syslog so here it is attached. syslog.txt (627.1 KB)
Its weird though, the Pihole UI will report a high load, by showing the load dot being red. but none of the cores are ever above 10% according to Htop..
While that nslookup ultimately returns the correct answer, the initial timeout and the failure to correctly determine the name of the DNS server used are suspicious. Instead of Server: UnKnown, it should of course have read pi.hole.
This may hint at something interfering with DNS traffiic, either locally on that client, or maybe your router is somehow redirecting DNS traffic.
But before you start troubleshooting, you should probably reconsider your method of installation:
That's probably not a good idea - that script seems to be some 4 years old, and taking only a short glance at the GitHub source, it would seem that it pulls packages from Raspbian Stretch repositories. That OS release has reached EOL in June 2022, and consequently, Pi-hole has dropped support for it.
I can't tell whether including those repos would still be justified 4 years later for some reason, or if they would have a detrimental effect on Pi-hole, but I'd recommend to use a current Raspberry Pi OS release and forego using that script, or contact that script's maintainer for further details.
Well in my router I've configured the Raspberry Pi to have a static IP via its mac address. and I've told the router that the standard DNS is the Raspberry Pi's IP that I've made static. which is why I'm reasonably sure that it isn't the networking that's the issue
The DNS traffic literally can't go anywhere else unless I set the DNS manually on my PC's IPv4 network adaptor setting.
I didn't follow that guide completely. I used Raspberry Pi Imager V1.7.3 to install the latest release of Raspberry Pi OS Lite (2022-09-22)
then I just ran this command wget "https://github.com/SmokingCrop/UniFi/raw/master/install-unifi-pihole-English.sh" -O install-unifi-pihole.sh && chmod +x install-unifi-pihole.sh && ./install-unifi-pihole.sh
which is what I did on the previous install I had.
The only difference being a newer version of the Raspberry Pi OS, but maybe that's the issue?
if you think its worth a shot for me to scrap the current install and start over fresh manually for the source websites, let me know.
It is that very script that my earlier comment refers to:
Mixing repos may have unwanted side effects if for some reason an older version of a software package gets installed than your current OS release would suggest or require.
I cannot know whether this would be the case with that specific script - the orginal creator of that script may be able to provide further details.
Sorry, I can't really advise one way or the other, as I am not familiar with that script and its rationale for including those outdated Stretch repositories.
You may want to consider consulting the script's maintainer on this matter, e.g. by opening an issue within their GitHub repository for their script.
And yet you observe that your Pi-hole sometimes doesn't get DNS requests.
Any piece of software on a client may decide to ignore your machine's settings and send DNS requests to an arbitrary DNS server, even using different means than plain DNS. Common occurences would include Smartphones using hardcoded DNS servers, browsers using DoH, antivirus software redirecting DNS traffic to their manufacturers, or you requesting nslookup to resolve a domain through a public DNS server.
Your 5UwDKYIe debug log shows you've configured your router's DHCP server to distribute Pi-hole's IPv4 as local DNS server (and this would be the preferred configuration for IPv4).
But for IPv6, your debug log also shows your network to have link-local IPv6 connectivity, but your Pi-hole isn't able to receive respective traffic:
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve www.viaisvcaeeesvi.vscveeaaavs.gjdfei.top on lo (::1)
[✗] Failed to resolve www.viaisvcaeeesvi.vscveeaaavs.gjdfei.top on eth0 (fe80::f196:2503:f70e:1815)
Assuming that your router is configured to distribute Pi-hole's IPv6 as local DNS server via NDP/RA, that may mean that IPv6 capable clients would first fail on attempting DNS resolution via that link-local address (fe80::...) before falling back to using your Pi-hole host's 192.168.1.9 IPv4.
To preclude a firewall issue, please verify that Pi-hole's required ports are accessible via IPv4 and IPv6 alike.
Right, I did try to use the Pi-hole as my DHCP server but I noticed that the Wifi adaptor would ignore that so my smartphone's DNS traffic didn't go through Pihole. so I switched the Pi-hole DHCP off and made my network router just route DNS.
Oh shit I forgot to setup the IPv6 upstream DNS, fixed that now. Still I doubt that's a reason for the unresponsiveness and high loads.
You didn't forget anything then:
Adding another upstream DNS server (IPv4 or IPv6 regardless) in Pi-hole's Settings | DNS has absolutely no bearing on your issue.
It is not required to have an IPv6 upstream for Pi-hole to be able to correctly resolve AAAA requests for IPv6 addresses - any upstream will do so, regardless of the transport protocol used.
My advice was rather to check whether Pi-hole's required ports would be accessible via IPv4 and IPv6.
Did you verify they are?