Hi,
maybe you can help me understand search domains. I don't seem to get it.
Here's the relevant description of my setup:
- I'm using OpnSense and have a home domain home.lan (I explicitly tried to avoid .local used by mDNS to not get into some sort of trouble)
- OpnSense hosts a network-facing, resolving and caching Unbound instance.
- The Unbound instance handles all the resolving of dynamically assigned devices for home.lan.
- The Unbound instance delegates resolving of all statically assigned devices to a local Bind instance via a stub zone.
- The local Bind instance is private and provides home.lan records to Unbound for all devices with static IPs.
- DHCP is providing the search domain home.lan via option 119.
- DHCP is providing the domain home.lan via option 15.
- Devices with static IPs have the search domain and domain manually set to home.lan (that includes the OpnSense instance)
What is a search domain?
As I understand it, search domain is a convenience feature that "interpolates" host names into FQDNs. It tries to detect, if a given domain string is a proper FQDN or just a host name. In the latter case it creates a FQDN by appending the search domain. This turns a mere host name into something known to DNS that can actually be used for addressing.
For example: Entering the host name
opnsense into a ping will "interpolate" into
opnsense.home.lan which is a proper domain name known to DNS.
#ping -v opnsense
ping: sock4.fd: 3 (socktype: SOCK_RAW), sock6.fd: 4 (socktype: SOCK_RAW), hints.ai_family: AF_UNSPEC
ai->ai_family: AF_INET, ai->ai_canonname: 'opnsense.home.lan'
PING opnsense.home.lan (172.22.24.254) 56(84) bytes of data.
64 bytes from 172.22.24.254: icmp_seq=1 ident=30591 ttl=63 time=0.757 ms
64 bytes from 172.22.24.254: icmp_seq=2 ident=30591 ttl=63 time=0.658 ms
64 bytes from 172.22.24.254: icmp_seq=3 ident=30591 ttl=63 time=0.693 ms
^C
--- opnsense.home.lan ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2032ms
rtt min/avg/max/mdev = 0.658/0.702/0.757/0.041 msIn my case the A record of
opnsense.home.lan is provided by the private Bind instance to the Unbound instance, which will cache it and provide it to the requesting client. All good and well.
Now, my issue is with the host name detection mechanism of the search domain feature. By default the search domain is appended, if there are no dots in the given domain string. The reasoning being: No dots means host name (cf. host name
opnsense vs. domain name
google.com).
However, that detection does not seem to work well. I can see multiple instances in which nonsensical DNS queries were created by appending the search domain. Here's an example from a time server lookup of my Chrony instance trying to lookup
nts.ntstime.de.home.lan:
(https://forum.opnsense.org/index.php?action=dlattach;topic=41324.0;attach=35893)
Can anyone explain, why I see such invalid search-domain-appended queries from clients? Why is the search domain appended to the proper domain
nts.ntstime.de in this instance?
The client's resolver library is the point where the search domain is added. And some client systems just do that. Years ago all did that, but e.g. Apple removed that feature.
Imagine a company with two locations and hosts like:
dc1.ka.punkt.de
dc1.ffm.punkt.de
So I can ping e.g. dc1.ka or dc1.ffm and the resolver will append punkt.de and I can reach both servers conveniently. Unfortunately today on a Mac dotted hosts won't have the search domain(s) appended.