No ERROR messages for local IP address in-addr.arpa records in /var/log/pihole/FTL.log.
2025-08-07 18:01:10.220 ERROR Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2025-08-07 18:01:10.228 INFO Tried to resolve PTR "32.1.168.192.in-addr.arpa" on 127.0.0.1#53 (UDP)
Seeing above ERROR and INFO messages.
Your debug log shows your Pi-hole host machine's network interface to carry two IPs:
*** [ DIAGNOSING ]: Network interfaces and addresses
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 192.168.1.32/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.1.35/24 scope global secondary eth0:1
valid_lft forever preferred_lft forever
While your Pi-hole's DHCP and web servers are listening on all addresses, you have applied a custom configuration that restricts Pi-hole's DNS service to 192.168.1.35 (from your virtual eth0:1 interface):
[misc]
(…)
dnsmasq_lines = [
"# 12-listen-on-virtual-interface.conf",
"listen-address=192.168.1.35",
"bind-dynamic",
(…)
] ### CHANGED, default = []
That custom configuration is potentially interfering with Pi-hole's Interface Settings as exposed via its DNS Settings panel.
By using listen-address to bind to a specific IP address, Pi-hole won't listen on the loopback interface, which may contribute to your observation:
*** [ DIAGNOSING ]: Ports in use
[✓] udp:192.168.1.35:53 is in use by pihole-FTL
udp:0.0.0.0:67 is in use by pihole-FTL
udp:0.0.0.0:123 is in use by pihole-FTL
udp:0.0.0.0:5353 is in use by avahi-daemon
udp:*:123 is in use by pihole-FTL
udp:*:5353 is in use by avahi-daemon
[✓] tcp:0.0.0.0:443 is in use by pihole-FTL
[✓] tcp:192.168.1.35:53 is in use by pihole-FTL
[✓] tcp:0.0.0.0:80 is in use by pihole-FTL
[✓] tcp:[::]:443 is in use by pihole-FTL
[✓] tcp:[::]:80 is in use by pihole-FTL
Furthermore, your debug log shows you have enabled Pi-hole's Conditional Forwarding to 192.168.1.32:
[dns]
(…)
revServers = [
"true,192.168.1.0/24,192.168.1.32,lan"
] ### CHANGED, default = []
But your custom dnsmasq_lines instruct your Pi-hole to NOT listen on that address, i.e. there won't be any answers from 192.168.1.32, unless another DNS server (separate from Pi-hole) would bind that address.
As your Pi-hole is acting as DHCP server, Conditional Forwarding wouldn't be required at all (unless you'd run another DNS server that holds local names in your network).
What's the purpose of that virtual interface configuration anyway?
If you don't depend on it, a simple fix would be to return to Pi-hole's standard listening behaviour, by dropping eth0:1 along with your respective custom dnsmasq_lines.
Probably unrelated to your issue, your debug log shows a few permission issues:
-----tail of FTL.log------
2025-08-07 22:05:07.650 UTC [1314M] WARNING: Failed to change ownership of "/etc/pihole/pihole.toml" to pihole:pihole (995:1001): Insufficient permissions (CAP_CHOWN required)
2025-08-07 22:05:07.677 UTC [1315M] WARNING: Cannot get exclusive lock for /etc/pihole/pihole.toml: Bad file descriptor
*** [ DIAGNOSING ]: Pi-hole log
-rw-r----- 1 nobody nogroup 1.7M Aug 7 22:05 /var/log/pihole/pihole.log
-----head of pihole.log------
(…)
Aug 7 21:17:10 dnsmasq[44975]: warning: failed to change owner of /var/log/pihole/pihole.log: Operation not permitted
It would seem you are running your Pi-hole in a virtualised environment, so you may need to adjust that environment's capabilities/permissions.
Thank you for the detailed responses. I have 2 Pi-hole's sitting behind a Keepalived VIP for an HA implementation. Keepalived will add a secondary interface with the VIP to the "main Pi-hole". I use Pi-hole for BOTH DNS and DHCP services in my network.
Originally, I thought it would be better to have Pi-hole ONLY listen on the VIP, but now that I think about it again, it really doesn't matter. Removed the custom dnsmasq config, and reverted back to Pi-hole's default interface settings.
Now that I understand the use case of Conditional Forwarding better, I also removed the custom config, since Pi-hole is the DHCP server.
With the above changes, the spurious error messages seem to have stopped. Will monitor and report back again if I see them in the future.
On the file permissions issue, it is because I have /etc/pihole, /opt/pihole, and /var/log/pihole all sitting on a bind mounted NFS mount to prevent excessive writes to the SD card.
i.e.,
NFS: 192.168.1.30:/export/pihole_storage/pi-hole6-01 ==> /mnt/pihole_storage
Bind: /mnt/pihole_storage/etc/pihole ==> /etc/pihole
Since the NFS location is owned by nobody:nogroup, when Pi-hole tries to modify ownership, it fails. However, file read/write is all OK.
I’d advise against hosting Pi-hole’s SQLite3 databases on an NFS mount.
SQLite3's write locking is based on locking database files, and as such is depending on file locking routines of the underlying OS.
Unfortunately, POSIX advisory locks are known to be somewhat buggy across all OSs when it comes to network shares, which means you are bound to provoke database corruption when storing SQLite3 database file on NFS shares.
SQLite3's documentation on How To Corrupt Your Database Files states:
Your best defense is to not use SQLite for files on a network filesystem.
Good points … between the log files and the SQLite DB files, which ones see most activity?
Main area of concern is SD card longevity.
As a data point, I’m using a Raspberry Pi 3B+ and a no-name 16GB SD card which came with it from a reputable online supplier in the UK, and I bought it nearly a decade ago. It’s been running Pi-hole for much of that. with full logging as well as various network projects alongside it pretty much 24/7.
It’s still going today no problem with the same SD card which has no errors. I normally buy Sandisk-branded cards but this black no-name one came with the Pi in a starter kit.
Even if they only lasted a few months, I think they’re far cheaper to replace as needed than the hassle of trying to work around the corruption problems from a remote database relocation.
I also use the official Raspberry Pi PSU for that model, and that seems to make a difference too, a reliable power source. In my experience (with the PiAware project) a killer of SD cards is a power failure at just the wrong time, eg a filesystem write. That’s been my only experience of a failed SD card that was just not recoverable – it could not be thereafter formatted past a certain percentage no matter what.
So a poor PSU could amplify that effect and give the illusion that the goal is to minimise writes, when really it would be to switch to a decent PSU and even move the Pi onto a UPS if available, along with other kit. In the PiAware case a UPS HAT was bought and installed and a script deployed which handles a clean shut down after a sustained power loss. In my own Pi-hole case it’s an official PSU and sat on a sinewave UPS along with other kit.
I agree with chrislph.
I have installed about 15 Pi's from the first release some 12 years ago with different purposes for myself, friends and relatives without experiencing any SD card issues.
Of which two here at home still run Pi-hole with the originally installed SD cards some eight years ago.
Only one very old and nameless cheap SD card died but that was most likely bc it was exposed to the outside elements as a weather station.
My experience is that allot of folks attribute filesystem corruption to a faulty SD card while its most likely just poor power.
For Pi's, I recommend to get the official ones with the Raspi logo.
I have some other brand AC adapters as well but you have to be a bit lucky with them to supply a stable Voltage.
Its not only the max Wattage that counts.
And for SD cards, get a spacious one to spread out the writes.
Dont get the cheapest one.
EDIT:
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#power-supply-warnings
Was thinking, what about an iSCSI LUN?
Thats a block device instead of share that leaves file locking to the OS.
For if you really need to scale up 
I already experimented with that before with a Pi and my Syno NAS: