Recently moved my PiHole instance from an Ubuntu install that was shared to a Rpi Zero (the original with a Ethernet hat) so it can be isolated and on a battery back up. Used the teleporter to move all my settings. Pihole is acting as the DHCP and DNS blocker for the whole network. Currently having issues where the local DNS (eg lan.mynetwork.xyz) stops working for extended periods of time then will come back without me taking any actions only to stop working again for awhile. When i use nslookup during the times it stops working the public DNS I use (1.1.1.1). DNS blocking during this "downtime" appears to still function. At the very least the query log is still showing blocked entries.
Expected Behaviour:
Constant local DNS resolution.
Actual Behaviour:
Local DNS will work sporadically. roughly 5-10 minute periods of each.
Can you elaborate a bit?
Are you saying you can resolve locally defined domains via 1.1.1.1?
Local defined names not being resolved often indicates that another DNS server is being used, by-passing Pi-hole. In your case, what you've shared suggests that you are using a public domain as local/search domain (i.e your probably obfuscated lan.mynetwork.xyz), which may mean that your local DNS records would shadow public DNS records. To avoid confusion and possible resolution conflicts, note that unless you own that specific domain, you should commonly use one of the domains reserved for private network usage (e.g. internal, lan or home.arpa).
For diagnosing your issue, it's probably best to work with concrete lookups for specific domains.
At the time where you observe local records to not resolve, what's the output of:
nslookup pi.hole
nslookup truenas
nslookup truenas 192.168.1.120
Also, your debug log shows that you have a few CNAME definitions that conflict with names defined in static leases (e.g. truenas and myspeed), so the static IP may not be associated with that name, i.e. truenas would not resolve to 192.168.1.100 from its static DHCP lease, but to the CNAME target's 192.168.1.111.
Yeah, happy to elaborate. Thank you for being willing to help.
I'm not trying to resolve local names to 1.1.1.1. Just when I do an NSLookup while its in "failure mode" it just returns that the resolution was sent to 1.1.1.1, which is just my secondary failover DNS. So instead of:
I get some weird error message about 1.1.1.1 not finding it. I didn't copy down the message, but as soon as it happens again I will post it.
I'm using my personally owned domain name. `
Unfortunately, it has decided to work all day today, so I'm not sure what is going on with that. Will test the domains you suggested when it fails on me again.
I'm kind of confused about the last party. I thought I was supposed to assign static IPs for the devices I was going to point my reverse proxy (traefik 192.168.1.111) entries at? For clarity, my Pihole's IP is 192.168.1.120.
Pi-hole has to be the only DNS server for your network.
If your clients are aware of alternative/secondary DNS servers, clients may use that alternative at their own discretion, and that alternative would of course not know anything about local DNS records as defined by Pi-hole exclusively, explaining your observation.
I think you are referring to your CNAME/static lease conflict?
From your debug log:
[2025-01-15 13:36:18.737 472M] WARNING in dnsmasq core: truenas.lan.mydomain.xyz is a CNAME, not giving it to the DHCP lease of 192.168.1.100
I have in my router a secondary failover DNS if my pihole can't be reached. That shouldn't affect the clients since they wouldn't see that unless the pihole is unreachable, right?
Yes that last * part* (sorry for the typo) is what confuses me. Why is it trying to give the cname to a dhcp static lease? The CNAMEs just points to my A-NAME record, which is traefik. What changed to cause this since I wasn't getting this error before?
If nslookup is reporting 1.1.1.1 as the server, then it is talking to 1.1.1.1 directly, i.e. at least the client it runs on is configured to use 1.1.1.1 for DNS, in addition to Pi-hole.
Because you have defined a static lease for the same FQDN (i.e. the name as extended by your local domain name), it is trying to assign that name to a device identified by a MAC, but can't do so, as you already have defined an identical CNAME.
You have defined more than one conflicting static DHCP leases/CNAMEs.
Your debug log's 48 hour retention period has expired, so I can't quote from it anymore.
@Bucking_Horn answered this above but to clarify for you, the secondary DNS field in the router is not a failover, its a second choice so clients can and will use it.