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:
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
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.
Increase ad revenue 50-250% with Ezoic
More Articles by Anthony Lawrence
Find me on Google+
© 2012-07-07 Anthony Lawrence