Snow leopard broke my dns

Update:

Apple closed my bug:

<pre>Mac OS X internal name resolution often uses DNS servers in reverse order</pre>

as a duplicate of Bug ID #6928835, so they know about it and are investigating it.

Snow leopard had some strange DNS settings in the network preferences (airport, advanced) greyed out - they were screwing up my connection. I took the DNS settings from my router (the ones supplied by the ISP) and entered them in the network preferences, this fixed the problem for me.

William Kucharski wrote:
The external record is coming from somewhere - Mac OS X isn't just making it up.

So either a manual DNS server is specified somewhere that is being queried, or the SmoothWall is occasionally returning the external entry.

Either way, it sounds like a problem that can be solved in configuration.

I sure wish I knew where. It's just completely bizarre. I've never had issues like this prior to Snow Leopard. No other system does anything like this (some Leopard, some OS 9, some ugh Vista, and a lot of Linux). It's just my one Snow Leopard box. Makes me think it's not SmoothWall.

Scott

jafau wrote:
Snow leopard had some strange DNS settings in the network preferences (airport, advanced) greyed out

Settings that are greyed out are those being provided to you by your DHCP server.

Typically this is your router, and routers often advertise themselves as the DNS server so that all queries go through the router and it can cache the results from all lookups done on the network to provide faster service.

What you've done is bypass the router and are directly querying your ISP's name servers each time.

However if you were having problems before that means there is a bug or some other issue with the way your router handles DNS requests.

Hello, i found this tip to resolv the same problem:
http://www.jackenhack.com/archives/2009/09/08/dns-problems-with-snow-leopard-10- 6/

Unfortunately that has nothing to do with the precise bug being discussed here, where mDNSResponder is deciding to alter the order in which DNS servers are queried from that provided manually or by a DHCP server.

That issue remains extant in Mac OS X 10.6.1.

I was having DNS problems with Snow Leopard and tried a ton of stuff to fix it. I finally got it fixed.

My problem had nothing to do with DNS. To find the problem, I ran a "verify disk" in Disk Utility and found a Invalid Sibling Link. I followed the instructions at http://www.macosxhints.com/article.php?story=20070204093925888. Basically, it says run fsck_hfs -r /dev/disk0s2 while booting from the install CD and unmounting the drive. I had to run fsck_hfs -f /dev/disk0s2 before the problem was fixed. The disk was successfully repaired, and I am back on the internets.

Even if you don't have a "Invalid Sibling Link" error but you do have some other error on the disk, try just doing a "repair disk" in Disk Utility.

I really hope this helps someone out.

William Kucharski wrote:
That issue remains extant in Mac OS X 10.6.1.

I still see it in 10.6.2 😟

Yep - still there in 10.6.2, but it wasn't on the list of issues 10.6.2 addressed, either.

I've no idea of whether it's something Apple considers proper behavior or if it just hasn't escalated far enough to be addressed.

Either way it would merely be speculation for me to comment further on its status (and speculation is against the AD Terms of Use), so your guess is as good as mine.

At some point in this thread a bug was reported and then closed as duplicate. Can anyone here report on the status of the surviving bug report (without breaking rules)?

We have the same problems. If this isn't fixed we are going back to 10.5. Then we would have to go back to 10.5 with the server also.

Would be useful now to understand if this is happening to all the new installations or just from migration (from Leopard to Snow Leopard), and also which kind of carrier... because in my case, this happens only connected to DSLs... not in the Office LAN/WAN (where there is a proxy...).

I say this because it seems the percentage of the mDNSres failures is higher on machine coming from migration and discretely lower with clean installations...

RobertLHoward wrote:
At some point in this thread a bug was reported and then closed as duplicate. Can anyone here report on the status of the surviving bug report (without breaking rules)?

Probably not.

Apple's bug reporter only allows you to check the status of bugs you opened yourself.

Therefore if a bug is closed as a duplicate, you are given the bug ID of the original bug, but cannot check its status.

So unless the creator of that bug is reading this thread, we'll never know unless it's fixed in a future update.

gpy wrote:
because in my case, this happens only connected to DSLs... not in the Office LAN/WAN (where there is a proxy...).

That's because in an environment where you have a web proxy your DNS settings are not relevant for external queries, the proxy does it's own DNS lookup (since it's the "client" connecting to the "web server")

There seems to be some confusion as to how the resolver handles DNS entries (on top of the fact the Apple has acknowledged that on some occasions it will read them in reverse order).

1) When querying DNS the secondary (and tertiary) entries are for use when the primary does not respond at all, meaning is down or otherwise unreachable. It is NOT a cascade where if the first one doesn't have the answer to your question then the client will try the second and third. If the primary is reachable but can't resolve the response is the equivalent of "no such host" and that's the end of the conversation, the second and third DNS servers are not used.

2) The resolver does not necessarily start "at the top" every time you make a DNS query. If the primary DNS server is unreachable the resolver tries the second one. If the second one answers the resolver may essentially blacklist the first one and keep using the second one until the resolver is reset. Otherwise every query will be subject to a (normally 5 second) delay because it's retrying the unreachable primary every time. This is why a dig command may succeed to resolve, since you're query a specific name server, whereas another application may fail since it's using the DNS server that is currently preferred by it's resolver instance, which may not be the same server.

On another note. An IT staff that uses internal DNS but also passes along external DNS server addresses so that if internal goes down clients can still get to the internet has not been educated properly. You should only ever use internal OR external, not both.

In the Windows (Active Directory) world you use internal only, period. This is canon and is not debatable or flexible and anyone who says otherwise is undereducated.

Outside of Windows there are still plenty of issues to be found. For example, a resolver may be configured to rotate the DNS servers for load balancing purposes (typically a non-default option). Say you have two internal DNS and two external DNS configured. Since the resolver is rotating through the DNS servers your requests for resolution of internal hosts are going to fail 50% of the time when they go to external servers that have no idea what your internal DNS is.

I understand the "if internal DNS goes down you can still get to the internet" argument and why it seems reasonable on the surface. As a consultant I've seen it done MANY times and in every case the reason I came to know that it was done is because I was called in to fix some type of problem that inevitably tied back to DNS. Rest assured that many more problems have been solved by REMOVING those external servers than web surfing minutes have been saved by having them there.

If you're in a home where your router is your DNS server then there is no reason to use external DNS on your client because if your internal DNS goes down it's because your router is down which means you're not going anywhere anyway.

If you run your own internal DNS server where if DNS goes down you could still reach the internet and are tempted to configure clients to use external DNS "just in case", don't. The proper solution is to set up a second DNS server.

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.