X

Safari Connectivity (#4): More details, more solutions

Safari Connectivity (#4): More details, more solutions

CNET staff
4 min read

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

  • yesterday's report
  • "Domain Health Survey"
  • Late-breakers@macfixit.com
  • More from Late-Breakers