MacOS – Adding “local” to the DNS Search Domains has no effect

dnsmacosNetwork

I have a Mac Mini (Yosemite) on my local network and it's not running a DNS server at all. When I want to access it over SSH from a Terminal on my Macbook Air (Yosemite), I can type:

$ ssh myserver.local

And that works fine.

But I wanted to avoid having to type the ".local" domain every time, so I added the "local" domain to the Search Domains list in Network Settings (for my Wi-Fi adapter which is the one currently in use in my MBA).

If I then try:

$ ssh myserver

that doesn't work (Could not resolve hostname).

Any idea why?

Best Answer

Hostname resolution in Mac OS X (since ~10.3) has roughly spoken - i exclude various cache mechanisms - the following operating sequence:

  1. 'Files' (e.g. /etc/hosts) ->
  2. mDNS ->
  3. DNS (search domains) ->
  4. DNS

Valid names for the different name resolution methods:

for 1: almost arbitrary names
for 2: name.local
for 3: name (+ search.domain in your network prefs) A Start Of Authority (SOA) record for the top level domain is obligatory.
for 4: fqdn

In your first scenario (myserver.local) you only use 'Files' and mDNS. 'Files' fails because there is no entry myserver.local in your hosts file. mDNS succeeds resolving it because it's a valid and resolvable mDNS name.

In your second scenario (myserver & search.domain local) you use 1, 2, 3 (and 4). 'Files' fails because you have no entry myserver, mDNS fails because it's no valid mDNS name. DNS (search domains) fails because you don't have a DNS-server with a SOA record for .local in your network (as well as DNS).

So just enter sudo nano /etc/hosts in Terminal and add the line:

 a.x.y.z      myserver

(a.x.y.z= IP-number of your server) and it should work. If you are really lazy even an 'a' as name might be sufficient. But don't use single numbers (like 1 or 123) because then ssh might try to connect to 0.0.0.1 or 0.0.0.123. At least ping connects to 0.0.0.1 or 0.0.0.123.

Related Question