Local DNS - hostname not resolving, only FQDN

The issue I am facing:
Using Local DNS

Details about my system:
Fedora Server 33 virtual machine. Non-DHCP

What I have changed since installing Pi-hole:
Installed unbound. Add local host to Local DNS Records

My apologies ahead of time for being lengthy...

Current LAN setup:

Router: Ubiquiti USG
Role: DHCP
Domain name: offworld.lan

Pi-Hole: Fedora Server 33 running as a virtual machine on a dedicated virtual host
Role: DNS server/Recursive with unbound
DNS settings:
Upstream DNS Servers: Default Google deselected with custom 127.0.0.1#5335, everything else default.
Local DNS Records:
enas 192.168.15.8
enas.offworld.lan 192.168.15.8

My path to attempting to get local DNS resolution working led me to a video on YouTube for installing and configuring unbound. Unbound is working. I stated that so that all will know that installing unbound is one of the biggest changes to my Pi-hole configuration.
Now, stating all that, I am trying to understand why resolving local DNS is inconsistent. I can resolve my client hostname with the FQDN but not just with its hostname. Why is that?
Below are results from one of my Fedora client machines looking at the Fedora server Pi-hole for DNS.


[ed@edfed: ~]$ dig enas

; <<>> DiG 9.16.20-RH <<>> enas
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64155
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;enas.				IN	A

;; Query time: 3526 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Oct 07 06:59:08 EDT 2021
;; MSG SIZE  rcvd: 33

[ed@edfed: ~]$ dig enas.offworld.lan

; <<>> DiG 9.16.20-RH <<>> enas.offworld.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 489
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;enas.offworld.lan.		IN	A

;; ANSWER SECTION:
enas.offworld.lan.	0	IN	A	192.168.15.8

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Oct 07 06:59:39 EDT 2021
;; MSG SIZE  rcvd: 62
ed@edfed: ~]$ ping enas
ping: enas: Name or service not known
[ed@edfed: ~]$ ping enas.offworld.lan
PING enas.offworld.lan (192.168.15.8) 56(84) bytes of data.
64 bytes from enas (192.168.15.8): icmp_seq=1 ttl=64 time=0.434 ms
64 bytes from enas (192.168.15.8): icmp_seq=2 ttl=64 time=0.227 ms
64 bytes from enas (192.168.15.8): icmp_seq=3 ttl=64 time=0.232 ms
^C
--- enas.offworld.lan ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.227/0.297/0.434/0.096 ms

I would love to be able to resolve clients on my LAN with just hostname to eliminate the additional typing of the FQDN.
Any assistance would be greatly appreciated.

Did the failed dig for enas register in Pi-hole's Query Log?

Could you share the contents of /var/log/pihole.log corresponding to a working and a failed dig?

No, I am not seeing the query in the log for enas, only enas.offworld.lan.

This is all I am seeing in the log for enas:

Oct  7 15:43:05 dnsmasq[6350]: query[A] enas.offworld.lan from 192.168.15.10
Oct  7 15:43:05 dnsmasq[6350]: /etc/pihole/custom.list enas.offworld.lan is 192.168.15.8

That would suggest that the respective DNS request never made it to Pi-hole.

Could you repeat the test dig's, this time forcing them via your Pi-hole's IP address, e.g.

dig enas @192.168.15.x

where 192.168.15.x is to be substituted by your Pi-hole host machine's IP address?

That seemed to work.


[ed@edfed: ~]$ dig enas @192.168.15.32

; <<>> DiG 9.16.20-RH <<>> enas @192.168.15.32
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16872
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;enas.				IN	A

;; ANSWER SECTION:
enas.			0	IN	A	192.168.15.8

;; Query time: 0 msec
;; SERVER: 192.168.15.32#53(192.168.15.32)
;; WHEN: Fri Oct 08 06:44:00 EDT 2021
;; MSG SIZE  rcvd: 49

[ed@edfed: ~]$ dig enas.offworld.lan @192.168.15.32

; <<>> DiG 9.16.20-RH <<>> enas.offworld.lan @192.168.15.32
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7904
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;enas.offworld.lan.		IN	A

;; ANSWER SECTION:
enas.offworld.lan.	0	IN	A	192.168.15.8

;; Query time: 0 msec
;; SERVER: 192.168.15.32#53(192.168.15.32)
;; WHEN: Fri Oct 08 06:45:26 EDT 2021
;; MSG SIZE  rcvd: 62

So, what this is telling me, at least in my interpretation, is that even though I have my network adapter looking at my Pi-hole for DNS, it doesn't seem to actually be looking at my Pi-hole for DNS local name resolution.
Would going into the Pi-hole DNS Settings and configure "Conditional forwarding" fix this issue?

The above results demonstrate that your Pi-hole at 192.168.15.32 is correctly providing resolution as expected.

Your initial dig results show a local DNS resolver at 127.0.0.53 has processed your request:

This would suggest that the server at 127.0.0.53 is not forwarding plain, non-dot hostnames upstream at all or upstream to Pi-hole respectively.

You'd have to find a way to configure (or disable) your machine-local DNS resolver(s) to address your issue.

Yeah, I see that now. Interesting. Looking on my Fedora's /etc/resolv.conf file it does have that address, even though I provided the Pi-hole address in Network Manager.
I'll see what I can figure out. Thanks.

Note that this would potentially apply to any of your clients that would employ a stub DNS resolver on the client machine itself.

Understood. Thanks.
Okay, so now I have updated /etc/resolv.conf with the IP address of my Pi-Hole and also selected the checkbox with configuration in Pi-Hole for Conditional Forwarding, my host is resolving with dig now.

ed@edfed: ~]$ dig enas

; <<>> DiG 9.16.21-RH <<>> enas
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10108
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;enas.				IN	A

;; ANSWER SECTION:
enas.			0	IN	A	192.168.15.8

;; Query time: 0 msec
;; SERVER: 192.168.15.32#53(192.168.15.32)
;; WHEN: Fri Oct 08 08:48:01 EDT 2021
;; MSG SIZE  rcvd: 49

However, when I ping the host, I get no reply.

ed@edfed: ~]$ ping enas
ping: enas: Name or service not known

Is there a reason I would not be able to ping the host? I'm assuming a pointer recorder would need to be entered in Pi-Hole also? If so, where does that get configured?

There is nothing wrong with Pi-hole here.

ping uses other methods to resolve hostnames besides DNS (and this is also what renders ping inadequate as a tool to analyse DNS issues).

Some ping implementations may not consider to resolve a given non-dot hostname via DNS. So far, I've only observed Windows' ping utilities to expose such behaviour (and inconsistently as well).
EDIT: So it is ping not sending a DNS request, rather than Pi-hole not answering it.

In any case, it should be easy enough to force ping to request name resolution by DNS, namely by appending your hostname by a dot, e.g.

ping enas.

Understood.
Thanks again for all your assistance and prompt replies.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.