Good morning,
I have two piholes running 192.168.4.99 & 192.168.4.100. They supply ad blocking, DHCP and local domain resolution on an active home network. They are named dns-pi2b and dns-pi3b. Recently, dns-pi2b stopped responding to its name, but I can still contact it by its IP address. Does anyone have any ideas how to correct this anomaly; the machines worked perfectly for years prior.
Hey,
How did you ensure your LAN devices can resolve this hostname in the first place ? I assume you created an A record on your piholes DNS integrated zone and set one or both of your piholes as DNS server on your devices interfaces, but I might be wrong. If so, which is the primary one ?
What does dig or nslookup tells you when you query dns-pi2b A or CNAME record ?
Are you running into this issue on every LAN device ?
Any recent change you might be aware of ?
Also, I don't know if this question is pertinent yet, but how are these two DNS server related; are they clustered in some way ?
Run from a client, what's the output of:
nslookup pi.hole
nslookup dns-pi2b
nslookup dns-pi3b
Both machines names have been resolving for the past two years without any issues. Only dns-pi2b is affected, and only during an HTTP address lookup. SSH dns-pi2b still resolves correctly. This just started the other day. Otherwise, the operation is normal.
nslookup pi.hole -- nothing.
nslookup dns-pi2b or dns-pi3b causes the ssh program to login to either server.nslookup has no ties to ssh - I'd be surprised if that was the case.
Please post the full output of those nslookup commands as run from a client.
ssh nslookup pi.hole
ssh: Could not resolve hostname nslookup: Name or service not known
Same response as before to both dns-2b and dns-3b. Automatically logs into the machines with ssh.
Oops! I didn't notice the leading ssh. Let me retry.
The commands I've asked you to run are not preceeded by ssh.
I also asked you to run them from a client (i.e. not from your Pi-hole machine you are probably trying to ssh into).
Please run the commands exactly as provided, and do run them from a client.
kali@kali:~$ nslookup pi.hole
Server: 192.168.4.99
Address: 192.168.4.99#53
Name: pi.hole
Address: 192.168.4.99
kali@kali:~$ nslookup dns-pi2b
Server: 192.168.4.99
Address: 192.168.4.99#53
Name: dns-pi2b
Address: 192.168.4.99
kali@kali:~$ kali@kali:~$ nslookup dns-pi3b
Server: 192.168.4.99
Address: 192.168.4.99#53
Name: dns-pi3b
Address: 192.168.4.100
As I mentioned before, the command line still works, it is only the HTTP request for dns-pi2b that is affected.
From the output you posted above, Pi-hole has correctly resolved all three domain names.
It did. But the web page for dns-pi2b no longer resolves. The page times out. dns-pi3b still serves content.
Those nslookup results show that your kali client was using your Pi-hole at 192.168.4.99 for DNS (at least for those requests), and they confirm that your 192.168.4.99 knows how to resolve both dns-pi2b and dns-pi3b.
Would that be true for your 192.168.4.100 as well?
And would your clients perhaps have a choice of other DNS servers, apart from your two Pi-holes?
Also, please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
pihole -d
or do it through the Web interface:
Tools > Generate Debug Log
Good morning,
Here is the token: https://tricorder.pi-hole.net/2YqVtQtA/
I'm not having trouble with DNS resolution, the web interface on dns-p12b stopped working.
Has it now?
I thought you could still access its UI when you...
It would be good to confirm that by running those nslookups against your second Pi-hole at 192.168.4.100.
Your debug log shows your router's DHCP server to distribute 3 public IPs as DNS server:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
* Received 307 bytes from eth0:192.168.4.1
Offered IP address: 192.168.5.17
DHCP options:
Message type: DHCPOFFER (2)
router: 192.168.4.1
dns-server: 206.225.75.226
dns-server: 206.225.75.225
dns-server: 184.170.172.131
That would allow DHCP clients to by-pass Pi-hole.
Unless you've manually pointed every client to Pi-hole for DNS, your clients won't be using Pi-hole
Could you provide a token for your .100 Pi-hole as well?
I changed the order the 192.168.11.xxx network gets its DNS and DHCP requests from 192.168.4.99 to 192.168.4.100. Now the web interface shows up again on both pi holes using their names. It is only when 99 is the primary DNS. Weird.
Those other DNS servers are not being used by the network protected by pi hole. They come from my ISP and every thing is configured to ignore them. Home Assistant, for example, could not deal with them. Well, it's all working now...
Glad it's working for you. 
Primary DNS server is not a well-defined concept.
You'll note from the DHCP output that all those IPs are announced as dns-server indiscriminately - there simply is no primary or secondary or alternate flag.
Each client is free to use any of them, and will decide to do so following its own mostly opaque rules when to prefer one over another.
I'd still recommend to run those nslookups against your second Pi-hole, e.g.
nslookup dns-pi2b 192.168.4.100
My suspicion is that your .100 doesn't know about dns-pi2b, and if a client sends a DNS request to your .100, it simply would fail to resolve, but that is just sort of an elaborated guess.
Answering my questions about UI availability, running the lookup through your second Pi-hole and providing a debug token for that could have helped to confirm or reject that suspicion, and probably would've revealed the underlying root cause.
kali@kali:~$ nslookup dns-pi2b 192.168.4.100
Server: 192.168.4.100
Address: 192.168.4.100#53
Name: dns-pi2b
Address: 192.168.4.99
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.