Snow leopard broke my dns

MuddyBulldog wrote:
The bug in Snow Leopard where it reads DNS servers in reverse order is a bug, yes. But it's not the problem. It's simply more visibly exposing the configuration issue that is the actual problem.

Except in the case where the secondary DNS server is on a slow link and is intended only to provide connectivity in the case where the primary is down.

That's a correct configuration but can cause difficulties in this situation.

William Kucharski wrote:

MuddyBulldog wrote:
The bug in Snow Leopard where it reads DNS servers in reverse order is a bug, yes. But it's not the problem. It's simply more visibly exposing the configuration issue that is the actual problem.

Except in the case where the secondary DNS server is on a slow link and is intended only to provide connectivity in the case where the primary is down.

That's a correct configuration but can cause difficulties in this situation.

Yes, that is where this bug rears it's head though no fault of the client configuration.

I know that, but even when connected thru tethering, same story...more reliable than at home. It seems like an incompatibility of SL with some DNS settings residing on the carrier side (I mean, the DSL provider)... which is not happening with Leopard (it's incredible, but at home now we use the spare macbook with 10.5.8 to surf the web and act as a proxy, sharing the internet connection...)

gpy wrote:
I know that, but even when connected thru tethering, same story...more reliable than at home. It seems like an incompatibility of SL with some DNS settings residing on the carrier side (I mean, the DSL provider)... which is not happening with Leopard (it's incredible, but at home now we use the spare macbook with 10.5.8 to surf the web and act as a proxy, sharing the internet connection...)

Again due to a difference in the resolution methodology. When you tether the default gateway and DNS servers get forced to that of the tethering provider disregarding any problematic DNS configurations that may be present on the client.

This posting is so helpful that it should be used as the basis for a section in the Mac OS X Server system administration manuals and/or a tech note. It is the sort of clear and detailed information that system administrators need to make sure things work properly. It is particularly important because design decisions in the implementation of DNS resolution in Snow Leopard were made with certain assumptions of correct practice in mind, and these practices are neither universally known nor universally adhered to.

(The documentation group will no doubt take care of changing the tone from conversational to documentation-style. 🙂 )

So the solution would be which one?

a) waiting for a possible resolution on 10.6.3 (even if I doubt it will never arrive, as the problem is happening only with certains combinations of SL + DSL providers)
b) call the provider and have them update their DNS Servers? (and which one and/or which versions they should get?)
c) rollback to Leopard?

I got the third option at the moment... do you know if there is an open bug for this issue?

funny enough the fact that the exact configuration under leopard (and when I say exact I mean absolutely identical) allow us to surf, move, browse sites very fast... in SL dns can't resolve major cdn sites like gstatic or m0.google.com to m(n) of google maps... leaving us with huge white block on un-rendered sites... under leopard, same browser, version, machine... works great!

Message was edited by: gpy

A Cisco Anyconnect VPN split DNS configuration is a legitimate use case completely busted by this Snow Leopard bug. A typical setup looks something like this:

resolver #1
domain : vpn.domain
nameserver[0] : <vpn-resolver-ip>
nameserver[1] : <standard-isp-resolver-ip>
order : 1

The intent is that non-VPN hosts will be cascaded from the vpn-resolver back to the standard-isp-resolver, and VPN hosts will be resolved by the vpn-resolver. However, due to this bug, the former works still but the latter intermittently fails because it sometimes sends VPN hostname lookups to the standard-isp-resolver first.

The only workarounds are to keep bouncing the mDNSResponder or move away from a split-DNS policy.

I really hope Apple fixes this in 10.6.3 which I hear rumblings is imminent. This is a terrible bug.

I understand, but it seems a little strange to not have your internal DNS be a cacheing server since it would be asked to resolve every address first in even a traditional BIND environment…

How many VPN users have the wherewithal to set up their own DNS server? This is a very common deployment with VPN solutions -- I've seen it with OpenVPN as well.

It's taken me ages to get here as Safari couldn't find my server AGAIN. Since upgrading my system to 10.6.x I have not been able to successfully access the internet without constant timeouts, safari not finding servers, I cannot send attachments in my mail because it times out every few minutes. Aperture cannot upload to servers anymore. The other machine on the network runs leopard which I have to use until I rollback to Leopard on this machine.

Apple as usual are keeping quiet and pretending the problem with dns dropouts on SL do not exist. So I think I'll give it until january and see if there's a fix in the next update as I have tried everything suggested by worldwide forums documenting the problem. *January rollback here we come along with the return of my sanity!!!!!*

This is a strange solution, but I have found a way for my clients to re-connect without having to restart. In all, create two identical locations. When your network connection goes down, toggle the location to the other one. Toggling to the other location (in this case the network uses DHCP) renews the network.

You're not the only one. I have a simliar setup, with only a single DNS server being supplied by DHCP to my clients behind my firewall. That DNS server provides internal addresses for all of the resources behind the firewall, and forwards all other requests to my ISP's DNS.

My mac running SL knows only about the single DNS server behind the firewall; but every once in awhile, it somehow gets a DNS response that could only come from some DNS server outside the firewall. It seems to cache this response, because immediately after, I can still submit a query for another device that is behind the firewall but definitely hasn't been cached, and I get the correct response.

It doesn't seem to be the mDNSresolver switching to another DNS as described by others, because there are no other DNS servers to switch to, and other queries performed immediately after the problem get resolved correctly.

I'm certain that there is only one DNS server configured. I've double-checked the DHCP server configuration, I've tried manually overriding the DNS configuration, I've checked the contents of /etc/resolv.conf and the output of scutil --dns, and there is only the internal DNS server.

It's like mDNSresponder really is pulling some other DNS server out of thin air to use every once in awhile.

There is a bug in 10.6.2 in my opinion. I have started a discussion over at the Ars site. Check it out.

http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/845000282041

I am having the exact same problem.

Mac Mini: DNS server(BIND), SL 10.6.2
IP: 10.0.0.10/24 (STATIC)

MBP: Client, SL 10.6.2
IP: 10.0.0.96/24 (DHCP RESERVED)

10.0.0.10 is the only DNS server registered with the MBP VIA DHCP, and there are no other entries in the network control panel advanced/DNS section -- Sometimes, it resolves internal IP's properly, sometimes not. External IP's are always resolved properly.

dig always works since it uses /etc/resolv.conf (which has only one nameserver entry pointing at , but MDNS Responder and the apps that use it don't reliably resolve local names.

This broke after upgrading my MBP to Snow Leopard, also note that I have an ubuntu 9.10 laptop and it consistently resolves all DNS just fine..

hopefully this will be fixed in 10.6.3...

NAS

I've done some more research, and there is something completely broken about DNS in Snow Leopard.

I've double and triple checked that I have only one DNS server configured via DHCP, and none configured manually. This DNS server is on a private lan with NAT to the outside world. The DNS server my SL box queries responds with private IP addresses. I've blocked outgoing dns queries on port 53 to the outside network, so there's no way mDNSresponder is rolling over to some other DNS server outside my lan. But even so, 15 to 60 seconds after flushing the dns cache, my local cache will get poisoned with outside addresses for some internal resources.

It certainly appears that SL is querying some hidden DNS server on a nonstandard port. If I block all access to the outside network at my firewall, my SL box never gets any bad DNS info. As soon as I unblock all access except for port 53, the problem comes back within 60 seconds, every time.