Mac OS X DNS lookup seems to be messed up - but only at work

Question

Mac OS X DNS lookups take forever from Safari and other applications that use mDNSResponder. The same lookups work fine if I use nslookup from the command line, and they also work fine from my iPhone and iPad on the same wireless network.

And that's only on the network at work; when I'm at home, or tethered to my iPhone, all DNS lookups work fine. When I'm on the network at work, either via Wi-Fi or Ethernet, I have these problems. I've tried using the following commands:

launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
launchctl load /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

That used to provide some temporary relief (minutes) under Snow Leopard, but now, under Lion, it usually doesn't provide anything at all.

Neither my Ethernet nor Wi-Fi settings specify DNS servers; they're auto-filled from the router. But I have tried specifying my own, like Google DNS or OpenDNS, and that doesn't fix the problem.

The network setup is a router plugged into the cable modem, with all Ethernet ports in the office coming off of it. An Airport Extreme wifi router is also plugged into the main router (in bridge mode), and the WiFi clients connect to that.

I've searched all over and found other things that look applicable at first (e.g. DNS lookup problems Mac OS X - but nslookup works!), making me think that these mDNSResponder issues aren't too uncommon, but none of them exactly match and their solutions haven't worked for me yet.

Also: it's not every DNS lookup, just most. Google searches come up instantly, but Google Maps takes forever to load (when I look at the activity window, it's usually scripts and whatnot coming from some Google CDN server). Even sites that we use every day, and you'd think would be cached someplace (like php.net) take forever to load, or time out.

Also: everything loads fine from a browser within a Windows XP virtual machine, which to me points even more accusingly at mDNSResponder as the culprit - but everything works fine when I'm any other network.

Answer 1

The reason for DNS being slow at the office but not at home, might be that the office router uses IPv6 but your home router uses IPv4, and that Lion is better on using IPv6 than Snow Leopard. The websites that are not affected by that slowdown are then probably the ones that have better support for IPv6.

See this article for measures that show IPv6 to be 2-3 times slower than IPv4 on DNS :
IPv6 Will Slow You Down (DNS)

If that's the case, disabling IPv6 on the office router (and so on the entire office network) might solve the problem.

This article might also be useful : How to Disable IPv6 on Mac OS X 10.7 Lion.

Answer 2

I used to have the same problem with my MacBook Pro running 10.6. I rarely ever turn my machine off. Basically at home I just close the lid and put it in my bag and take it to work. At work I open the lid and off I go. What I have noticed is that OS X doesn't seem to do this transition quite as seamlessly as I would like. I would get slow DNS, large amounts of waiting network resources, etc. What fixes it for me is manually disconnecting from each network before I close my machine (ie turn airport off before I close the lid). If I don't do this, my standby is to:

dscacheutil -flushcache

Either way works pretty well for me. On a rare occasion I restart the machine.

Answer 3

Do other Macs work correctly on the office network?

Make sure the network settings being assigned are self-consistent. I have seen the situation where a DHCP server was assigning a default gateway that wasn't on the client's subnet. Windows went ahead and used that, and worked fine, but MacOS(correctly!) refused to send to an IP address that wasn't on the subnet.

When the subnet mask is applied to both the client's IP address and to the default gateway, the results should be equal. Otherwise, it's a bad DHCP server config.

This doesn't sound like that exact situation, though. Is your Mac configured to use both the WiFi and Ethernet at work? If so, try turning one at a time off.