Mac OS X 10.9 treating subdomain as top-level domain?

Question

I seem to constantly have trouble resolving hosts on my network from OS X systems. I have a domain (let's call it mydomain.com) with a lab.mydomain.com subdomain and the host I want to get to, at host.lab.mydomain.com.

My Mac's DNS search entries include:

1. mydomain.com
2. lab.mydomain.com
3. lab.otherdomain.com
4. othersubdomain.otherdomain.com

I can resolve the full 'host.lab.mydomain.com' just fine, and when I have 'lab.mydomain.com' in the list, I can use just 'host' since it resolves under the 'lab.mydomain.com' suffix. But I can't resolve (in certain cases -- read on) "host.lab".

The weirdest thing is this failure only happens with certain commands (namely, SSH and dig). Using 'nslookup' works fine and resolves the hostname properly. However, using SSH or dig fails. I can usually, but not always, resolve "host.lab" through Chrome.

I ran a tcpdump filtering on port 53 to try and diagnose this myself, and the results were interesting: after running "dscacheutil -flushcache; killall -HUP mDNSResponder" and attempting to resolve using the different commands, I found that "nslookup" of course was doing a proper lookup to my configured DNS server using each suffix in order, which found the host in short order. However, ssh and dig seem to be treating "host.lab" as a top-level domain and going straight to root-servers.net to try and resolve "host" as a domain name under the ".lab" TLD -- without ever touching my configured DNS server!

What's the deal? Why are these certain name resolution schemes on my Mac short-circuiting and treating .lab as a top-level domain instead of honoring my DNS search suffixes? Of course I can work around this by punching out the full domain name, but it's really, really annoying.

Answer 1

Keep in mind that nslookup and dig are DNS debugging tools. They have their own built-in resolver code and do not behave the same way as the system resolver that regular applications use. By default, dig never appends search-list domains to try to fully-qualify a name, even if you give it just "host" (it'll treat that as a top-level domain), but nslookup does the opposite and always appends search-list domains (to try and "help" you). These tools couldn't be more juxtaposed as debugging tools go.

Most command-line applications (like 'ssh') use the BSD library for name lookup and the resolver code in that comes from BIND which treats any name with a "." in it as a fully-qualified domain and it will not append search-list domains. There's a long sordid history as to why, but it works best this way to avoid conflicts and name "collisions" that happen with search-list appending in a general sense. You can read recent analysis on this topic.

Now that you understand this, use either "host" or "host.lab.mydomain.com" with your apps. ;-)

Answer 2

From dig's manpage:

Mac OS X NOTICE
       The dig command does not use the host name and address resolution or
       the DNS query routing mechanisms used by other processes running on Mac
       OS X.  The results of name or address queries printed by dig may differ
       from those found by other processes that use the Mac OS X native name
       and address resolution mechanisms.  The results of DNS queries may also
       differ from queries that use the Mac OS X DNS routing library.

When watching the DNS transactions via tcpdump as you did, I noticed dig was sending a fully qualified (has a trailing .) DNS query, even when it wasn't included on the command line:

192.168.2.122.61036 > 142.166.166.166.53: 51329+ A? www. (21)

This, of course, will fail. This is the default behaviour for this compilation of dig; adding +search to its arguments will make it behave more conventionally.

For ssh and others, I found this article that suggests adding an argument to the mDNSresponder's property list file to compel it to use the search domains. This may also fix dig.