Cannot ping using hostname or fully qualifed domain name
Pihole is the DHCP & DNS service provider in the LAN. The router does not perform this function.
Expected Behaviour:
Any active DHCP client in the LAN could be referred to by its fully qualified domain name but right now that is not happening. There are lease records for the clients and the domain name suffix is clearly present. However, any reference to the client using the fully qualified domain does not return a valid result (i.e. its IP address).
Actual Behaviour:
$ ping raspbari19.parkcircus.org
ping: raspbari19.parkcircus.org: Name or service not known
$ ssh pi@raspbari19.parkcircus.org
ssh: Could not resolve hostname raspbari19.parkcircus.org: Name or service not known
but using the assigned IP address in the above examples works.
This instance of Pi-hole has been serving the LAN since 2016 along the lines of expected behavior. During some upgrades (OS & pihole), apache2 and connmand were inadvertently installed. After advice from the forum here, I removed these packages manually and reconfigured. I may have not completed the configuration correctly. I would like to refer to clients using their fully qualified domain names with using reference files (e.g. /etc/hosts or manually entering them via pihole features). Please advise. Thanks.
As a data point I am also using Pi-hole as my DHCP and DNS server on the LAN. Pi-hole detects and shows hostnames and I am able to reference those machines by hostname elsewhere on the LAN. I've not configured any manual entries for these hostnames, they have been picked up from the devices directly, Eg,
$ ping apple-tv
PING apple-tv.lan (192.168.1.57): 56 data bytes
64 bytes from 192.168.1.57: icmp_seq=0 ttl=64 time=2.024 ms
...
$ ping chriss-imac
PING chriss-imac.lan (192.168.1.121): 56 data bytes
64 bytes from 192.168.1.121: icmp_seq=0 ttl=64 time=0.048 ms
...
I think that's the behaviour you're describing, and what you're saying used to happen until recently, is that right?
Hello @chrislph! Cannot thank you enough because I thought I was off the deep end.
I would like to experience exactly the same results you have precisely illustrated. I need to be able to emulate exactly the same request/response sessions.
As I mentioned previously, Pi-hole is clearly registering the DHCP lease requests and appending the domain suffix (based on casual inspection of the query logs) but it is declining to respond to DNS queries directly. Which setting (as an error on my part) would cause this?
Thanks.
P.S.
I understand the manual part entry part (suggested previously) but that is not a viable solution except for key SOHO nodes such as NAS or Mail Server.
The results I posted are from a Mac which uses the Pi-hole for DHCP and DNS. If I try the same tests from the Pi-hole's terminal itself, the names are not known. This is because for the OS running the Pi-hole I use external DNS servers. This ensures that Pi-hole isn't using itself for DNS and avoids any problems during updates.
If you are running your tests from the Pi-hole itself you might see the same behaviour. Are you definitely running those tests from a machine that is not the Pi-hole and that is using the Pi-hole for DNS?
What happens if you try forcing the Pi-hole as the DNS and dig a known hostname? Does it work for that instance? And what DNS server does it reveal when you don't? This might reveal that another DNS server is in fact in use, not Pi-hole as you expected. Eg (the relevant lines),
$ dig apple-tv
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50677
;apple-tv. IN A
;; SERVER: 8.8.8.8#53(8.8.8.8)
There, the default OS DNS was revealed as Google's, and so apple-tv was not known. But if I explicitly force the Pi-hole, it resolves and you can see the same IP as earlier.
$ dig apple-tv @192.168.1.2
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65425
apple-tv. 0 IN A 192.168.1.57
;; SERVER: 192.168.1.2#53(192.168.1.2)
You can also try nmap discovery, with and without forcing the DNS as Pi-hole. Here are the relevant lines, you can see that without the OS's default external nameserver it's just IPs, with the Pi-hole they are resolved to the same IPs.
$ nmap -sn 192.168.1.0/24
Nmap scan report for 192.168.1.57
Nmap scan report for 192.168.1.121
$ nmap -sn --dns-servers 192.168.1.2 192.168.1.0/24
Nmap scan report for Apple-TV.lan (192.168.1.57)
Nmap scan report for Chriss-iMac.lan (192.168.1.121)
Thank you so much for your help. We're getting there. I ran the examples you provided in my LAN and low and behold the DHCP clients that I checked were given Google (ECS, DNSSEC) as the primary DNS server even though I had checked it as Upstream.
$ resolvectl dns
Global:
Link 2 (eno1): 8.8.8.8
Link 3 (wlx9cefd5fa9797):
Link 4 (docker0):
In other words, just like you explained, Pi-hole was being by-passed for DNS calls and that clearly explains my predicament.
In a former life, I would have whipped out Network Monitor and inspected the 3-way DHCP handshake but alas those days are history for me since I cannot afford Redmond's dues any more.
Right now my DNS settings in Pi-hole are:
Upstream - Google Advanced - Never forward non-FQDN, Never forward reverse lookups, Use DNSSEC Interface - Allow only local requests
Can you help me understand why DHCP clients are not being offered Pi-hole as the local DNS server? What setting is missing in my configuration for this purpose? It clearly something very basic that I inadvertently changed.
Thanks again so much!
P.S.
Your nmap and dig examples provided the clues. When Pi-hole is forced via command line option to serve as the DNS server, the name lookup works like a charm. In fact, zenmap with this option provides the FQDN hostnames too.
pi@ph5a:~ $ pihole -t
[..]
Feb 7 15:17:11: query[PTR] 2.0.0.10.in-addr.arpa from 10.0.0.11
Feb 7 15:17:11: /etc/pihole/custom.list 10.0.0.2 is ph5a.home.dehakkelaar.nl
Feb 7 15:17:11: query[A] avr.home.dehakkelaar.nl from 10.0.0.11
Feb 7 15:17:11: DHCP avr.home.dehakkelaar.nl is 10.0.0.9
Feb 7 15:17:11: query[AAAA] avr.home.dehakkelaar.nl from 10.0.0.11
Feb 7 15:17:11: config avr.home.dehakkelaar.nl is NODATA-IPv6
pi@ph5a:~ $ pihole -t
[..]
Feb 7 15:18:12: query[PTR] 2.0.0.10.in-addr.arpa from 10.0.0.11
Feb 7 15:18:12: /etc/pihole/custom.list 10.0.0.2 is ph5a.home.dehakkelaar.nl
Feb 7 15:18:12: query[A] avr.home.dehakkelaar.nl.home.dehakkelaar.nl from 10.0.0.11
Feb 7 15:18:12: config avr.home.dehakkelaar.nl.home.dehakkelaar.nl is NXDOMAIN
Feb 7 15:18:12: query[AAAA] avr.home.dehakkelaar.nl.home.dehakkelaar.nl from 10.0.0.11
Feb 7 15:18:12: config avr.home.dehakkelaar.nl.home.dehakkelaar.nl is NXDOMAIN
Feb 7 15:18:12: query[A] avr.home.dehakkelaar.nl.dehakkelaar.nl from 10.0.0.11
Feb 7 15:18:12: cached avr.home.dehakkelaar.nl.dehakkelaar.nl is NXDOMAIN
Feb 7 15:18:12: query[AAAA] avr.home.dehakkelaar.nl.dehakkelaar.nl from 10.0.0.11
Feb 7 15:18:13: cached avr.home.dehakkelaar.nl.dehakkelaar.nl is NXDOMAIN
Feb 7 15:18:13: query[A] avr.home.dehakkelaar.nl from 10.0.0.11
Feb 7 15:18:13: DHCP avr.home.dehakkelaar.nl is 10.0.0.9
Feb 7 15:18:13: query[AAAA] avr.home.dehakkelaar.nl from 10.0.0.11
Feb 7 15:18:13: config avr.home.dehakkelaar.nl is NODATA-IPv6
By the way, its not Pi-hole thats adding the search/suffix domain but the clients doing that instead.
If you dont want them to add a search/suffix domain, add a dot "." at the end of the name eg:
pi@ph5a:~ $ pihole -t
[..]
Feb 7 15:26:07: query[PTR] 2.0.0.10.in-addr.arpa from 10.0.0.11
Feb 7 15:26:07: /etc/pihole/custom.list 10.0.0.2 is ph5a.home.dehakkelaar.nl
Feb 7 15:26:07: query[A] avr from 10.0.0.11
Feb 7 15:26:07: DHCP avr is 10.0.0.9
Feb 7 15:26:07: query[AAAA] avr from 10.0.0.11
Feb 7 15:26:07: config avr is NODATA-IPv6
That is exactly what I need to achieve but cannot. When I first installed pi-hole in 2016 and ever since until a few days ago, everything was fine. I kept pi-hole upgraded on a regular basis.
I got the urge to upgrade from Buster to Bullseye and that is when the problems started. One of the primary pi-hole developers (co-founder, I believe) noticed that Apache2 and connmand had been installed during the OS upgrade. Thereupon I uninstalled these packages and pi-hole Dashboard confirmed that its operations are available to users.
Based on the guidance from @chrislph, it is clear that my pi-hole is offering a DNS service. The issue I feel is that when the pi-hole DHCP service is sending the response to the lease request, instead of providing its IP address for DNS service it is feeding the Google IP address. As I remarked, it is very easy to establish this "hunch" through some Wireshark data acquisition (that I do not have unfortunately) but the forensic trail is apparent from the resolvectldns command.
There must be a setting that I unknowingly tripped in my pi-hole configuration after the upgrade such that its DNS service is not the first source for DNS resolution in my LAN. How can I ensure that all DHCP clients use pi-hole first and then let pi-hole decide on further resolution if necessary?
Perhaps I'm making a mountain out of a molehill owing to a basic mistake on my part. Unfortunately, there are almost 58 DHCP clients in the LAN. Manual changes to each are impractical. If someone more familiar with pi-hole DHCP services could set me on the right path, I'd be very grateful.
Right know in the absence of further straws, I will disable references to external DNS servers and see what the pi-hole DHCP service offers for DNS resolution. Thank you again for stepping up to provide guidance that everything is fine with pi-hole but my configuration is messed up.
It'll be worth creating another debug log and posting the token URL here (they expire after 48 hours so the previous one will be gone now). That way someone on Pi-hole staff will be able to check to see if you have multiple DHCP servers or anything else unexpected.
Quick reply here (while I work on your other suggestions):
reza@BeUlta:~$ nslookup raspbari14.parkcircus.org 172.16.0.2
Server: 172.16.0.2
Address: 172.16.0.2#53
Name: raspbari14.parkcircus.org
Address: 172.16.0.57
reza@BeUlta:~$ nslookup 172.16.0.57 172.16.0.2
57.0.16.172.in-addr.arpa name = raspbari14.parkcircus.org.
reza@BeUlta:~$ ssh chowkidar@raspbari14.parkcircus.org
ssh: Could not resolve hostname raspbari14.parkcircus.org: Name or service not known
reza@BeUlta:~$
