Correct DNS address from DHCP but cannot resolve LAN hostnames

[jcathcart]

Hello, I am experiencing a bit of a challenge resolving local hostnames. We have an internal application server with the hostname of 'apps' on the domain 'lcs.lan' as you can see in the configuration details at the bottom of this post.

Hostname lookup from LAN workstation:

$ nslookup apps
Server:		127.0.0.53
Address:	127.0.0.53#53

** server can't find apps: SERVFAIL

FQD lookup from LAN workstation:

$ nslookup apps.lcs.lan
Server:		127.0.0.53
Address:	127.0.0.53#53

** server can't find apps.lcs.lan: NXDOMAIN

But if I specify the DNS server as the pfSense Gateway address it resolves:

$ nslookup apps 192.168.0.1
Server:		192.168.0.1
Address:	192.168.0.1#53

Name:	apps.lcs.lan
Address: 192.168.100.101

If we inspect the DNS servers the workstation is using we can see it has the expected 192.168.0.1:

$ nmcli device show eno0 | grep DNS
IP4.DNS[1]:                             192.168.0.1
IP4.DNS[2]:                             8.8.8.8
IP4.DNS[3]:                             8.8.4.4
IP6.DNS[1]:                             2603:300b:d05:ba80:a2ce:c8ff:feb6:ee6d

I am wondering if there is a reason nslookup is not effectively resolving the 'apps' hostname when the workstation has the 192.168.0.1 DNS entry, but when I specify 192.168.0.1 explicitly in the nslookup command it does resolve. I must be missing something I just don't know what it is. Any ideas?

Thanks for any help or insights!

Configuration Details

Network Range

---

Range: 192.168.0.0/16
WAN: DHCP Client
LAN: 192.168.0.1

General Setup

---

Hostname: pfSense
Domain: lcs.lan
DNS Server Override: Checked (no DNS servers specified here as override is checked)
DNS Resolution Behavior: use local, fallback to remote

DHCP Server

---

DHCP Backend: ISC DHCP
Enable: Checked
Primary Address Pool: 192.168.1.10-192.168.14.245
DNS Servers: [
192.168.0.1
8.8.8.8
8.8.4.4
]
DHCP Static Mappings: [
[MAC redacted] 192.168.100.101 apps Main application server & NAS
[MAC redacted] 192.168.100.104 mariadb Database for apps requiring MySQL
[MAC redacted] 192.168.100.105 proxy NGINX proxy for routing to internal applications
]

DNS Resolver

---

Enable: Checked
Network Interfaces: All
Outgoing Network Interfaces: All
DNSSEC: Checked
DNS Query Forwarding: Unchecked
DHCP Registration: Checked
Static DHCP: Checked
Host Overrides: none
Domain Overrides: none

[johnpoz]

@jcathcart said in Correct DNS address from DHCP but cannot resolve LAN hostnames:

127.0.0.53

That is a special loopback address, you need to see exactly where that is actually pointing.. That is points to a local dns client which then forwards to some other name server.

$ nmcli device show eno0 | grep DNS
IP4.DNS[1]:                             192.168.0.1
IP4.DNS[2]:                             8.8.8.8
IP4.DNS[3]:                             8.8.4.4
IP6.DNS[1]:                             2603:300b:d05:ba80:a2ce:c8ff:feb6:ee6d

Your problem is how do you know which one will be used.. 8.8.8.8 sure isn't going to know about your apps.lcs.lan record.

Your client should only point to NS that can resolve your local resources, 8.8.8.8 sure isn't going to be that.

And if you want to use just hostname, ie apps then you need to make sure what your using is going to auto add the correct search suffix. apps is not a resolvable.. the fqdn apps.lcs.lan could be..

[jcathcart]

@johnpoz Thanks for the response

Just to provide more information: I have the lcs.lan domain included in the search domains and it appears in the search list. I do not get resolution with just the FQDN (apps.lcs.lan) or with the the hostname alone ('apps') unless I specify the NS with nslookup.

$ nmcli device show eno0
...
IP4.DOMAIN[1]:                          lcs.lan
IP4.SEARCHES[1]:                        lcs.lan
...

I believe you have exposed the issue in regard to not knowing which NS is being targeted by the 127.0.0.53 loopback. As you already mentioned the 8.8.8.8 and 8.8.4.4 won't have any idea about the 'apps' or my internal domain so, reading between the lines, I think what you are saying is that 127.0.0.53 could be pointing to any of the three NS addresses which would fail unless it used the 192.168.0.1 address and we don't know which one is being selected. Please correct me if I am wrong.

I had previously used the 192.168.0.1 as the only DNS address issued by the DHCP Server, which did allow me to resolve local hostnames so what you are saying makes sense. The issue there was that I then could not resolve external hostnames (like google.com). Perhaps using 192.168.0.1 as the only NS issued by the DHCP Server and then enabling some sort of dns query forwarding would solve the issue?

Thanks for your help/time

[johnpoz]

@jcathcart so this pfsense is 192.168.0.1, unbound is running on it to resolve your local - it should be able to resolve external out of hte box. If it is not then yeah you have something not right.

[jcathcart]

@johnpoz Thanks for your help, it is now working.