I had the same problem on my Mac, and after fixing it I have figured out that it was caused by FortiClient (VPN client). Even when FortiClient was disconnected - it's DNS still appeared in the scutil.
The solution for me was:
scutil
> list ".*DNS"
This will show you a list of all DNS configs, that will look something like:
subKey [0] = State:/Network/Global/DNS <br>
subKey [1] = State:/Network/MulticastDNS<br>
subKey [2] = State:/Network/OpenVPN/DNS<br>
subKey [3] = State:/Network/OpenVPN/OldDNS<br>
subKey [4] = State:/Network/PrivateDNS<br>
subKey [5] = State:/Network/Service/forticlientsslvpn/DNS <br>
To check each of them run: (until you find the problematic one)
> get key_name
> d.show
…and to fix it run:
> get key_name
> d.remove ServerAddresses
> set key_name
This is how it looked on my machine:
> get State:/Network/Service/forticlientsslvpn/DNS
> d.show
<dictionary> {
ServerAddresses : <array> {
0 : 192.168.30.6
1 : 192.168.30.15
}
SupplementalMatchDomains : <array> {
0 :
}
SupplementalMatchOrders : <array> {
0 : 100000
}
}
> d.remove ServerAddresses
> d.show
<dictionary> {
SupplementalMatchDomains : <array> {
0 :
}
SupplementalMatchOrders : <array> {
0 : 100000
}
}
> set State:/Network/Service/forticlientsslvpn/DNS
> exit
First, if networksetup -getdnsservers <service name>
does not show anything, you don't have anything listed in System Preferences > Netowrk under "DNS Servers:".
Second, it is important to note that OS X does not handle DNS like most systems. Per https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man5/resolver.5.html Essentially this means that OS X has multiple DNS clients depending on your configuration. The result of these multiple services means that there are situations whereby using Safari to access a website (http://www.example.com) will take you to an IP address that OS X has retrieved from DNS (say 1.2.3.4) while at the same time, performing a dig
$ dig www.example.com
will return different results. (perhaps 2.3.4.5)
The reason for this lies in the way that OS X handles DNS.
If you run $ man dig
you get among other things, the following:
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.
Also $man nslookup
will return something similar
Mac OS X NOTICE
The nslookup 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 nslookup 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.
All this is really a rather lengthy way of saying, the best way to see what DNS servers are being used is to look at System Preferences > Network
The "DNS Server:" entires are usually there, and "Search Domains:" will allow you to search for incomplete addresses.
If "DNS Server:" is not present, then OS X will try to use the address in "Router:" for DNS.
AND, on top of all this fun, there are utilities and other processes that may not be using the OS X DNS Routing Library, and they will be hitting the contents of /etc/resolv.conf directly.
The short short answer is this:
- If you go by the contents of System Preferences > Network, you are looking at the same thing that most processes are using.
- The Contents of System Preferences > Network, should populate /etc/resolv.conf, but not always.
- Some other processes (like dig and nslookup) are accessing /etc/resolv.conf directly.
And, on top of all this - If you are not using the VPN clients built in to OS X, it is possible that additional routes and DNS servers are being used that networksetup -getdnsservers <service name>
will not show. Your VPN client may have the ability to show you the routes and DNS servers, I know that mine does.
I know that this does not precisely answer your question, but hopefully this helps you realize that it is not always easy to find out what the "truth" is regarding DNS on a Mac. Generally you are safe assuming that the contents of System Preferences > Network, or the contents of networksetup -getdnsservers <service name>
are where you are getting your DNS from. However if things seem weird, keep in mind that there are other possibilities too. Use dig to help determine if there are differences afoot.
Last, for those readers who are wondering how to get the <service name>
in networksetup -getdnsservers <service name>
, try using networksetup -listallnetworkservices
Bill
Best Answer
Why they made this change, I don't know, but it's driven me crazy for a while.
I don't know why things work for host, but not ping, but I think it has to do with the nature of these two utilities. Ping is a simple (although very helpful) diagnostic utility for dropping packets on the wire that should get echoed back to you. The hostname lookup functionality is just a side effect of the job and handed off to the system's recursive resolver (I believe -- I haven't verified by checking linked libraries or anything of that sort). Host's main job is to do DNS name resolution, so it implements its own recursive resolver.
Apple's recursive resolver is mDNSResponder. For some reason, the version of mDNSResponder in Lion needs the "-AlwaysAppendSearchDomains" command line option to behave as it did in Snow Leopard (at least).
Here's a quick way to fix it:
(There should be two tab characters at the start of the second-to-last line above, but I couldn't figure out how to get this little editor to insert tabs, so I added 16 spaces. Either should work, but the tabs fit the spacing of the original file better.)
This will add the "-AlwaysAppendSearchDomains" argument to the mDNSResponder startup plist file (and save a backup copy), but since this is controlled by launchd, that system needs to be told to restart mDNSResponder.
Now, if you check your running mDNSResponder process, you should see it running with your new argument:
(Props to http://www.makingitscale.com/2011/fix-for-broken-search-domain-resolution-in-osx-lion.html and http://kavassalis.com/2011/07/wtf-bug-in-os-x-10-7/, where I found my answers to this problem.)