Update (see comments for details): dscacheutil -flushcache at a terminal window fixes this for me.
I have been experiencing some intermittent and very strange problems with Firefox and Google. These began right after I upgraded to Mac OS X Leopard, and I'm not even sure where to start debugging this. The symptoms are simple enough: Firefox suddenly cannot resolve any Google.com address after OS X awakes from a nap.
The first few times this happened I thought it was just coincidence - maybe Google was down or more reasonably some Verizon router was confused. But it didn't make sense that this would happen after waking from sleep, so I blamed Verizon or my router, because rebooting that would fix the problem.
Realize that while Firefox is unable to find any google.com site (gmail, adsense, analytics, whatever), any other browsing seems to be fine. Of course I can't say that absolutely, because there could be other domains thar will not resolve, but so far I haven't noticed any: just Google.
Here's where we move into "this makes no sense!" land. When Firefox refuses to find Google, all I have to do is switch over to Safari and load any Google site. When I go back to Firefox and click "Try again" or just click the bue Reload button, Firefox will now know where Google lives.
Hmmm.. so my thinking is that this has to be a local issue - either my Verizon router or the Leopard resolver code. Obviously the resolver code is more suspicious as the problems started after upgrading to Leopard, but it does seem odd that resetting the router has fixed this.
But the "fix" is just black magic at this point. I can't easily reproduce the symptoms: it doesn't happen every time the Mac snoozes. Therefore I don't get a lot of chances to see what actions will or will not fix it - it may be days before it happens again.
If it is resolver code, the next question is what is Firefox asking that Safari is not? It could be something like a Truncated DNS issue, but "mail.google.com" etc. don't give truncated dns info. Yet it would seem to be something like that, because Safari gets an answer but Firefox doesn't.. until Safari fills the resolver cache.
If you are totally confused by DNS, I recommend Take Control of Your Domain Names, a $10.00 PDF E-Book that demystifies all of this.
So, my theory so far is this: after sleeping, sometimes google.com is not in the resolver cache and Firefox is not asking it to go look farther. Safari apparently does, and that fills the cache, so now Firefox works. Good theory, but how do I test that?
There's a Mozilla page that explains
(link dead, sorry)
their DNS strategy that might help figure this out.. and I also notice that there is mention of a network.dnsCacheExpiration key that can be set - though I don't see that in my "about:config".
My next thought was to see if anyone else had ever observed similar symptoms, and it turns out that yes, they have: this newsgroup post reports very similar behaviour, and interestingly enough that person solved it by implementing a local caching DNS.
This page suggests that
IPv6 support in Firefox causes slow lookups
(link dead, sorry)
and gives the solution of setting :
network.dns.disableIPv6 user set boolean true
and another site includes posts from people who
with have also experienced this problem. Firefox
itself suggests that disabling IPv6 is a likely fix:
(link dead, sorry)
Firefox cannot load web sites but other programs can
But why Google and not other sites? I do notice that Google uses "Pragma: no-cache" in its response headers, but doesn't set a page expiration date. Should that cause Firefox to behave differently? If it is IPv6, why did I first see it with Leopard?
Well, maybe because IPv6 is now automatic in Leopard. You can
shut it off
System Preferences->Network->Advanced->TCP/IP tab-> Configure IPv6
This page says that having it on may cause other Leopard Networking problems.
See OS X wake from sleep network problems also.
So, I've set IPv6 to "off" for now in both my wired and wireless connections, and we'll see if the problem goes away.
By the way, the Mac OS X man page for "dig" warns:
The dig command does not use the host name and address resolution or the DNS query routing mechanisms used by other processes running on Mac OS X. The results of name or address queries printed by dig may differ from those found by other processes that use the Mac OS X native name and address resolution mechanisms. The results of DNS queries may also differ from queries that use the Mac OS X DNS routing library.
That doesn't help finding weird resolution issues, does it?
Got something to add? Send me email.
More Articles by Anthony Lawrence © 2012-07-07 Anthony Lawrence
I just had to take the hypertext idea and connect it to the TCP and DNS ideas and — ta-da!— the World Wide Web. ((Tim Berners-Lee)