DNS works in terminal but not elsewhere in Mac OS

Question

I have an issue similar to the one in this question: DNS not resolving on Mac OS.

Things out on the Internet work fine. Local machines in my company, however, fail to resolve, including the servers I'm trying to work on.

We use local DNS servers and my Network preferences show only those local DNS servers. (192.168.20.10, 192.168.25.10)

Trying to get to them via hostname.companyname.local or hostname.companyname.com fails in mac OS apps (Safari, Firefox, Chrome, RDC, etc). However, if I use dig or nslookup in the terminal, it comes back just fine:

dig hostname.companyname.local

; <<>> DiG 9.8.3-P1 <<>> hostname.companyname.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16841
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;hostname.companyname.local.        IN  A

;; ANSWER SECTION:
hostname.companyname.local. 1200    IN  A   192.168.25.24

;; Query time: 3 msec
;; SERVER: 192.168.20.10#53(192.168.20.10)
;; WHEN: Thu Nov 20 11:36:49 2014
;; MSG SIZE  rcvd: 54

So, why does it work in Terminal and why doesn't it work in Mac OS? (Using Yosemite.) The answer from the previously linked thread about bouncing mDNSResponder sounded promising, but that doesn't appear to exist in Yosemite.

Answer 1

When your local area network has been configured with a domain name ending in .local, then all LAN hostname resolutions queried by a Mac (~10.3-10.10) will be passed to mDNS first - bypassing unicast DNS!

Dig and nslookup are unicast DNS utilities, so they will both bypass the system hostname resolution order (files->mDNS->DNS) and query unicast DNS directly.

You may fix this by changing the local domain name to use a TLD other than .local.

This is very common in split-horizon DNS and heterogenous but Windows-dominated company networks. A lot of Windows sysadmins are used to the .local TLD as valid private TLD name since at least a decade.

Answer 2

Why does it work in Terminal and why doesn't it work in Mac OS? The answer to your first part is in man dig or man host:

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.

To answer the second part, I would run a packet trace and see if the query packets are going out, and if so, to where? tcpdump -i en0 -vnnt "udp port 53"

mDNS is for Bonjour discovery; I don't believe it has much to do with standard DNS but don't quote me on that.

Answer 3

We have a similar ongoing problem at our company. As far as we can tell, it seems like for some reason the OS stops appending some host names with the default search domain.

I wrote a simple script to fix it that changes the default search domain to google.com, pings the affected host (which fails), then changes the default search domain back to empty. It works but does not fix the root cause of the problem. This script only changes the setting for the wi-fi interface because that is all we need, please keep that in mind.

networksetup -setsearchdomains Wi-Fi google.com

sleep 3; ping hostname

sleep 3; networksetup -setsearchdomains Wi-Fi empty