Snow leopard broke my dns

However the dscacheutil command is still the only way to show what Mac OS X's internal resolver has come up with.

*scutil --dns* gives the following, in full:

DNS configuration

resolver #1

search domain[0] : internal

nameserver[0] : 192.168.0.10

nameserver[1] : 192.168.0.254

order : 200000

resolver #2
domain : username.members.mac.com.
options : pdns
timeout : 5
order : 150000

resolver #3
domain : local
options : mdns
timeout : 2
order : 300000

resolver #4
domain : 254.169.in-addr.arpa
options : mdns
timeout : 2
order : 300200

resolver #5
domain : 8.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300400

resolver #6
domain : 9.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300600

resolver #7
domain : a.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300800

resolver #8
domain : b.e.f.ip6.arpa
options : mdns
timeout : 2
order : 301000

For my tcpdump I just did a *tcpdump -i en0 -vvv -n -s 0 -w DumpFile.dmp* and then scanned the dump file by hand with a *tcpdump -r DumpFile.dmp*. No filtering on port, name or anything, and still no mention of the first DNS server.

Your assumption is correct: 192.168.0.254 is indeed "smoothwall.domain", although it is not known by that FQDN by anyone. It knows itself purely by the hostname "smoothwall" or "smoothwall.internal", and the internal DNS server has a host record for it at smoothwall.internal. I have no idea where smoothwall.domain was generated.

Finally, my nameservers are not DHCP-specified; on this client they are manually assigned along with all the other IP information. However, DHCP on this network specifies exactly the same DNS settings, and Snow Leopard laptops that use DHCP do experience the same issue. I would therefore discount static or DHCP assignment of DNS servers as a factor (in my case, at least).

My fault, smoothwall.domain isn't an actual domain name, it's:

hostname. port

so it's "smoothwall" responding on the "domain" port. My bad.

That having been said, I can't imagine what's causing the resolver to not use your primary nameserver unless it failed a query and so mDNS has somehow marked that nameserver as "bad."

Snoop Dogg; nice pointer. As suggested, I performed a killall on the mDNSResponder and examined the system log (and man, there's a lot of stuff cached in there!).

The interesting bit is right at the end:
Sep 8 08:08:46 MacBook mDNSResponder[17]: --------- DNS Servers ----------
Sep 8 08:08:46 MacBook mDNSResponder[17]: DNS Server . 192.168.0.254:53
Sep 8 08:08:46 MacBook mDNSResponder[17]: DNS Server . 192.168.0.10:53
Sep 8 08:08:46 MacBook mDNSResponder[17]: Timenow 0x8B5C2C36 (-1956893642)
Sep 8 08:08:46 MacBook mDNSResponder[17]: ---- END STATE LOG ----

So, assuming the DNS servers are queried by mDNSResponder in the order shown in this list, mDNSResponder is indeed querying the DNS servers in the wrong order! - this would explain the behaviour seen, and supports my experience that only specifying the LAN DNS server (as opposed to multiple DNS servers) works.

Great! - how do we get Apple to fix this?

Barnski,

Thanks for all your responses to my queries.

I've just managed to reproduce your behavior somehow, and have filed a bug with Apple, RADAR #7204499:

scutil --dns shows:
resolver #1
domain : comcast.net.
nameserver\[0] : 208.67.222.222
nameserver\[1] : 208.67.220.220
order : 200000
Indeed, /etc/resolv.conf was generated as:
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
domain comcast.net.
nameserver 208.67.222.222
nameserver 208.67.220.220
But the output of "killall -INFO mDNSResponder" shows:
Sep 8 03:02:32 Sun-MacBookPro mDNSResponder\[27]: --------- DNS Servers ----------
Sep 8 03:02:32 Sun-MacBookPro mDNSResponder\[27]: DNS Server . 208.67.220.220:53
Sep 8 03:02:32 Sun-MacBookPro mDNSResponder\[27]: DNS Server . 208.67.222.222:53
The output clearly shows the DNS Servers in the REVERSE order of that specified.
This is confirmed by watching DNS traffic with:
$ tcpdump -n -i en1 port domain
The following behavior is seen:
1) A "nslookup microsoft.com." queries the specified name servers in the documented order:
03:07:50.338737 IP 192.168.0.104.56799 > 208.67.222.222.53: 38560+ A? microsoft.com. (31)
03:07:50.399542 IP 208.67.222.222.53 > 192.168.0.104.56799: 38560 2/0/0 A 207.46.197.32, A 207.46.232.182 (63)
2) A "dscacheutil -q host -a name dell.com." queries the specified name servers in REVERSE order as shown by the SIGINFO dump from mDNSResponder:
03:08:45.999752 IP 192.168.0.104.52265 > 208.67.220.220.53: 51153+ AAAA? dell.com. (26)
03:08:46.113500 IP 208.67.220.220.53 > 192.168.0.104.52265: 51153 0/0/0 (26)
03:08:46.448882 IP 192.168.0.104.65288 > 208.67.220.220.53: 44627+ A? dell.com. (26)
03:08:46.510262 IP 208.67.220.220.53 > 192.168.0.104.65288: 44627 2/0/0 A 143.166.83.38, A 143.166.224.244 (58)
Both sets of queries should have been made to 208.67.222.222.

I'll let you whether they have anything to add.

Good work William - thanks for that. I have also registered the problem at the feedback page -> http://www.apple.com/feedback/macosx.html

Keep us posted on progress, if you hear anything.

Will do.

The frustrating thing is that it's intermittent - the order of the nameservers seems to change - so I'm wondering if it's Apple's attempt to do some load balancing between DNS servers by switching off every so often.

Well, this may be my issue as well...will keep watching for updates...

Many Thanks for tracking this down and getting it in front of Apple, William and Barnski. I submitted a 'me too' on feedback and cited the RADAR number.

Does anyone know if this made it into 10.6.1? It wasn't listed as a corrected issue.

I've installed 10.6.1 this morning. I should know within a couple of hours. So far, so good. If Entourage stays connected to Exchange all day today then I'll assume it's been fixed. It has normally been going into a disconnected state within anything from 20 minutes to 2 hours.

Chingachgook wrote:
Does anyone know if this made it into 10.6.1? It wasn't listed as a corrected issue.

I've installed 10.6.1 this morning. I should know within a couple of hours. So far, so good. If Entourage stays connected to Exchange all day today then I'll assume it's been fixed. It has normally been going into a disconnected state within anything from 20 minutes to 2 hours.

My testing last night and this morning show the same bug is present in 10.6.1, unfortunately. 😟

I'm also not sure at this point whether it will be considered a bug or a feature as the same functionality is available in BIND >= 8.2 by specifying the "rotate" keyword in /etc/resolv.conf, so there is a precedent.

I don't want to speculate, though, so all I can say is I'll let you know if and when I'm contacted.

Sorry all, but I just installed 10.6.1 on a laptop here, and the problem still seems to be present 😟

Can anyone else confirm?

Yes, read above.

Nothing in 10.6.1 changed name resolution at all, and wasn't supposed to, according to the release notes.

At present Apple has not yet confirmed or denied whether the issues we're seeing is in fact a bug or a design decision done to perform the equivalent of the BIND "rotate" functionality.

Yep - still there. Still have to run a +sudo killall mDNSResponder+ from time to time.

I hope Apple either fixes or modifies the implementation so that the issue goes away. I don't relish the idea of trying to get our IT support bunch to modify the internal DNS to make it work with rotating DNS server use instead of cascading DNS server use. Add to that the fact that I'm the only Mac user on the internal network and it's not really supported. Could turn into an exercise in frustration.

On the other side, switching to a different DNS server on the client side every once in a while when all name resolution requests are being reasonably handled seems a useless 'feature' IMHO.

I'll watch this space.

Chingachgook, can you run "scutil --dns" in Terminal and post the results?