Safari Connectivity (#4): More details, more solutions
We continue to cover an issue where Safari can't connect to some sites on the first try, but (for most users) will eventually load the desired page after several tries.
The primary cause of this issue now appears to be an apparent flaw in the way that Mac OS X handle DNS requests. It appears that the Mac OS X DNS lookup mechanism (which queries a DNS server for the appropriate IP address of a given domain name, e.g. 64.236.16.84 for "cnn.com") times out too quickly. Simply put, Mac OS X queries the domain name, waits a brief time period for the response, and times out before the response happens.
Specifically, it appears that Mac OS X has trouble dealing with IPv6-formatted responses from a DNS server (see yesterday's report). MacFixIt reader Scott Haneda confirms:
"As it turns out, at some time in the past, the root servers were changed in the way they send out responses. In a Ipv4 world, A records are sent back, in a IPv6 world, AAAA records are sent back instead. Safari chokes on this. It has been explained to me, but I can not confirm, that this is not a bug in BIND, not a bug in OS X, and not a bug in Safari, but one that goes deeper into the core of OS X. It is more than likely a issue with IPv6 in the BSD subsystem. It is also apparently a known issue that is yet to be resolved.
Haneda, who runs his own small ISP, notes that this problem will manifest more often for users whose ISP runs Mac OS X or BSD as a name server:
"End users who are using a ISP that is running OS X or BSD as a name server, specifically freeBSD, will certainly have this problem. I also suspect pretty much anyone on the Apple network may also have this issue as well. Every name server out there running BSD will need to make a change to their configuration in order to solve this. The easiest thing would be to have Apple release a patch, in the mean time, you can deal with it on your own.
Haneda also has echoes earlier suggestions for modifying the BIND startup file -- on the ISP end, or if you are using an in-house domain name server:
"If you are not a server admin, you need to contact your ISP and ask them to make the following changes. If you are a server admin, you will either need to wait for a official fix or work it out on your own. [...]
"If you have access to your recursive resolver, and it should be noted that if you do not offer recursive resolving, this issue more than likely will not affect you, please do the following:
"On BIND 9.3.0 and above, simply kill BIND and start it with the -4 flag, which is apparently a undocumented flag to force BIND into IPv4 mode only. You may also want to add edns-udp-size 512; to your config file in the options directive.
"If you are using BIND 9.2.x, you will need to upgrade or recompile with the --disable-ipv6 option. This was my first test, and was less than perfect. It only slightly seemed to resolve the issue. At this time I am running BIND 9.3.0 with the -4 flag and this seems under light testing to have solved it for me."
Turn off IPv6 connectivity in System Preferences Meanwhile, a handful of readers report that turning off IPv6 connectivity in the network pane of System Preferences resolves this issue for some ISPs. One reader writes:
"After reading the stuff on Safari connectivity I went to Network setup and set IPV6 connectivity to OFF on the Airport panel (I connect to my SWB DSL line through Airport/PPPOE). No more missed connects after a dozen or so tries. Is it fixed? I dunno -- it may start missing again any minute."
Using DNS servers from other ISPs Meanwhile, Ramsey French notes that you can use alternative DNS servers -- other than the ones directly provided by your ISP -- which may have faster response times, or may not be using BSD or Mac OS X on the domain name server, hence avoiding this particular issue:
"Most people think they only can use the DNS from their ISP. But in reality, any DNS will work since it is just a lookup table of IP's. Choosing your ISP's DNS is preferred because it is the closest and should return IP's quicker. But if the ISP's server is slow or bogged down, DNS (servers) of any other ISP might be better."
As noted yesterday, manually entering your ISP's DNS servers, or another set of DNS servers (which can generally be obtained from your ISP's Web site, a phone call to their support line, or from another user who is utilizing a fast DNS set of servers) in the Network pane of System Preferences works to resolve this issue. With manually entered DNS addresses, Mac OS X does not have to take the extra step of locating the servers and hence processes more DNS query requests on the first try.
Check out the "Domain Health Survey" by Men and Mice for some further information.
Feedback? Late-breakers@macfixit.com.
Resources
I built BIND 9.3.0 and installed it in /usr/local, and created a new StartupItem for it, while disabling OSX's 9.2.2 version.
I'm giving it the "-4" flag ("/usr/local/sbin/named -4"), set the forwarder to my ISP's DNS servers in /etc/named.conf, and also added the option "edns-udp-size 512;".
I am, of course, using the localhost (127.0.0.1) as my resolver.
This cocktail of settings does seem to greatly reduce the occurrance of this error, but it still crops up every once in a while.
I also want to note that I was getting these lookup errors even when I was directly using my ISP's DNS as my resolver.
Using Windows XP as a DNS client of my G4 (when still using OSX's built-in BIND 9.2.2 and no special options), these lookup errors didn't occur on it.
All of this makes me wonder if the problem isn't with the functionality of BIND on OSX, but rather some problem with the OSX resolver (lookupd and/or DNSAgent)?
Sure hope Apple come up with a fix soon!
settings for the interface (built in ethernet, Airport) that you use and way
down at the bottom if you see a little button which says 'Configure IPv6...'
click that and set it to "Off." Hit the Apply Now button.
That should decrease the likelihood the lookupd resolver will time out from
trying to get IPv6 information.
Safari still has some bugs of its own to deal with in terms of the 'unable to
get data' problem the first time a hyperlink is clicked, but this should help
with the DNS issues.
Disabling the IPv6 did the trick for me, but it remains to be seen what other
side effects this might have on the system. But the 4 hardest sites for me to
load just popped up quick as can be.
experienced this problem on every machine on my network (Windows
included).
I edited my /etc/named.conf to include forwarders to my ISPs DNS servers,
and the problem seems to have disappeared. I've done all kinds of lookups
on domains that I would never go to (just guessing words), and they all
connect on the first try.
Here's an example:
<code>
options {
directory "/var/named";
recursion true;
forwarders { 123.456.789.001; 123.456.789.002; };
};
</code>
Hey!! Simple fix. In your Network Prefs, disable IPv6 addressing. Works fine
for me!!
I started having this problem of not connecting to sites on the first
click after installing the last set of Apple software updates. I'm not
sure exactly when it started happpening, but certainly within the
last three weeks. It happens on all browsers that I use, Safari,
Firefox and IE. I've just tried the IPv6 suggested fix and have not
reached a conclusion yet as to whether it helps with the problem or
not. But this certainly is a frustrating problem.
the same symptoms with Explorer -- can't log on to sites; after first
try, it usually goes through. Anyone else experiencing the same?
- by 123 November 5, 2004 3:03 AM PST
- You can also try editing your /etc/resolv.conf and setting the timeout. Since
- Like this Reply to this comment
-
(9 Comments)OSX seems to make a symlink to /var/run/resolv.conf, on most systems (as
root),
cd /etc
rm resolv.conf
cp /var/run/resolv.conf resolv.conf
echo "timeout 30" >> resolv.conf
or so. Increasing the timeout further should also help (since "This time
interval is divided by the number of nameservers and the number of retries
allowed for each nameserver.")