Safari Connectivity and Security Updates; potential causes, fixes, and more

Last week we resumed coverage of 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.

There is a strong correlation, but probably not a causation, between the inability to load pages in Safari (and perform other network operations) and the release of certain Apple Security Updates.

The primary cause of this issue now appears to be an apparent flaw in the way that Mac OS X -- specifically the BIND networking component -- 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.

This partially explains why manually entering your ISP's DNS servers (which can generally be obtained from your ISP's Web site or a phone call to their support line) 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.

In some cases, the DNS addresses must also be configured on a router if one is present.

MacFixIt reader Brent writes "I was able to resolve the problems by manually entering the DNS Servers for my ISP (Cox Kansas) in the Network Settings and on my router."

Reader Mike adds "We have gotten into the habit of entering the DNS server numbers for our ISP (Road Runner) in order to solve some connection problems. We set the DNS numbers in the (D-Link DI-604) broadband gateway router, and we also set the DNS numbers in all computers of our office LAN."

Finally, MacFixIt reader Set notes that you can sometimes find local DNS servers through a Web search "I did a search on the internet for DNS servers pertaining to my local area and service provider (Time Warner RR in Raleigh, NC), and found these 3:

• 24.25.4.107
• 24.25.4.108
• 24.25.4.109

"I added those to my Network Preferences, and the ones ending in 107 and 108 to my Airport Express DNS server list (because only 2 are allowed) using the Airport Admin Utility. In the last 6 hours, I have had only 1 error where the server couldn't be found (a second try found the site, however)."

Some users, like Doug Eldred, have different ISPs produce different results on the same Mac. This it seems that some ISPs may have slower DNS conversion mechanisms that others"

"One more observation on the Safari/DNS situation... I have Qwest/MSN DSL. For the past day or so, NO DNS queries worked at all. I tried repeatedly unplugging both the DSL modem and my AirPort Express Base Station, once for several hours, and rebooting the iMac, to no avail.

"One or more or my neighbors have unprotected 802.11* WAPs (one is "linksys", another is 'default'), so I 'borrowed' one long enough to convince myself that it wasn't the Internet as a whole, nor my computer or setup per se. Oddly enough, while using the 'borrowed' connection, I had few if any DNS failures on the first try which immediately worked on a second try, which I've been having on and off since one of the security updates was installed.

"[...]I was thinking of calling Qwest to see if they knew of any problems, when to my surprise I found an old document that gave the Qwest DNS server addresses back in January 2000. To my slight surprise (but not really "shock") they were still valid. Since specifying them, I've had no solid failures, few "first time fails, second time works" incidents, but I -do- still have an -occasional- first/second time incident, though much much less frequently."

A more complex, but more reliable fix MacFixIt reader Ken has discovered a clever workaround that involves modifying the operation of Mac OS X's "named" daemon -- the DNS server that is part of the BIND set of UNIX DNS utilities.

The theory behind why this fix works is as follows: root domain servers appear to have recently been given IPv6 capability, and are now returning AAAA records in response to name lookups.

Ken writes "The simple upshot is that for whatever reason, the first time named tries to go do a DNS query, it seems to decide to try sending to an IPV6 server address, which is pretty much guaranteed to fail for most users. Eventually this times out and it retries, but by that time Safari has usually given up on resolving the address and you get an error. The second time you try it, the correct address has already been cached by the system and everything works.

"I found that a very simple fix (if you don't mind editing OS config files) was to modify the /System/Library/StartupItems/BIND/BIND file to add the '-4' option to named, which forces it to only use IPV4. For example, the first part of the file normally looks like this:

StartService ()
{
if [ "${DNSSERVER:=-NO-}" = "-YES-" ]; then
ConsoleMessage "Starting named"
named
fi
}

I changed the above to:

StartService ()
{
if [ "${DNSSERVER:=-NO-}" = "-YES-" ]; then
ConsoleMessage "Starting named"
named -4
fi
}

"You should probably do the same thing for the RestartService section in the file. You'll either need to restart named by hand with the new option, or simply reboot your system to have the above take effect (probably the safest thing to do). I haven't yet tried digging into the BIND code deeply enough to determine why it seems to favor IPV6 address over and over again even though it never gets a valid response. It appears as though there is some code within BIND to sort the servers on response time, but IPV6 servers seem to always wind up at the front of the list."

Previously visited sites do not exhibit the problem Several readers have reported that one a site successfully (usually after multiple requests), it will continue to work on the first try in subsequent attempts. This occurs because Mac OS X is able to cache the correct DNS address for a given URL. However, once the cache no longer exists, the problem re-occurs.

MacFixIt reader Steve writes "Shutting down my cable modem/airport, and powering back up fixed the Safari 'two-try' syndrome. However, that was short-lived. It did fix it for a few hours, but then... back to the usual problem. Previously visited sites are fine, but newly-visited sites almost always exhibit the 'cannot find server' drop down, but connect always on the second try."

Why are these issues occurring after Security Updates? Again, the update most often implicated as a cause -- Security Update 2004-09-30 -- was a relatively minor update in terms of the number of files replaced; specifically, the Update only changed files relating to NetInfo Manager, File Sharing, QuickTime, postfix, and cupsd. None of these files should affect Safari connectivity.

Also, it should be noted that we've received a dozen or so reader reports (out of the hundreds regarding this issue) from users who have not applied any of the recent Apple Security Updates.

In a quick scan through changes included in the recent updates, only one -- Security Update 2004-09-07 -- has significant changes to TCP/IP operation.

This update fixes a vulnerability where maliciously crafted IP fragments can use too many system resources preventing normal network operation, i.e. the "Rose Attack."

According to Security Update 2004-09-07's documentation "The TCP/IP implementation has been modified to limit the resources consumed and prevents this denial of service attack."

Even this change does not seem to be directly related to the issue at hand, though Security Update 2004-09-07 did generate an increase in the number of connectivity problem reports.

One possible theory -- Security Update 2004-09-07 was revised from its initial release in mid-September. A mere two weeks later, the "most problematic" update, Security Update 2004-09-30, was released. Some have suggested that Security Update 2004-09-07 actually caused the problem, but users did not immediately experience it because of already cached DNS servers. A subsequent update -- Security Update 2004-09-30 for some, another revision or even a general system maintenance routine for others -- cleared the DNS cache and the problem began to manifest. Currently the theory is pure speculation, but it may help us track down the actual trigger for this issue.

Feedback? Late-breakers@macfixit.com.

Resources