Change DNS search order on Mac El Capitan

Question

I've got a router that is also running a DNS that contains names for machines on my local network. It is set up to forward requests, so for any public machine it will reach out to the DNS provided by my ISP. The router is configured such that it is the primary DNS, and the ISP's DNS is listed as a secondary. I have a couple of machines (the ones with entries in my private DNS) that have static IPs. The other machines, including the Mac that is the subject of this question, get their addresses by DHCP.

Windows machines on this network are working perfectly. They resolve the private names to the machines on my network and also have access to the public internet.

My single Mac laptop is not working. It accesses the public internet with no problem, but it is not hitting my internal DNS to get the internal names. For example, if I do a ping to an internal machine as

ping internal.example.com

I get packets back, but it shows an IP address that corresponds to Hover. (Apparently Hover is putting up a landing page for any sub-domain for which there is no public route.) If I do

nslookup internal.example.com

however, I get the correct (internal) IP for the machine on my local network.

Finally, if I do ping again but this time force it to use my internal DNS (192.168.1.2),

ping internal.example.com 192.168.1.2

I get response from the correct machine on my local network. This seems to indicate even the "native" approach can do what I want, if it will just use the right DNS.

I've found a lot of articles that talk around this issue, but what I've actually found so far is either out of date or not a complete solution to my problem. What I've cobbled together so far:

• Apple has been changing its methodology for DNS resolution over the course of several OS upgrades, so answers online quickly become dated.
• The Mac has (at least) two DNS resolution schemes running concurrently as of El Capitan. This is related to getting different results from ping and from nslookup, as noted above. The command line utilities that work on the "usual" linux system seem to at least document this on their man pages, usually under a section titled something like "Mac OS X Notice." Unfortunately, it's not clear exactly which utilities use which without checking them one by one. (So far, it looks like nslookup and dig use the linux methodology and ping uses whatever is "native" to Mac OS.)
• It's a (more or less) documented feature of the "native" DNS method that it dynamically chooses which DNS to use. That means, in particular, that the order that appears in windows like the Network control panel or the order that's specified by the router (in my case), are not respected.
• I got some information from the "native" DNS tool with the command sudo killall -INFO mDNSResponder on the command line. That dumps messages into /var/log/system.log. From that log message, it appears that my ISP's DNS is listed first within that system. (Again, I note, that it is listed second in the configuration of the router and in the Network control panel. It is also listed second if I run scutil.)
• I tried flushing the cache on mDNSResponder using sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder; but that did not help.
• I tried editing the file com.apple.mDNSResponder.plist as in these instructions (https://www.cnet.com/news/os-x-10-6-3-and-dns-server-priority-changes/), but I was not able to edit the file. (Read-only, even with sudo vi.) In addition, the file on my system has different content than what's explicitly referenced in those instructions.

In net of all of this, however, I still have a Mac that's not working on a network full of other computers that work great. I could probably take out the ISP's DNS on the router so that it's not even offered, but that feels like a hack. Is there a good fix for this on El Capitan?

Sorry if this has already been answered. (I feel like it must be somewhere!) I've dug around on and off most of the day and haven't hit a solution on El Capitan so far.

Answer 1

macOS has a sophisticated system for DNS request routing ("scoped queries") in order to handle cases like VPN, where you might want requests for your work's domain name to go down your VPN tunnel so that you get answers from your work's internal DNS servers, which may have more/different information than your work's external DNS servers.

To see all the DNS servers macOS is using, and how the query scoping is set up, use:

scutil --dns

To query DNS the way macOS does, use:

dns-sd -G v4v6 example.com

…or…

dns-sd -q example.com 255 255

See the man pages for scutil(8) and dns-sd(1) for more information.

DNS-troubleshooting tools such as nslookup(1), dig(1), and host(1) contain their own DNS resolver code and don't make use of the system's DNS query APIs, so they don't get the system behavior. If you don't specify which DNS server for them to use, they will probably just use one of the ones listed in /etc/resolv.conf, which is auto-generated and only contains the default DNS servers for unscoped queries.

Traditional Unix command-line tools that aren't specific to DNS, such as ping(8), probably call the traditional gethostbyname(3) APIs, which, on macOS, make use of the system's DNS resolver behaviors.

To see what your DHCP server told your Mac to use, look at the domain_name_server line in the output of:

ipconfig getpacket en0

(replace en0 with the correct BSD-style interface name as you would see in ifconfig)

Please note, I'm pretty sure the DNS RFCs don't require DNS implementations to consider the list of servers to be ranked by preference. Although it's common for DNS implementations to treat them that way, it's probably not wise to rely on all implementations to implement things that way if it's not specified in the relevant standards.

Oh, also note that your Mac may also be getting DNS server lists from IPv6 router advertisements or DHCP6, if those are active on your network. And of course VPN settings, installed configuration profiles, Open Directory, Active Directory, etc., if any of those things are in use in your environment.