Snow leopard broke my dns

It looks like the update alone won't fix it. The new-and-supposedly-improved 10.6 behavior is still the default. You have to do a little bit of manual work to get the correct behavior:

Mac OS X v10.6.3 or later: How to change the DNS search order behavior
http://support.apple.com/kb/HT4030

mkerley wrote:
It looks like the update alone won't fix it. The new-and-supposedly-improved 10.6 behavior is still the default. You have to do a little bit of manual work to get the correct behavior:

Mac OS X v10.6.3 or later: How to change the DNS search order behavior
http://support.apple.com/kb/HT4030

Well, that's something, I guess.

I still don't see that as having anything to do with (or being able to fix the problem with) dynamic VPN-based DNS servers that are "tacked on" to the DNS server list in a split-DNS situation.

I'm no DNS or VPN expert, but it seems like the split-DNS mechanism is just broken in 10.6.x (it never checks the other split added by the VPN connection), so this article doesn't even apply to that scenario.

mkerley wrote:
It looks like the update alone won't fix it. The new-and-supposedly-improved 10.6 behavior is still the default. You have to do a little bit of manual work to get the correct behavior:

Mac OS X v10.6.3 or later: How to change the DNS search order behavior
http://support.apple.com/kb/HT4030

Yep, I think you're right...

https://forum.sonicwall.com/showthread.php?t=23633

Don

I applied this change and it seems to have no effect. I am using the Cisco Anyconnect VPN client, which is supposedly using Split DNS -- although it looks misconfigured to me:

$ scutil --dns
DNS configuration

resolver #1
domain : vpn-domain1.com
search domain[0] : vpn-domain1.com
search domain[1] : vpn-domain2.com
search domain[2] : vpn-domain1.com
nameserver[0] : 10.0.0.253 <-- VPN DNS server 1
nameserver[1] : 10.0.0.221 <-- VPN DNS server 2
nameserver[2] : 172.16.1.1 <-- local DNS server
order : 1

So what is happening is that sometimes the mDNSResponder picks my local DNS server to resolve vpn-domain1.com hosts and of course fails. So to work around this, I tried the knowledge base article to essentially force all DNS requests through the VPN every time. It did not work -- it still appears to hit my local server.

Two questions:

1) Has anyone else with Cisco Anyconnect gotten it to work with DNS and Snow Leopard?

2) Has anyone else gotten this Unicast hack to work?

Interesting...the article states:

" Summary
In Mac OS X v10.6 and later, the search order of DNS servers specificed in Network preferences is dynamic, so that servers that don't respond are moved to the end of the search order. This provides performance and reliability improvements over previous Mac OS X versions, but it can lead to unexpected results where a strict search order is required in Mac OS X v10.6.
With Mac OS X v10.6.3 and later, DNS servers can be searched in a strict order by making a change to the mDNSResponder plist as an administrator. Learn how in this advanced article."

...then in the end of the article it states:

"*Additional Information*
In Mac OS X v10.6, the default DNS server searching behavior is that when a server does not return a result (returning SERV_FAIL for a query), and other servers are available to query, the server is temporarily disabled in the search order for about thirty seconds. If there is more than one server for the query and all of them have returned SERV_FAIL, the servers will be queried in the order that they were disabled (that is, the server that has been disabled the longest will be used first)."

...so if I understand this correctly (*), if a VPN client needs more than the 30 seconds allowed in either of the above cases, connection may fail. I don't see where the 30 second time is set. I would like to test setting it to 120 seconds to see if my Aventail Connect client will work.


+(*) I wanted to confirm, since there's a glaring typo in the article..."mv" really needs to be "cp"...I already reported it to Apple.+

Don

And further, setting the plist as describe in the article causes my system to completely hang on reboot. Nice work, Apple.

Brian Dantes wrote:
And further, setting the plist as describe in the article causes my system to completely hang on reboot. Nice work, Apple.

The "mv" should be "cp". The instructions have you move the file out and rename it...but never move it back, so you're essentially unloading/loading a non-existant launchd item. 😟

I reported this to Apple. If you're able to get into Single User mode, "cp" the file back to the original folder and boot up. Next time use "cp". I really hope they fix this soon...

Don

No, I noticed that silly mistake in the instructions too. I edited the plist properly. It hung on reboot with the modified plist. I had to boot off another volume (even Safe Boot did not work) and move the old plist file back.

The instructions seem to have disappeared; currently, there is no mention of how to edit the plist. However, there is a copy here:

http://reviews.cnet.com/8301-13727_7-10471471-263.html

Note, that is seems to accidentally have you copy the plist file to a different directory.

So, I too was noticing that on certain pages, my browser would hang for 30 seconds. On my 10.4 machine, it did not.

I made the plist change and it didn't help. Note that I only had 1 DNS Server listed (my dsl router which in turn used two remote DNS servers plus provided lookup for my local network).

I kept the plist DNS change in place.

So, I went to Network in my System Preferences. I had Location set as Automatic. I created a new location, "home-test". There, I entered DNS Servers instead of letting it figure out automatically. I entered first the address of my router, then the address of the two DNS servers that my router currently uses (from my ISP).

Now, I no longer get a hang on a bad address. In fact, I can test by switching back and forth between "Automatic" and "home-test":

1) Automatic (30 second timeout)

% time ping someunknownhostisgone.com
ping: cannot resolve someunknownhostisgone.com: Unknown host
0.000u 0.001s 0:30.15 0.0% 0+0k 0+0io 0pf+0w

% time ping someunknownhostisgone.com
ping: cannot resolve someunknownhostisgone.com: Unknown host
0.000u 0.001s 0:30.15 0.0% 0+0k 0+0io 0pf+0w


2) home-test (quick timeout)

% time ping someunknownhostisgone.com
ping: cannot resolve someunknownhostisgone.com: Unknown host
0.000u 0.001s 0:04.05 0.0% 0+0k 0+0io 0pf+0w]

% time ping someunknownhostisgone.com
ping: cannot resolve someunknownhostisgone.com: Unknown host
0.000u 0.001s 0:00.00 0.0% 0+0k 0+1io 0pf+0w

So, Automatic repeatedly takes 30 seconds to time out. home-test takes 4 seconds the first time, then 0.

This fix seems to work (for now). But why? Who can explain?

I suspect, but do not know, that in the case of the 30 second timeout one or more of the DNS servers is not properly returning NXDOMAIN for the non-existent domain but is instead returning an error, causing mDNSResponder to try other DNS servers on the list.

If you are curious as to what's really going on, you can run the following command in Terminal while you do the lookup and see what activity goes by:

sudo tcpdump -n -i interface port 53

where interface is the name of your network interface (usually en0 for Ethernet or en1 for AirPort.)

When you are done, press "C" in the Terminal window while holding down the "Control" key.

You should see output like:

23:51:12.994948 IP 192.168.0.109.55672 > 208.67.222.222.53: 24595+ A? ibm.com. (25)
23:51:13.023554 IP 208.67.222.222.53 > 192.168.0.109.55672: 24595 3/0/0 A 129.42.18.103, A 129.42.16.103, A 129.42.17.103 (73)

William Kucharski wrote:
I suspect, but do not know, that in the case of the 30 second timeout one or more of the DNS servers is not properly returning NXDOMAIN for the non-existent domain but is instead returning an error, causing mDNSResponder to try other DNS servers on the list.

If you are curious as to what's really going on, you can run the following command in Terminal while you do the lookup and see what activity goes by:

sudo tcpdump -n -i interface port 53

where interface is the name of your network interface (usually en0 for Ethernet or en1 for AirPort.)

When you are done, press "C" in the Terminal window while holding down the "Control" key.

You should see output like:

23:51:12.994948 IP 192.168.0.109.55672 > 208.67.222.222.53: 24595+ A? ibm.com. (25)
23:51:13.023554 IP 208.67.222.222.53 > 192.168.0.109.55672: 24595 3/0/0 A 129.42.18.103, A 129.42.16.103, A 129.42.17.103 (73)

I tried and I think that you are basically correct. I'll post the output here once I decide that it's not a security risk to do so.

Looks like when I am configured with both my router and external DNS, there are a few requests in parallel and then an NXDomain response from the external DNS. Next time I do the same query, there is no traffic (must be cached locally).

With only my router, there is a ton of traffic. Lots that look like: FormErr.

It also looks like the result is not cached locally.

Seems like some kind of bad interaction between my router (a 2Wire supplied by ATT) and Snow Leopard. I bet it's a pretty wide spread problem.


On my Tiger OS iMac, the router correctly returns NXDomain.

I thought that I had a working setup. I kind of do, but it's flakey. Here is a sequence:

[imacman:~] jice% ping macman.gateway.2wire.net
PING macman.gateway.2wire.net (192.168.0.2): 56 data bytes
64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=0.637 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.620 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.638 ms
^C
--- macman.gateway.2wire.net ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.620/0.632/0.638/0.008 ms
[imacman:~] jice% ssh macman.gateway.2wire.net hostname
Password:
macman
[imacman:~] jice% ping macman.gateway.2wire.net
PING macman.gateway.2wire.net (192.168.0.2): 56 data bytes
64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=0.621 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.660 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.648 ms
^C
--- macman.gateway.2wire.net ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.621/0.643/0.660/0.016 ms
[imacman:~] jice% ping macman.gateway.2wire.net
ping: cannot resolve macman.gateway.2wire.net: Unknown host
[imacman:~] jice% ping macman.gateway.2wire.net
ping: cannot resolve macman.gateway.2wire.net: Unknown host
[imacman:~] jice% ping macman.gateway.2wire.net
ping: cannot resolve macman.gateway.2wire.net: Unknown host
[imacman:~] jice% ping macman.gateway.2wire.net
ping: cannot resolve macman.gateway.2wire.net: Unknown host
[imacman:~] jice% sudo killall -HUP mDNSResponder
[imacman:~] jice% ping macman.gateway.2wire.net
PING macman.gateway.2wire.net (192.168.0.2): 56 data bytes
64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=0.576 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.578 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.658 ms
^C
--- macman.gateway.2wire.net ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.576/0.604/0.658/0.038 ms

Seems that mDNSResponder gets confused and looses the ability to lookup a local name. I do have the plist "fix" set to use strict ordering. Did I do that right?


[imacman:/System/Library/LaunchDaemons] jice% cat com.apple.mDNSResponder.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.apple.mDNSResponder</string>
<key>OnDemand</key>
<false/>
<key>UserName</key>
<string>_mdnsresponder</string>
<key>GroupName</key>
<string>_mdnsresponder</string>
<key>ProgramArguments</key>
<array>
<string>/usr/sbin/mDNSResponder</string>
<string>-launchd</string>
</array>
<key>MachServices</key>
<dict>
<key>com.apple.mDNSResponder</key>
<true/>
</dict>
<key>Sockets</key>
<dict>
<key>Listeners</key>
<dict>
<key>SockFamily</key>
<string>Unix</string>
<key>SockPathName</key>
<string>/var/run/mDNSResponder</string>
<key>SockPathMode</key>
<integer>438</integer>
</dict>
</dict>
<key>EnableTransactions</key>
<true/>
<key>StrictUnicastOrdering</key>
<true/>
</dict>
</plist>

Hmmm. It's possible that I didn't properly unload and load the new settings. I'll try again and keep an eye to see if the order seems to be changed again.

Found this useful post:

http://superuser.com/questions/84144/how-is-dns-used-by-individual-processes