Hi.
I am having trouble getting DNSMasq and Unbound to behave the way I'm wanting.
I have a domain, and my ISP hosts my email (mail.domain.com) and website (www.domain.com). This works fine. I have named my internal network lan.domain.com. So, my NAS is nas.lan.domain.com. In order to resolve the name of any internal system I need to use the fqdn (like the example above, nas.lan.domain.com).
How do I get DNSMasq and Unbound to resolve using just the hostname, since every internal system is in the same lan.domain.com sub-domain? I shouldn't have to always use the fqdn for my internal systems. Or do I need to punt Unbound and install BIND?
Any help would be greatly appreciated.
Details: - most systems have DNS reservations in DNSMasq
- all internal systems, including the firewall, are in the lan.domain.com sub-domain
- I have a mix of BSD, Linux, and Windows systems
- I defined a DHCP range for the LAN interface to see if it would help
- I tried an override in Unbound to see if it would help
- lan.domain.com is set as a private domain in Unbound, again, to see if it would help
Did I miss anything?
Set the DHCP search domain option to "lan.domain.com" so your clients that got a lease from the DHCP server append that name when you lookup for "nas".
Exactly which page is this on? (I have lan.domain.com already explicitly set in several (all?) places. Also, I assume this is set within the server, and not as a setting passed to clients which would require a reboot.)
Its a client setting, the client decides how to ask the DNS server for a name.
Clients either get it via DHCP option or you set it manually in them.
In dnsmasq its the "domain" setting in each range.
Here some context what a search domain is:
https://en.wikipedia.org/wiki/Search_domain
Here where we explained it for dnsmasq:
https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration
If it doesnt work, its entirely up to the client, the DNS server cannot do anything about it.
OK, thank you. So, it will only work after the client asking has rebooted? That's going to be a pain. :( This also explains my nslookup results.
I always thought this was a server-side setting...
Thank you again, I've learned something new.
R
the answer is a little more nuanced.
It depends on the client, and the DHCP server
Some clients, like Win 10/11, Ubuntu, natively out of the box, automatically include DHCP Parameter option 119 (Domain search list) in their DHCP discover and DHCP request.
And some clients, like Android phones, don't natively request option 119 at all.
And some clients, like Linux clients, allow you to administratively configure which DHCP parameter options are requested in DHCP discover/requests...
On the DHCP server side, the DHCP option 119 (Domain search list) needs to be configured, to supply an answer to option 119 in DHCP offer and DHCP ack, to clients that asked/requested option 119 in DHCP discover/requests.
Thank you for the detailed explanation.
Once again, the great thing about standards is that there are so many of them. :/
R
Quote from: rheilke on August 07, 2026, 07:35:53 PMOnce again, the great thing about standards is that there are so many of them. :/
But wait, there is more! I had a similar problem in my network that non-fqdn requests from my Windows 11 client to my TrueNAS server didn't work properly. The culprit here was that apparently Windows 11 uses mDNS by default. And the TrueNAS server had two network interfaces and returned two IPv4 adresses, but Windows picked the wrong one. I had to disable the mDNS server on TrueNAS to get this to work.
Don't run a NAS dual homed.
Quote from: rheilke on August 07, 2026, 07:35:53 PMOnce again, the great thing about standards is that there are so many of them. :/
https://xkcd.com/927/
LOL! ^_^
tangofan: thanks for the note about mDNS and TrueNAS. I'll check what QNap does.
Haven't seen XKCD in ages...
Not sure why this isn't working for you. I can resolve without using FQDN.
❯ ping ap
PING ap.internal (10.10.2.4) 56(84) bytes of data.
64 bytes from ap (10.10.2.4): icmp_seq=1 ttl=63 time=0.562 ms
64 bytes from ap (10.10.2.4): icmp_seq=2 ttl=63 time=0.443 ms