Help me understand search domains

[bestboy]

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.

Code: [Select]

#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 ms
In 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:



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?

[Patrick M. Hausen]

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.

[bestboy]

Obviously I do not have many Apple devices in my network then

Thanks Patrick. I do understand that use case, but in such a case you could explicitly configure the client resolver to make use of the ndots option. The ndots option in the resolve.conf[1] defines the dots threshold for appending the search domain. The default is 1 meaning "if there are less than 1 dots, i.e. none, then append the search domain". In a scenario like yours, setting ndots throughout the network to 2 should help. Do Macs have a resolve.conf? For Windows there's a registry entry to configure[2] the dots threshold.

Still, that does not help to explain the invalid queries. The nts.ntstime.de query was not done by an Apple device. It was done by my OpnSense instance, which should use the ndots default value of 1.

Code: [Select]

#cat /etc/resolv.conf
domain home.lan
nameserver 127.0.0.1
search home.lan

[1] https://man.freebsd.org/cgi/man.cgi?resolv.conf
[2] https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.DNSClient::DNS_AppendToMultiLabelName

EDIT: inline links changed coz not working