Symptoms<\/h3>\n\n- Web pages load slowly in Safari or Firefox in Leopard.<\/li>\n
- Web sites won’t load, only load partially, stop loading after a few hours.<\/li>\n
- Slow DNS (domain name) lookup in Leopard. First load of web site is slow with “looking up domain” in browser status bar.<\/li>\n
- Once website is loaded, browsing to that site is fast.<\/li>\n
- AirPort wireless strength drops, then Internet connection is lost<\/a> (see related post).<\/li>\n
- Email programs are slow in connecting to servers.<\/li>\n
- SSH sessions are slow to connect to remote servers.<\/li>\n<\/ul>\n
Possible Causes of Slow Internet under Leopard<\/h3>\n\n- Your ISP’s DNS servers are (sometimes) slow to respond due to high traffic.<\/li>\n
- Firefox, Camino<\/a>, Safari is requesting domain name lookups in IPv6 format<\/a> (2001:db8::1428:57ab), but your DSL router\/cable modem answers with IPv4 addresses<\/a> (192.0.2.235) (references: mozillazine.org<\/a>, mozilla.org bug<\/a>, arstechnica.com<\/a>). Safari may not be affected by this as WebKit is said to use IPv4 domain lookups first, then uses IPv6 if IPv4 fails.<\/li>\n
- Your router, acting as a DNS Proxy, doesn’t recognize nor forward IPv6 domain name lookup requests.<\/li>\n
- Leopard is now requesting SRV (service) records for domain name lookups. Your router does not recognize nor forward to SRV requests.<\/li>\n
- Your ISP’s DNS servers don’t recognize or doesn’t respond to SRV queries or respond with NXDOMAIN.<\/li>\n
- [Added 080618<\/strong>] Poor wireless router performance in general (references: entropy.ch<\/a>). To test this, try connecting directly to your DSL router\/modem if you are using an intermediate router such as an Apple AirPort Base Station, or NetGear\/Linksys wireless router and seeing if web and internet speeds increase.<\/li>\n<\/ul>\n
Fixes\/Solutions\/Workarounds<\/h3>\n\n- Use better faster DNS servers, like OpenDNS.org (208.67.222.222, 208.67.220.220)<\/a>.<\/li>\n
- Connect directly to DNS servers to avoid DNS forwarding through your router (acting as a DNS proxy)<\/a>.<\/li>\n
- Turn off IPv6 DNS lookups in Firefox\/Camino<\/a> (references: mozilla.org<\/a>).<\/li>\n
- If DNS forwarding is required, <\/a>change the DNS servers directly on the router.<\/li>\n
- Update your router’s firmware<\/a> (references: jungledisk.com<\/a>, ubuntu.com<\/a>) for better SRV and IPv6 handling and better performance overall.<\/li>\n
- Below are detailed instructions on applying these fixes to slow dns lookups\/slow Internet on Leopard<\/li>\n<\/ul>\n
Details<\/h2>\n
After upgrading to Leopard, plenty of Mac OS X users have complained of “slow internet” when browsing the web, yet Windows PCs or Macs with Tiger (10.4) on the same network are much faster.<\/p>\n
DNS Lookups<\/h3>\n
A domain name lookup or DNS lookup is done every time you visit a web page, say “apple.com”, as you’re actually visiting “17.149.160.49”. A DNS Resolver on your computer sends a request to a DNS Server that handles this lookup or translation from names (easy to remember) to numbers (hard to remember). Once your browser has this numerical IP address it can start loading the web pages at that server location.<\/p>\n
Domain Name System Lookups in Leopard<\/h3>\n
With Leopard, a major change occurred in DNS lookups. Any program in Leopard that can use version 6 IP addresses (IPv6 explained below) will send out a new type of DNS lookup request – the SRV Record. In Tiger and previous OS X versions, DNS lookups were A record requests.<\/p>\n
SRV records are new (sadly, 8 years old is new in the DNS world), provide more information than A records, but have terrible support<\/strong> in terms of hardware (your DSL router or cable modem) and DNS servers that answer with SRV information. For every SRV request that Leopard sends it must wait for a valid reply. If the request fails, Leopard must try again. If it fails again, Leopard will finally ask for an A record. This is one reason why Mac users are experiencing slow Internet on new Macs with Leopard or after upgrading to Leopard from Tiger.<\/p>\nDomain Name Lookup Chain<\/h3>\n
Diagnosing slow Internet problems under Leopard is difficult due to the many different slowdowns that can occur along the domain name lookup chain when connecting to the Internet in OS X. For an application like Firefox or Safari to find a domain name, this is roughly what happens:<\/p>\n
\n- Firefox\/Safari is asked to load a web page at a domain name (example: “apple.com”).<\/li>\n
- Browser starts work on getting an IP address for that domain (a domain name lookup).<\/li>\n
- Browser checks for recently translated domain names in its own internal “cache” and thus already has the IP address.<\/li>\n
- If “apple.com” is not found in cache, Firefox\/Safari then asks Directory Services (an OS X program that does DNS lookups) for the answer.<\/li>\n
- Directory Services (DS) searches for the domain in its own<\/em> DS cache (view the DS cache using Terminal<\/a>: dscacheutil -cachedump -entries).<\/li>\n
- If domain is not found in cache, DS checks flat (text) files such as \/etc\/hosts for the domain name (see the file using Terminal: cat \/etc\/hosts).<\/li>\n
- If domain is still not found then DS sends a domain name lookup request to the first DNS server listed for your AirPort wireless card or your Ethernet card (your network interfaces<\/em>). The first (and usually only) DNS server is often your router (often listed as 192.168.1.1 in System Preferences => Network => Advanced => DNS tab).<\/li>\n
- If the router doesn’t<\/em> recognize the name lookup request (SRV\/IPv6), the request will be either ignored, returned without result, returned with error. If the router does<\/em> recognize the DNS request, it checks its own DNS cache for a matching domain lookup.<\/li>\n
- If domain name is not found<\/em> in cache, the router forwards the request to the ISP’s DNS server.<\/li>\n
- If the first ISP DNS server doesn’t respond or doesn’t have the record, the router sends a second lookup request to the next DNS server listed in its configuration. Continue until all DNS servers are exhausted.<\/li>\n
- When name lookup result is received by router, it saves the result to cache, then forwards the domain name record back to the requesting computer.<\/li>\n
- Directory Services on Leopard, receives the answer, places it in cache, then returns the results to the requesting application: your browser.<\/li>\n
- Firefox\/Safari receives the DNS record, with IP address, stores it in cache, then starts to retrieve the web page at that location.<\/li>\n<\/ol>\n
![\"\"](\"https:\/\/installingcats.com\/wp-content\/uploads\/2008\/06\/dns_resolution-1.jpg\" "\\"DNS")
<\/p>\n
(Illustration by Lion Kimbro on Wikipedia – Domain Name Systems article<\/a>)<\/p>\nAny one of the links in the chain can be a potential source of slow Internet speeds when browsing or retrieving mail, etc. The difficulty lies is finding out where the problem exists and how it can be fix. Compound this complexity with the number of different DSL routers in use in homes, the number of different firmware (software inside the router), number of different ISP DNS servers<\/p>\n
Caches<\/h3>\n
Caches store recent domain name lookup results in order to save time when the domain is requested again. Each time a domain name lookup is made, caches are checked to see if the lookup has occurred recently and if so, use the cache result. If no result is found in cache, the domain name lookup has failed and the DNS lookup request continues down the chain. A domain lookup may fail all the way down the chain until it’s finally resolved with the second or third DNS server listed, taking maybe 15 seconds to finally succeed. But, once domain lookup has been successfully performed, this domain request “answer” is cached all the way back<\/em> up the chain, for varying amounts of time. Browsers like Safari and Firefox normally cache domain name lookups for 1 minute (30 minutes if you’re Internet Explorer in Vista). Leopard’s Directory Services program caches lookups for one hour (3600 seconds) by default.<\/p>\nOnce a successful domain lookup has occurred, web pages from the same site will load very quickly, since the domain and its IP address are known and cached in memory. When the cached domain lookup result expires, the vicious cycle of slow domain lookups restarts. This often leads to the confusing pattern of fast Internet \/ slow Internet performance that can be seen sporadically throughout a browsing session.<\/p>\n
IPv6<\/h3>\n
IPv6, the new way of addressing all things on the Internet<\/a>, is important and necessary as we’ll eventually run out of IPv4 addresses (like 17.149.160.49). But part of the issue with slow browsing and slow Internet on Leopard is the combination of how IPv6 is used in Mac OS X and the current state of DSL routers and cable modems.<\/p>\nWhenever a program on Leopard can use IPv6 addressing, such as Firefox, it will request IP addresses for domains in IPv6 and if that fails, Firefox will then try IPv4 domain lookups. The reason this adds to the slow Internet problem is that many routers and DSL or cable modems in peoples homes are not capable of handling\/routing IPv6 domain name queries (properly). This can cause repeated, failed DNS queries in IPv6 format, with the requesting application eventually falling back to sending IPv4 domain lookup requests that are successfully answered. The unfortunate problem with this “IPv6 then IPv4” order of domain lookups is users end up with delays of 5 to 10 seconds “looking up” a domain name<\/a>, which is not a very long time to wait, but suffering short delays every time you visit a different website can be extremely frustrating.<\/p>\nSRV (Service Record) Requests<\/h3>\n
Part of the issue may be related to Apple’s decision to follow the Internet Engineering Task Force<\/a>‘s recommendation of using SRV queries instead of “A record” queries when looking up domain names in Leopard.<\/p>\nThe problem with Leopard asking for SRV records<\/a> from DNS servers is that many DNS servers still don’t recognize or respond to SRV type DNS requests, or respond with a non-existent domain (NXDOMAIN) error code. This is not exactly Apple’s fault for asking, it’s actually the fault of DNS server owners who are not updating their servers to the latest standards. Regardless, whenever a program like a web browser requests a DNS record and gets failed responses, or no response at all, the program retries its requests, but only after a certain delay. Each failed SRV request and subsequent retry adds time the user must wait before the browser or application eventually gives up on the SRV requests and tries an old-school basic A record request in an attempt to get the IP address of the domain name. And all DNS servers answer to A record requests, even the old dingy ones not following the latest IETF standards. You, the user, sees this request — no response — retry dance as the browser taking a long time “Looking up domain.com….”, often seen as such on the browser status bar at the bottom left hand corner of the window. Only when the browser or application has received a valid IP address from a domain lookup can it contact the web server and start to download the HTML and display the page.<\/p>\nTimeouts<\/h3>\n
The delay between lookup retries is important to prevent overloading DNS servers, DNS resolvers (like Directory Services on your Mac) and simply makes sense. It’s similar to walking up to someone’s house and knocking on the door: Normally you wait a few moments for a response before trying again. If you don’t wait, you don’t know whether no one’s home, or whether they’re just taking a few seconds to respond. Continued knocking doesn’t help you. (And perhaps will earn you a stern look if not make you the target of a hissy fit).<\/p>\n
Hammering a DNS server with domain lookups without pause is not very productive since the DNS server will simply drop (not answer) requests that it cannot handle within a timely fashion, based on its current load and worse, may get you blocked from the DNS server.<\/p>\n
Next we’ll see how we can solve or workaround the issues discussed above that could be slowing down Leopard’s Internet speed.<\/p>\n
<\/a><\/p>\nSolutions<\/h2>\n\n- Direct DNS \/ Better DNS<\/a><\/li>\n
- Disable IPv6 DNS Lookups<\/a><\/li>\n
- Update DNS Servers on Router<\/a><\/li>\n
- Update Router Firmware<\/a><\/li>\n<\/ul>\n
<\/a><\/p>\nDirect DNS \/ Better DNS<\/h3>\n
Update 080606: Leopard 10.5.3 may have changed the order in which DNS Servers are used<\/a>.<\/span><\/p>\nUpdate 080606: DNS servers entered on a DHCP configured setup are used in reverse order. I.e. the last server entered is the first to be used. If you’ve manually configured a network location, DNS servers are used in the order that you’ve entered them\/see them.<\/p>\n
New 080606<\/strong>: If you wish to save your current network setup and have the option of returning to it easily, follow the instructions for Creating a New Network Location<\/a>. Otherwise, follow the instructions immediately below to quickly add new DNS servers.<\/p>\nAdd DNS servers to Current Network Configuration<\/h4>\n
This is the quickest & easiest way to use new DNS servers, which is to simply add them to the DNS tab found in System Preferences => Network => Advanced => click on DNS tab.<\/p>\n
![\"\"](\"https:\/\/installingcats.com\/wp-content\/uploads\/2008\/06\/network_dhcp_add_dns-1-234x300.gif\" "\\"Network")
<\/a><\/p>\nClick on the + sign at the bottom left hand corner near IPv6 or IPv6 addresses and type in the addresses of the DNS servers you wish, in reverse priority order. (Recommended: OpenDNS servers at 208.67.220.220 and 208.67.222.222). I.e. the server that you want to use first, enter it last. Afterwards, click Ok. Then in the Network pane, click Apply to make your changes active. If you’re using an AirPort wireless connection, wait a few moments for the connection to be re-established
\n<\/a><\/p>\nCreating a New Network Location<\/h4>\n
The advantage of creating a new network location is the ease of which you can move back and forth between different network setups. By creating and using a new network location, you can always revert your changes by simply selecting your original (Automatic) network location from the Location drop down list.<\/p>\n
In Leopard, open System Preferences<\/strong> => Network<\/strong> => click the Advanced<\/strong> button (bottom right corner)<\/p>\n![\"\"](\"https:\/\/installingcats.com\/wp-content\/uploads\/2008\/06\/network-1.jpg\" "\\"Network")
\nClick TCP\/IP<\/strong> tab (top left).
\nWrite down on a piece of paper (or in TextEdit) the IPv4 Address<\/strong>, Subnet Mask<\/strong> (255.255.255.0), Router<\/strong>, and Configure IPv6<\/strong> setting. Click Cancel<\/strong>.<\/p>\n![\"\"](\"https:\/\/installingcats.com\/wp-content\/uploads\/2008\/06\/network_advanced_tcp_ip-1.jpg\" "\\"Network")
<\/p>\n
Find the Location<\/strong> drop down at top of the Network preferences pane. Click it and choose Edit Locations<\/strong>.<\/p>\n![\"\"](\"https:\/\/installingcats.com\/wp-content\/uploads\/2008\/06\/network_locations-1.jpg\" "\\"network_locations\\"")
\nHighlight “Automatic” if not already
\nClick the Gear icon<\/strong> on the bottom center, choose Duplicate Location<\/strong><\/p>\n![\"\"](\"https:\/\/installingcats.com\/wp-content\/uploads\/2008\/06\/network_locations_duplicate-1.jpg\" "\\"network_locations_duplicate\\"")
<\/strong>
\nChoose a name, I used “Home”.
\nChange the Location<\/strong> drop down box by clicking on “Automatic” and then switch it to “Home” (or the name you chose in the last step)
\nYou’ll see the following:<\/p>\n![\"\"](\"https:\/\/installingcats.com\/wp-content\/uploads\/2008\/06\/network_location_home_new-1.jpg\" "\\"Network")
\nSelect Airport<\/strong> on the left (or Ethernet<\/strong> if you’re not using a wireless connection).
\nClick Advanced<\/strong> at the bottom right.
\nClick on the TCP\/IP<\/strong> tab-button.
\nChange the Configure IPv4<\/strong> drop down box to “Manually”.
\nHere’s where you use the values you saved in Step 2. Fill out IPv4 address<\/strong>, subnet mask<\/strong>, router<\/strong>, configure IPv6<\/strong> settings. Do not<\/em> click OK<\/strong>, instead click on DNS<\/strong> near the top.
\nClick the +<\/strong> button, bottom left hand corner. This creates a blue outline under DNS Servers on the left half of this window.<\/p>\n![\"\"](\"https:\/\/installingcats.com\/wp-content\/uploads\/2008\/06\/network_home_dns-1.jpg\" "\\"Network")
<\/p>\n
![\"\"](\"https:\/\/installingcats.com\/wp-content\/uploads\/2008\/06\/network_home_dns_entry-1.jpg\" "\\"Network")
<\/p>\n
Enter in the DNS server of your choice. I recommend OpenDNS at 208.67.222.222. (Don’t include a period at the end). Add a second OpenDNS server by clicking again on the + button and entering 208.67.220.220. These DNS servers will automatically redirect you to the closest \/ best server for you, regardless of whether you’re in France (like me) or in North America. Click OK<\/strong>. You should be returned to the Network preferences pane and see something like the following:<\/p>\n![\"\"](\"https:\/\/installingcats.com\/wp-content\/uploads\/2008\/06\/network_location_home_done-1.jpg\" "\\"Network")
<\/p>\n
At this point you’ve created a new Location called “Home”, having setup AirPort or Ethernet with the correct settings and “Services” (i.e. DNS), but none of these changes have been made active. Let’s make a backup of the configuration file that will be updated before<\/em> you apply your changes. In Finder, click on the hard disk icon at the top left corner (usually Macintosh HD), then navigate to this directory: \/Library\/Preferences\/SystemConfiguration<\/strong> and find this file: preferences.plist<\/strong>. Simply copy the file to your Documents folder or to a spot of your choice. If you have to rollback the applied changes, you can copy this file back to the above location. If you’re using Time Machine, this file should be backed up already. Now you know where this file is, so replacing it with a Time Machine version should be straightforward.<\/p>\nBefore we make our changes effective, we’re going to check how DNS requests are handled now, before the changes, and after to make sure we’ve changed our Network Settings properly.
\n<\/a>
\nLeave the Network window open as is and open up a Terminal window<\/a>. We’re going to be using the tcpdump program to listen to DNS traffic<\/a> between your computer and your DNS server.<\/p>\nType this command and hit Enter: sudo tcpdump -i en1 -s 128 port 53<\/code><\/p>\n(If you’re using Ethernet with a cable, use en0<\/strong> instead of en1<\/strong>, which is the AirPort wireless interface).<\/p>\nSupply your password when asked to do so.<\/p>\n
You should see something like the following:<\/p>\n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
\nlistening on en1, link-type EN10MB (Ethernet), capture size 96 bytes<\/code><\/p>\ntcpdump should now be running.<\/p>\n
Open up another Terminal window and type the following command: curl http:\/\/www.csu.edu<\/code><\/p>\nThis uses the curl program to read the web page located at www.csu.edu.<\/p>\n
Going back to your tcpdump window you should see something similar to this:<\/p>\n
00:31:37.026520 IP 192.168.1.132.56645 > WANADOO-D310.domain: 19279+ SRV? _http._tcp.www.csu.edu. (40)
\n00:31:37.029352 IP WANADOO-D310.domain > 192.168.1.132.56645: 19279* 0\/0\/0 (40)
\n00:31:37.029849 IP 192.168.1.132.56646 > WANADOO-D310.domain: 49549+ SRV? _http._tcp.www.csu.edu. (40)
\n00:31:37.032657 IP WANADOO-D310.domain > 192.168.1.132.56646: 49549* 0\/0\/0 (40)
\n00:31:37.034345 IP 192.168.1.132.56647 > WANADOO-D310.domain: 46004+ A? www.csu.edu. (29)
\n00:31:37.279043 IP WANADOO-D310.domain > 192.168.1.132.56647: 46004 1\/0\/0 A www.csu.edu (45)<\/p>\n
Notice 192.168.1.132. That’s me, or really, my MacBook Pro’s AirPort wireless card. Then there’s a greater than sign (>) showing the direction of DNS traffic. WANADOO-D310 is my DNS server, which is actually the DSL modem\/router, a.k.a. 192.168.1.1, which is passing domain name lookups to the real DNS servers at my Internet Service Provider (WANADOO, yeah I know goofy name). Remember the network settings we wrote down before starting all this? You’ll notice that the DNS server is 192.168.1.1.<\/p>\n
OK, we’ve got a baseline of what our Mac is doing when looking up domain names, let’s apply our new network location “Home” that we created and see the difference.<\/p>\n
Back on the Network preference pane, notice the Apply<\/strong> button on the bottom right hand corner. Once you apply your changes, your Mac will begin using the new Location you’ve created.<\/p>\nTake the plunge and click on Apply<\/strong>.<\/p>\nFor AirPort wireless connections, you may have to click the Turn AirPort Off button, wait fifteen seconds, then click Turn AirPort On again in order for the new DNS settings to be used.<\/p>\n
Going back to the Terminal window where we executed the curl command, and with our changes set, let’s execute another: curl http:\/\/www.unc.edu<\/code><\/p>\nResults will look like the following:<\/p>\n
00:32:33.562589 IP 192.168.1.132.56663 > resolver1.opendns.com.domain: 39356+ SRV? _http._tcp.www.unc.edu. (40)
\n00:32:33.767237 IP resolver1.opendns.com.domain > 192.168.1.132.56663: 39356 NXDomain 0\/0\/0 (40)
\n00:32:33.767856 IP 192.168.1.132.56664 > resolver1.opendns.com.domain: 62833+ SRV? _http._tcp.www.unc.edu. (40)
\n00:32:33.809161 IP resolver1.opendns.com.domain > 192.168.1.132.56664: 62833 NXDomain 0\/0\/0 (40)
\n00:32:33.811130 IP 192.168.1.132.56665 > resolver1.opendns.com.domain: 45293+ A? www.unc.edu. (29)
\n00:32:33.853070 IP resolver1.opendns.com.domain > 192.168.1.132.56665: 45293 1\/0\/0 A www.unc.edu (45)<\/p>\n
Notice what’s changed? WANADOO-D310.doman has changed to resolver1.opendns.com.domain. This is OpenDNS’ name for the DNS server we started using, 208.67.222.222, which we entered as our DNS for the “Home” location. Also, note how instead of just getting a 0\/0\/0 response, we’re getting NXDOMAIN 0\/0\/0? That’s at least the DNS server responding<\/em> saying: that domain doesn’t exist (not exactly true, since the domain does exist, but it just doesn’t have an SRV record), rather than the DNS server sending back nothing, not even an error code. Also, notice how our Mac tried twice on asking for SRV records, and the DNS server responded twice, that no record exists for that domain, and then finally our Mac asks for an A record (A?) and gets one answer record back (1\/0\/0 A ww.unc.edu).<\/p>\nIf you want to see a domain that actually has a proper SRV record, try this in the curl terminal window: curl http:\/\/s3.amazonaws.com<\/code><\/p>\nResults should be something like this:<\/p>\n
09:36:56.440037 IP 192.168.1.132.61010 > resolver1.opendns.com.domain: 34536+ SRV? _http._tcp.s3.amazonaws.com. (45)
\n09:36:56.671881 IP resolver1.opendns.com.domain > 192.168.1.132.61010: 34536 2\/0\/0 CNAME s3-directional-w.amazonaws.com., (97)
\n09:36:56.673894 IP 192.168.1.132.61011 > resolver1.opendns.com.domain: 18143+ A? s3.amazonaws.com. (34)
\n09:36:56.715913 IP resolver1.opendns.com.domain > 192.168.1.132.61011: 18143 2\/0\/0 CNAME s3-1.amazonaws.com., A s3.amazonaws.com (69)
\n09:36:57.263186 IP 192.168.1.132.61012 > resolver1.opendns.com.domain: 32069+ PTR? 171.206.21.72.in-addr.arpa. (44)
\n09:36:57.306060 IP resolver1.opendns.com.domain > 192.168.1.132.61012: 32069 1\/0\/0 PTR s3.amazonaws.com. (74)<\/p>\n
Here we’re getting 2 answer records (the “2” in 2\/0\/0) on the SRV requests, which are CNAME records, first being s3-directional-w.amazonaws.com, second being s3-1.amazonaws.com. CNAME records are “nickname” records, which point to true name, or A Record. Right after that our Mac asks for an A record on the first CNAME that was returned to us (s3-directional-w.amazonaws.com) to get back the actual IP address (72.21.207.246), which you can verify by using the dig program.<\/a><\/p>\nThis fix alone has made my Internet connection much faster since my ISP’s DNS servers were sometimes under heavy load and slow to respond to DNS queries. Most of the time, I’d get name requests done in 200-400ms. Not noticeably slow. But, on occasion domain name lookups would timeout after 7 seconds, multiple times, resulting in up to 21 seconds of waiting for a single name lookup request to occur. This is excruciatingly long when I often open up multiple different websites one right after another when starting a browsing session. To make matters worse, many websites are getting into the practice of placing different parts of the web page on different domain names. Let’s take CNN.com for example. To load this single page of President Obama… oh, I mean senator Obama, waving to the crowd, tcpdump showed name lookups for the following domains:<\/p>\n
![\"\"](\"https:\/\/installingcats.com\/wp-content\/uploads\/2008\/06\/president_obama_cnn-1.jpg\" "\\"President")
<\/a><\/p>\n\n- www.cnn.com<\/li>\n
- edition.cnn.com<\/li>\n
- i.cdn.turner.com<\/li>\n
- i2.cdn.turner.com<\/li>\n
- svcs.cnn.com<\/li>\n
- ads.cnn.com<\/li>\n
- i.cnn.net<\/li>\n
- ad.doubleclick.net<\/li>\n
- metrics.cnn.com<\/li>\n
- m1.2mdn.net<\/li>\n<\/ol>\n
One Page. Ten domains. Ten DNS lookups. Ouch. And I’m not including PTR\/Reverse Lookups for each domain, making it really 20 DNS queries.<\/p>\n
And does anyone wonder why problematic DNS performance in Leopard would slow web browsing to a crawl?
\n<\/a><\/p>\nDisable IPv6 DNS Lookups<\/h3>\n
Firefox and Camino by default do DNS lookups using IPv6 addresses by default, reverting to IPv4 if that fails. This can be a problem when the router that we are using to connect to the Internet doesn’t work with IPv6 DNS requests properly, if at all.<\/p>\n
To disable IPv6 DNS lookups in Firefox and Camino, type the following into the browser address bar:
\nabout:config<\/code>
\nIf you see a large “Be Careful” warning, simply click on “I understand and I wish to continue”. Next, you will see a long list of Preference Name, Status, Type and Value columns. Above all that is a bar in which you can filter which preferences to view. In the Filter bar type: ipv6
\nYou should see something like the following:<\/p>\n![\"\"](\"https:\/\/installingcats.com\/wp-content\/uploads\/2008\/06\/about_config-1.jpg\" "\\"Firefox")
<\/p>\n
To change the value for this preference simply double-click the name “network.dns.disableIPv6”. The value you want is “true”, which means that IPv6 DNS requests are disabled. If this value is already “true”, don’t double-click this preference.<\/p>\n
To make the preference change active, close the browser and Quit Firefox completely (Apple Key + Q), then restart Firefox. You may<\/em> have to repeat this Quitting and Restarting to have the change take effect.<\/p>\nAfter making this change, Firefox (or Camino if that’s what you’re using) will use IPv4 only when performing DNS requests.<\/p>\n
<\/a><\/p>\nUpdate DNS Servers on Router<\/h3>\n
If you have access to your router’s administration web page, you may be able to set its DNS servers manually, avoiding the buggy DNS servers located at your ISP. Refer the manual that came with your router, or speak with your service provider about how to access the router’s administration page. Often this page can be accessed at http:\/\/192.168.1.1, so simply type that address into your browser’s address bar and press Enter. With any luck you’ll have access to the Administration login page. Many router administration sites don’t have passwords, don’t have usernames, or use very simple standard passwords such as “admin”, leaving it up to the owner to change it to something more secure. Visit the router manufacturer’s web site for more information about accessing the administration features of the router.<\/p>\n
Keep in mind that updating the router’s DNS servers will not avoid problems you may be encountering with the router’s poor DNS Proxying\/Forwarding support. If your router can’t handle IPv6 or SRV requests coming from your Mac, these DNS requests will stop here at the router and will not be forwarded onto the new DNS servers you’ve just specified, making this fix completely ineffective. DNS requests that your router cannot understand will likely be ignored or returned without answer results. DNS Proxy\/Forwarding issues are discussed further in the next section.<\/p>\n
<\/a><\/p>\nUpdate Router Firmware<\/h3>\n
For those who need to continue making DNS requests through their router, rather than directly against DNS servers, due to VPN or tunneling requirements, your fix may lie in upgrading your router’s firmware. Routers are in effect “the” DNS server for the majority of home broadband Internet connections since it acts as the DNS Proxy, taking domain name lookup requests from your computer, passes them to the ISP’s DNS servers for resolution, receives the results, and finally passes the name lookup results back to your Mac, all transparently in the background. This is why your DNS server address is the same as your “Gateway” which is a fancy name for your router, since all traffic passes through this “gate” of sorts. Thus the Gateway address is often 192.168.1.1, which in turn is also the address of the DNS server for the “Automatic” network Location in Leopard.<\/p>\n
Be aware that DNS Proxying is a common failure point in the domain name resolution chain. If the router is not compliant with the latest Internet Task Force standards, it may not know what to do with SRV requests (which Leopard now uses) and may simply ignore them, return empty results, or return NXDOMAIN (non-existent) errors. Again, a firmware update may bring your router up to the latest standards for DNS servers.<\/p>\n
If the router is a DSL Cable modem\/router, contact your ISP and ask whether there is updated firmware for the model of router you’re using. If you’re more of a do-it-yourself person you can attempt to find the manufacturer of the router\/modem and find the latest firmware from their website, if available. Disclaimer<\/strong>: updating the firmware of your router with the wrong firmware, or not completing the firmware update due to power loss, will render your router useless<\/strong>. Do not attempt to update the firmware if you are not confident of what you’re doing.<\/p>\nNew Information<\/h2>\n
<\/a>
\n Update 080606<\/strong>: As per a discussion on Macosxhints forums<\/a>, Apple may have changed the order in which DNS servers are used<\/span>. In the screenshot, the listed DNS servers are used in the order they are seen, under Leopard 10.5.2. This is true for a manually configured Network Location. In 10.5.3, users are seeing the opposite order, i.e<\/span>. In a DCHP configured Network Location (automatically done by your DSL router and ISP), the DNS servers listed are used in reverse order. (Bottom server is used first, then moves up the list as needed). Thus adding a new Network Location to use a given DNS server<\/a> would be unnecessary.<\/p>\n![\"\"](\"https:\/\/installingcats.com\/wp-content\/uploads\/2008\/06\/dns_servers-1-211x300.gif\" "\\"Leopard")
<\/a><\/p>\nUpdate 080614<\/strong>: Airport Wireless Connection Drops – This is a common problem for Leopard users after upgrading to 10.5.2. This isn’t exactly a slow Internet problem, but rather, a “no Internet” problem. See this related post on wireless problems on Apple AirPort connections<\/a>.<\/p>\nThe Beginning<\/h2>\n
This is not the end, but rather, the beginning of an article that I hope will continue to grow in scope to cover more problems and offer more solutions to slow Internet problems in Leopard. Please leave a comment if you’re experiencing a problem not discussed here and we’ll get working on diagnosing the issue and searching for a cure.<\/p>\n
If you’re having troubles implementing a fix listed above, leave a comment and I’ll try to expand on the topic or reword it so that it is understandable to you and to everyone else I’ve confused.<\/p>\n
Possible Causes of Slow Internet under Leopard<\/h3>\n\n- Your ISP’s DNS servers are (sometimes) slow to respond due to high traffic.<\/li>\n
- Firefox, Camino<\/a>, Safari is requesting domain name lookups in IPv6 format<\/a> (2001:db8::1428:57ab), but your DSL router\/cable modem answers with IPv4 addresses<\/a> (192.0.2.235) (references: mozillazine.org<\/a>, mozilla.org bug<\/a>, arstechnica.com<\/a>). Safari may not be affected by this as WebKit is said to use IPv4 domain lookups first, then uses IPv6 if IPv4 fails.<\/li>\n
- Your router, acting as a DNS Proxy, doesn’t recognize nor forward IPv6 domain name lookup requests.<\/li>\n
- Leopard is now requesting SRV (service) records for domain name lookups. Your router does not recognize nor forward to SRV requests.<\/li>\n
- Your ISP’s DNS servers don’t recognize or doesn’t respond to SRV queries or respond with NXDOMAIN.<\/li>\n
- [Added 080618<\/strong>] Poor wireless router performance in general (references: entropy.ch<\/a>). To test this, try connecting directly to your DSL router\/modem if you are using an intermediate router such as an Apple AirPort Base Station, or NetGear\/Linksys wireless router and seeing if web and internet speeds increase.<\/li>\n<\/ul>\n
Fixes\/Solutions\/Workarounds<\/h3>\n\n- Use better faster DNS servers, like OpenDNS.org (208.67.222.222, 208.67.220.220)<\/a>.<\/li>\n
- Connect directly to DNS servers to avoid DNS forwarding through your router (acting as a DNS proxy)<\/a>.<\/li>\n
- Turn off IPv6 DNS lookups in Firefox\/Camino<\/a> (references: mozilla.org<\/a>).<\/li>\n
- If DNS forwarding is required, <\/a>change the DNS servers directly on the router.<\/li>\n
- Update your router’s firmware<\/a> (references: jungledisk.com<\/a>, ubuntu.com<\/a>) for better SRV and IPv6 handling and better performance overall.<\/li>\n
- Below are detailed instructions on applying these fixes to slow dns lookups\/slow Internet on Leopard<\/li>\n<\/ul>\n
Details<\/h2>\n
After upgrading to Leopard, plenty of Mac OS X users have complained of “slow internet” when browsing the web, yet Windows PCs or Macs with Tiger (10.4) on the same network are much faster.<\/p>\n
DNS Lookups<\/h3>\n
A domain name lookup or DNS lookup is done every time you visit a web page, say “apple.com”, as you’re actually visiting “17.149.160.49”. A DNS Resolver on your computer sends a request to a DNS Server that handles this lookup or translation from names (easy to remember) to numbers (hard to remember). Once your browser has this numerical IP address it can start loading the web pages at that server location.<\/p>\n
Domain Name System Lookups in Leopard<\/h3>\n
With Leopard, a major change occurred in DNS lookups. Any program in Leopard that can use version 6 IP addresses (IPv6 explained below) will send out a new type of DNS lookup request – the SRV Record. In Tiger and previous OS X versions, DNS lookups were A record requests.<\/p>\n
SRV records are new (sadly, 8 years old is new in the DNS world), provide more information than A records, but have terrible support<\/strong> in terms of hardware (your DSL router or cable modem) and DNS servers that answer with SRV information. For every SRV request that Leopard sends it must wait for a valid reply. If the request fails, Leopard must try again. If it fails again, Leopard will finally ask for an A record. This is one reason why Mac users are experiencing slow Internet on new Macs with Leopard or after upgrading to Leopard from Tiger.<\/p>\nDomain Name Lookup Chain<\/h3>\n
Diagnosing slow Internet problems under Leopard is difficult due to the many different slowdowns that can occur along the domain name lookup chain when connecting to the Internet in OS X. For an application like Firefox or Safari to find a domain name, this is roughly what happens:<\/p>\n
\n- Firefox\/Safari is asked to load a web page at a domain name (example: “apple.com”).<\/li>\n
- Browser starts work on getting an IP address for that domain (a domain name lookup).<\/li>\n
- Browser checks for recently translated domain names in its own internal “cache” and thus already has the IP address.<\/li>\n
- If “apple.com” is not found in cache, Firefox\/Safari then asks Directory Services (an OS X program that does DNS lookups) for the answer.<\/li>\n
- Directory Services (DS) searches for the domain in its own<\/em> DS cache (view the DS cache using Terminal<\/a>: dscacheutil -cachedump -entries).<\/li>\n
- If domain is not found in cache, DS checks flat (text) files such as \/etc\/hosts for the domain name (see the file using Terminal: cat \/etc\/hosts).<\/li>\n
- If domain is still not found then DS sends a domain name lookup request to the first DNS server listed for your AirPort wireless card or your Ethernet card (your network interfaces<\/em>). The first (and usually only) DNS server is often your router (often listed as 192.168.1.1 in System Preferences => Network => Advanced => DNS tab).<\/li>\n
- If the router doesn’t<\/em> recognize the name lookup request (SRV\/IPv6), the request will be either ignored, returned without result, returned with error. If the router does<\/em> recognize the DNS request, it checks its own DNS cache for a matching domain lookup.<\/li>\n
- If domain name is not found<\/em> in cache, the router forwards the request to the ISP’s DNS server.<\/li>\n
- If the first ISP DNS server doesn’t respond or doesn’t have the record, the router sends a second lookup request to the next DNS server listed in its configuration. Continue until all DNS servers are exhausted.<\/li>\n
- When name lookup result is received by router, it saves the result to cache, then forwards the domain name record back to the requesting computer.<\/li>\n
- Directory Services on Leopard, receives the answer, places it in cache, then returns the results to the requesting application: your browser.<\/li>\n
- Firefox\/Safari receives the DNS record, with IP address, stores it in cache, then starts to retrieve the web page at that location.<\/li>\n<\/ol>\n
<\/p>\n
(Illustration by Lion Kimbro on Wikipedia – Domain Name Systems article<\/a>)<\/p>\nAny one of the links in the chain can be a potential source of slow Internet speeds when browsing or retrieving mail, etc. The difficulty lies is finding out where the problem exists and how it can be fix. Compound this complexity with the number of different DSL routers in use in homes, the number of different firmware (software inside the router), number of different ISP DNS servers<\/p>\n
Caches<\/h3>\n
Caches store recent domain name lookup results in order to save time when the domain is requested again. Each time a domain name lookup is made, caches are checked to see if the lookup has occurred recently and if so, use the cache result. If no result is found in cache, the domain name lookup has failed and the DNS lookup request continues down the chain. A domain lookup may fail all the way down the chain until it’s finally resolved with the second or third DNS server listed, taking maybe 15 seconds to finally succeed. But, once domain lookup has been successfully performed, this domain request “answer” is cached all the way back<\/em> up the chain, for varying amounts of time. Browsers like Safari and Firefox normally cache domain name lookups for 1 minute (30 minutes if you’re Internet Explorer in Vista). Leopard’s Directory Services program caches lookups for one hour (3600 seconds) by default.<\/p>\nOnce a successful domain lookup has occurred, web pages from the same site will load very quickly, since the domain and its IP address are known and cached in memory. When the cached domain lookup result expires, the vicious cycle of slow domain lookups restarts. This often leads to the confusing pattern of fast Internet \/ slow Internet performance that can be seen sporadically throughout a browsing session.<\/p>\n
IPv6<\/h3>\n
IPv6, the new way of addressing all things on the Internet<\/a>, is important and necessary as we’ll eventually run out of IPv4 addresses (like 17.149.160.49). But part of the issue with slow browsing and slow Internet on Leopard is the combination of how IPv6 is used in Mac OS X and the current state of DSL routers and cable modems.<\/p>\nWhenever a program on Leopard can use IPv6 addressing, such as Firefox, it will request IP addresses for domains in IPv6 and if that fails, Firefox will then try IPv4 domain lookups. The reason this adds to the slow Internet problem is that many routers and DSL or cable modems in peoples homes are not capable of handling\/routing IPv6 domain name queries (properly). This can cause repeated, failed DNS queries in IPv6 format, with the requesting application eventually falling back to sending IPv4 domain lookup requests that are successfully answered. The unfortunate problem with this “IPv6 then IPv4” order of domain lookups is users end up with delays of 5 to 10 seconds “looking up” a domain name<\/a>, which is not a very long time to wait, but suffering short delays every time you visit a different website can be extremely frustrating.<\/p>\nSRV (Service Record) Requests<\/h3>\n
Part of the issue may be related to Apple’s decision to follow the Internet Engineering Task Force<\/a>‘s recommendation of using SRV queries instead of “A record” queries when looking up domain names in Leopard.<\/p>\nThe problem with Leopard asking for SRV records<\/a> from DNS servers is that many DNS servers still don’t recognize or respond to SRV type DNS requests, or respond with a non-existent domain (NXDOMAIN) error code. This is not exactly Apple’s fault for asking, it’s actually the fault of DNS server owners who are not updating their servers to the latest standards. Regardless, whenever a program like a web browser requests a DNS record and gets failed responses, or no response at all, the program retries its requests, but only after a certain delay. Each failed SRV request and subsequent retry adds time the user must wait before the browser or application eventually gives up on the SRV requests and tries an old-school basic A record request in an attempt to get the IP address of the domain name. And all DNS servers answer to A record requests, even the old dingy ones not following the latest IETF standards. You, the user, sees this request — no response — retry dance as the browser taking a long time “Looking up domain.com….”, often seen as such on the browser status bar at the bottom left hand corner of the window. Only when the browser or application has received a valid IP address from a domain lookup can it contact the web server and start to download the HTML and display the page.<\/p>\nTimeouts<\/h3>\n
The delay between lookup retries is important to prevent overloading DNS servers, DNS resolvers (like Directory Services on your Mac) and simply makes sense. It’s similar to walking up to someone’s house and knocking on the door: Normally you wait a few moments for a response before trying again. If you don’t wait, you don’t know whether no one’s home, or whether they’re just taking a few seconds to respond. Continued knocking doesn’t help you. (And perhaps will earn you a stern look if not make you the target of a hissy fit).<\/p>\n
Hammering a DNS server with domain lookups without pause is not very productive since the DNS server will simply drop (not answer) requests that it cannot handle within a timely fashion, based on its current load and worse, may get you blocked from the DNS server.<\/p>\n
Next we’ll see how we can solve or workaround the issues discussed above that could be slowing down Leopard’s Internet speed.<\/p>\n
<\/a><\/p>\nSolutions<\/h2>\n\n- Direct DNS \/ Better DNS<\/a><\/li>\n
- Disable IPv6 DNS Lookups<\/a><\/li>\n
- Update DNS Servers on Router<\/a><\/li>\n
- Update Router Firmware<\/a><\/li>\n<\/ul>\n
<\/a><\/p>\nDirect DNS \/ Better DNS<\/h3>\n
Update 080606: Leopard 10.5.3 may have changed the order in which DNS Servers are used<\/a>.<\/span><\/p>\nUpdate 080606: DNS servers entered on a DHCP configured setup are used in reverse order. I.e. the last server entered is the first to be used. If you’ve manually configured a network location, DNS servers are used in the order that you’ve entered them\/see them.<\/p>\n
New 080606<\/strong>: If you wish to save your current network setup and have the option of returning to it easily, follow the instructions for Creating a New Network Location<\/a>. Otherwise, follow the instructions immediately below to quickly add new DNS servers.<\/p>\nAdd DNS servers to Current Network Configuration<\/h4>\n
This is the quickest & easiest way to use new DNS servers, which is to simply add them to the DNS tab found in System Preferences => Network => Advanced => click on DNS tab.<\/p>\n
<\/a><\/p>\nClick on the + sign at the bottom left hand corner near IPv6 or IPv6 addresses and type in the addresses of the DNS servers you wish, in reverse priority order. (Recommended: OpenDNS servers at 208.67.220.220 and 208.67.222.222). I.e. the server that you want to use first, enter it last. Afterwards, click Ok. Then in the Network pane, click Apply to make your changes active. If you’re using an AirPort wireless connection, wait a few moments for the connection to be re-established
\n<\/a><\/p>\nCreating a New Network Location<\/h4>\n
The advantage of creating a new network location is the ease of which you can move back and forth between different network setups. By creating and using a new network location, you can always revert your changes by simply selecting your original (Automatic) network location from the Location drop down list.<\/p>\n
In Leopard, open System Preferences<\/strong> => Network<\/strong> => click the Advanced<\/strong> button (bottom right corner)<\/p>\n
\nClick TCP\/IP<\/strong> tab (top left).
\nWrite down on a piece of paper (or in TextEdit) the IPv4 Address<\/strong>, Subnet Mask<\/strong> (255.255.255.0), Router<\/strong>, and Configure IPv6<\/strong> setting. Click Cancel<\/strong>.<\/p>\n<\/p>\n
Find the Location<\/strong> drop down at top of the Network preferences pane. Click it and choose Edit Locations<\/strong>.<\/p>\n
\nHighlight “Automatic” if not already
\nClick the Gear icon<\/strong> on the bottom center, choose Duplicate Location<\/strong><\/p>\n<\/strong>
\nChoose a name, I used “Home”.
\nChange the Location<\/strong> drop down box by clicking on “Automatic” and then switch it to “Home” (or the name you chose in the last step)
\nYou’ll see the following:<\/p>\n
\nSelect Airport<\/strong> on the left (or Ethernet<\/strong> if you’re not using a wireless connection).
\nClick Advanced<\/strong> at the bottom right.
\nClick on the TCP\/IP<\/strong> tab-button.
\nChange the Configure IPv4<\/strong> drop down box to “Manually”.
\nHere’s where you use the values you saved in Step 2. Fill out IPv4 address<\/strong>, subnet mask<\/strong>, router<\/strong>, configure IPv6<\/strong> settings. Do not<\/em> click OK<\/strong>, instead click on DNS<\/strong> near the top.
\nClick the +<\/strong> button, bottom left hand corner. This creates a blue outline under DNS Servers on the left half of this window.<\/p>\n<\/p>\n
<\/p>\n
Enter in the DNS server of your choice. I recommend OpenDNS at 208.67.222.222. (Don’t include a period at the end). Add a second OpenDNS server by clicking again on the + button and entering 208.67.220.220. These DNS servers will automatically redirect you to the closest \/ best server for you, regardless of whether you’re in France (like me) or in North America. Click OK<\/strong>. You should be returned to the Network preferences pane and see something like the following:<\/p>\n<\/p>\n
At this point you’ve created a new Location called “Home”, having setup AirPort or Ethernet with the correct settings and “Services” (i.e. DNS), but none of these changes have been made active. Let’s make a backup of the configuration file that will be updated before<\/em> you apply your changes. In Finder, click on the hard disk icon at the top left corner (usually Macintosh HD), then navigate to this directory: \/Library\/Preferences\/SystemConfiguration<\/strong> and find this file: preferences.plist<\/strong>. Simply copy the file to your Documents folder or to a spot of your choice. If you have to rollback the applied changes, you can copy this file back to the above location. If you’re using Time Machine, this file should be backed up already. Now you know where this file is, so replacing it with a Time Machine version should be straightforward.<\/p>\nBefore we make our changes effective, we’re going to check how DNS requests are handled now, before the changes, and after to make sure we’ve changed our Network Settings properly.
\n<\/a>
\nLeave the Network window open as is and open up a Terminal window<\/a>. We’re going to be using the tcpdump program to listen to DNS traffic<\/a> between your computer and your DNS server.<\/p>\nType this command and hit Enter: sudo tcpdump -i en1 -s 128 port 53<\/code><\/p>\n(If you’re using Ethernet with a cable, use en0<\/strong> instead of en1<\/strong>, which is the AirPort wireless interface).<\/p>\nSupply your password when asked to do so.<\/p>\n
You should see something like the following:<\/p>\n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
\nlistening on en1, link-type EN10MB (Ethernet), capture size 96 bytes<\/code><\/p>\ntcpdump should now be running.<\/p>\n
Open up another Terminal window and type the following command: curl http:\/\/www.csu.edu<\/code><\/p>\nThis uses the curl program to read the web page located at www.csu.edu.<\/p>\n
Going back to your tcpdump window you should see something similar to this:<\/p>\n
00:31:37.026520 IP 192.168.1.132.56645 > WANADOO-D310.domain: 19279+ SRV? _http._tcp.www.csu.edu. (40)
\n00:31:37.029352 IP WANADOO-D310.domain > 192.168.1.132.56645: 19279* 0\/0\/0 (40)
\n00:31:37.029849 IP 192.168.1.132.56646 > WANADOO-D310.domain: 49549+ SRV? _http._tcp.www.csu.edu. (40)
\n00:31:37.032657 IP WANADOO-D310.domain > 192.168.1.132.56646: 49549* 0\/0\/0 (40)
\n00:31:37.034345 IP 192.168.1.132.56647 > WANADOO-D310.domain: 46004+ A? www.csu.edu. (29)
\n00:31:37.279043 IP WANADOO-D310.domain > 192.168.1.132.56647: 46004 1\/0\/0 A www.csu.edu (45)<\/p>\n
Notice 192.168.1.132. That’s me, or really, my MacBook Pro’s AirPort wireless card. Then there’s a greater than sign (>) showing the direction of DNS traffic. WANADOO-D310 is my DNS server, which is actually the DSL modem\/router, a.k.a. 192.168.1.1, which is passing domain name lookups to the real DNS servers at my Internet Service Provider (WANADOO, yeah I know goofy name). Remember the network settings we wrote down before starting all this? You’ll notice that the DNS server is 192.168.1.1.<\/p>\n
OK, we’ve got a baseline of what our Mac is doing when looking up domain names, let’s apply our new network location “Home” that we created and see the difference.<\/p>\n
Back on the Network preference pane, notice the Apply<\/strong> button on the bottom right hand corner. Once you apply your changes, your Mac will begin using the new Location you’ve created.<\/p>\nTake the plunge and click on Apply<\/strong>.<\/p>\nFor AirPort wireless connections, you may have to click the Turn AirPort Off button, wait fifteen seconds, then click Turn AirPort On again in order for the new DNS settings to be used.<\/p>\n
Going back to the Terminal window where we executed the curl command, and with our changes set, let’s execute another: curl http:\/\/www.unc.edu<\/code><\/p>\nResults will look like the following:<\/p>\n
00:32:33.562589 IP 192.168.1.132.56663 > resolver1.opendns.com.domain: 39356+ SRV? _http._tcp.www.unc.edu. (40)
\n00:32:33.767237 IP resolver1.opendns.com.domain > 192.168.1.132.56663: 39356 NXDomain 0\/0\/0 (40)
\n00:32:33.767856 IP 192.168.1.132.56664 > resolver1.opendns.com.domain: 62833+ SRV? _http._tcp.www.unc.edu. (40)
\n00:32:33.809161 IP resolver1.opendns.com.domain > 192.168.1.132.56664: 62833 NXDomain 0\/0\/0 (40)
\n00:32:33.811130 IP 192.168.1.132.56665 > resolver1.opendns.com.domain: 45293+ A? www.unc.edu. (29)
\n00:32:33.853070 IP resolver1.opendns.com.domain > 192.168.1.132.56665: 45293 1\/0\/0 A www.unc.edu (45)<\/p>\n
Notice what’s changed? WANADOO-D310.doman has changed to resolver1.opendns.com.domain. This is OpenDNS’ name for the DNS server we started using, 208.67.222.222, which we entered as our DNS for the “Home” location. Also, note how instead of just getting a 0\/0\/0 response, we’re getting NXDOMAIN 0\/0\/0? That’s at least the DNS server responding<\/em> saying: that domain doesn’t exist (not exactly true, since the domain does exist, but it just doesn’t have an SRV record), rather than the DNS server sending back nothing, not even an error code. Also, notice how our Mac tried twice on asking for SRV records, and the DNS server responded twice, that no record exists for that domain, and then finally our Mac asks for an A record (A?) and gets one answer record back (1\/0\/0 A ww.unc.edu).<\/p>\nIf you want to see a domain that actually has a proper SRV record, try this in the curl terminal window: curl http:\/\/s3.amazonaws.com<\/code><\/p>\nResults should be something like this:<\/p>\n
09:36:56.440037 IP 192.168.1.132.61010 > resolver1.opendns.com.domain: 34536+ SRV? _http._tcp.s3.amazonaws.com. (45)
\n09:36:56.671881 IP resolver1.opendns.com.domain > 192.168.1.132.61010: 34536 2\/0\/0 CNAME s3-directional-w.amazonaws.com., (97)
\n09:36:56.673894 IP 192.168.1.132.61011 > resolver1.opendns.com.domain: 18143+ A? s3.amazonaws.com. (34)
\n09:36:56.715913 IP resolver1.opendns.com.domain > 192.168.1.132.61011: 18143 2\/0\/0 CNAME s3-1.amazonaws.com., A s3.amazonaws.com (69)
\n09:36:57.263186 IP 192.168.1.132.61012 > resolver1.opendns.com.domain: 32069+ PTR? 171.206.21.72.in-addr.arpa. (44)
\n09:36:57.306060 IP resolver1.opendns.com.domain > 192.168.1.132.61012: 32069 1\/0\/0 PTR s3.amazonaws.com. (74)<\/p>\n
Here we’re getting 2 answer records (the “2” in 2\/0\/0) on the SRV requests, which are CNAME records, first being s3-directional-w.amazonaws.com, second being s3-1.amazonaws.com. CNAME records are “nickname” records, which point to true name, or A Record. Right after that our Mac asks for an A record on the first CNAME that was returned to us (s3-directional-w.amazonaws.com) to get back the actual IP address (72.21.207.246), which you can verify by using the dig program.<\/a><\/p>\nThis fix alone has made my Internet connection much faster since my ISP’s DNS servers were sometimes under heavy load and slow to respond to DNS queries. Most of the time, I’d get name requests done in 200-400ms. Not noticeably slow. But, on occasion domain name lookups would timeout after 7 seconds, multiple times, resulting in up to 21 seconds of waiting for a single name lookup request to occur. This is excruciatingly long when I often open up multiple different websites one right after another when starting a browsing session. To make matters worse, many websites are getting into the practice of placing different parts of the web page on different domain names. Let’s take CNN.com for example. To load this single page of President Obama… oh, I mean senator Obama, waving to the crowd, tcpdump showed name lookups for the following domains:<\/p>\n
<\/a><\/p>\n\n- www.cnn.com<\/li>\n
- edition.cnn.com<\/li>\n
- i.cdn.turner.com<\/li>\n
- i2.cdn.turner.com<\/li>\n
- svcs.cnn.com<\/li>\n
- ads.cnn.com<\/li>\n
- i.cnn.net<\/li>\n
- ad.doubleclick.net<\/li>\n
- metrics.cnn.com<\/li>\n
- m1.2mdn.net<\/li>\n<\/ol>\n
One Page. Ten domains. Ten DNS lookups. Ouch. And I’m not including PTR\/Reverse Lookups for each domain, making it really 20 DNS queries.<\/p>\n
And does anyone wonder why problematic DNS performance in Leopard would slow web browsing to a crawl?
\n<\/a><\/p>\nDisable IPv6 DNS Lookups<\/h3>\n
Firefox and Camino by default do DNS lookups using IPv6 addresses by default, reverting to IPv4 if that fails. This can be a problem when the router that we are using to connect to the Internet doesn’t work with IPv6 DNS requests properly, if at all.<\/p>\n
To disable IPv6 DNS lookups in Firefox and Camino, type the following into the browser address bar:
\nabout:config<\/code>
\nIf you see a large “Be Careful” warning, simply click on “I understand and I wish to continue”. Next, you will see a long list of Preference Name, Status, Type and Value columns. Above all that is a bar in which you can filter which preferences to view. In the Filter bar type: ipv6
\nYou should see something like the following:<\/p>\n<\/p>\n
To change the value for this preference simply double-click the name “network.dns.disableIPv6”. The value you want is “true”, which means that IPv6 DNS requests are disabled. If this value is already “true”, don’t double-click this preference.<\/p>\n
To make the preference change active, close the browser and Quit Firefox completely (Apple Key + Q), then restart Firefox. You may<\/em> have to repeat this Quitting and Restarting to have the change take effect.<\/p>\nAfter making this change, Firefox (or Camino if that’s what you’re using) will use IPv4 only when performing DNS requests.<\/p>\n
<\/a><\/p>\nUpdate DNS Servers on Router<\/h3>\n
If you have access to your router’s administration web page, you may be able to set its DNS servers manually, avoiding the buggy DNS servers located at your ISP. Refer the manual that came with your router, or speak with your service provider about how to access the router’s administration page. Often this page can be accessed at http:\/\/192.168.1.1, so simply type that address into your browser’s address bar and press Enter. With any luck you’ll have access to the Administration login page. Many router administration sites don’t have passwords, don’t have usernames, or use very simple standard passwords such as “admin”, leaving it up to the owner to change it to something more secure. Visit the router manufacturer’s web site for more information about accessing the administration features of the router.<\/p>\n
Keep in mind that updating the router’s DNS servers will not avoid problems you may be encountering with the router’s poor DNS Proxying\/Forwarding support. If your router can’t handle IPv6 or SRV requests coming from your Mac, these DNS requests will stop here at the router and will not be forwarded onto the new DNS servers you’ve just specified, making this fix completely ineffective. DNS requests that your router cannot understand will likely be ignored or returned without answer results. DNS Proxy\/Forwarding issues are discussed further in the next section.<\/p>\n
<\/a><\/p>\nUpdate Router Firmware<\/h3>\n
For those who need to continue making DNS requests through their router, rather than directly against DNS servers, due to VPN or tunneling requirements, your fix may lie in upgrading your router’s firmware. Routers are in effect “the” DNS server for the majority of home broadband Internet connections since it acts as the DNS Proxy, taking domain name lookup requests from your computer, passes them to the ISP’s DNS servers for resolution, receives the results, and finally passes the name lookup results back to your Mac, all transparently in the background. This is why your DNS server address is the same as your “Gateway” which is a fancy name for your router, since all traffic passes through this “gate” of sorts. Thus the Gateway address is often 192.168.1.1, which in turn is also the address of the DNS server for the “Automatic” network Location in Leopard.<\/p>\n
Be aware that DNS Proxying is a common failure point in the domain name resolution chain. If the router is not compliant with the latest Internet Task Force standards, it may not know what to do with SRV requests (which Leopard now uses) and may simply ignore them, return empty results, or return NXDOMAIN (non-existent) errors. Again, a firmware update may bring your router up to the latest standards for DNS servers.<\/p>\n
If the router is a DSL Cable modem\/router, contact your ISP and ask whether there is updated firmware for the model of router you’re using. If you’re more of a do-it-yourself person you can attempt to find the manufacturer of the router\/modem and find the latest firmware from their website, if available. Disclaimer<\/strong>: updating the firmware of your router with the wrong firmware, or not completing the firmware update due to power loss, will render your router useless<\/strong>. Do not attempt to update the firmware if you are not confident of what you’re doing.<\/p>\nNew Information<\/h2>\n
<\/a>
\n Update 080606<\/strong>: As per a discussion on Macosxhints forums<\/a>, Apple may have changed the order in which DNS servers are used<\/span>. In the screenshot, the listed DNS servers are used in the order they are seen, under Leopard 10.5.2. This is true for a manually configured Network Location. In 10.5.3, users are seeing the opposite order, i.e<\/span>. In a DCHP configured Network Location (automatically done by your DSL router and ISP), the DNS servers listed are used in reverse order. (Bottom server is used first, then moves up the list as needed). Thus adding a new Network Location to use a given DNS server<\/a> would be unnecessary.<\/p>\n<\/a><\/p>\nUpdate 080614<\/strong>: Airport Wireless Connection Drops – This is a common problem for Leopard users after upgrading to 10.5.2. This isn’t exactly a slow Internet problem, but rather, a “no Internet” problem. See this related post on wireless problems on Apple AirPort connections<\/a>.<\/p>\nThe Beginning<\/h2>\n
This is not the end, but rather, the beginning of an article that I hope will continue to grow in scope to cover more problems and offer more solutions to slow Internet problems in Leopard. Please leave a comment if you’re experiencing a problem not discussed here and we’ll get working on diagnosing the issue and searching for a cure.<\/p>\n
If you’re having troubles implementing a fix listed above, leave a comment and I’ll try to expand on the topic or reword it so that it is understandable to you and to everyone else I’ve confused.<\/p>\n
Fixes\/Solutions\/Workarounds<\/h3>\n\n- Use better faster DNS servers, like OpenDNS.org (208.67.222.222, 208.67.220.220)<\/a>.<\/li>\n
- Connect directly to DNS servers to avoid DNS forwarding through your router (acting as a DNS proxy)<\/a>.<\/li>\n
- Turn off IPv6 DNS lookups in Firefox\/Camino<\/a> (references: mozilla.org<\/a>).<\/li>\n
- If DNS forwarding is required, <\/a>change the DNS servers directly on the router.<\/li>\n
- Update your router’s firmware<\/a> (references: jungledisk.com<\/a>, ubuntu.com<\/a>) for better SRV and IPv6 handling and better performance overall.<\/li>\n
- Below are detailed instructions on applying these fixes to slow dns lookups\/slow Internet on Leopard<\/li>\n<\/ul>\n
Details<\/h2>\n
After upgrading to Leopard, plenty of Mac OS X users have complained of “slow internet” when browsing the web, yet Windows PCs or Macs with Tiger (10.4) on the same network are much faster.<\/p>\n
DNS Lookups<\/h3>\n
A domain name lookup or DNS lookup is done every time you visit a web page, say “apple.com”, as you’re actually visiting “17.149.160.49”. A DNS Resolver on your computer sends a request to a DNS Server that handles this lookup or translation from names (easy to remember) to numbers (hard to remember). Once your browser has this numerical IP address it can start loading the web pages at that server location.<\/p>\n
Domain Name System Lookups in Leopard<\/h3>\n
With Leopard, a major change occurred in DNS lookups. Any program in Leopard that can use version 6 IP addresses (IPv6 explained below) will send out a new type of DNS lookup request – the SRV Record. In Tiger and previous OS X versions, DNS lookups were A record requests.<\/p>\n
SRV records are new (sadly, 8 years old is new in the DNS world), provide more information than A records, but have terrible support<\/strong> in terms of hardware (your DSL router or cable modem) and DNS servers that answer with SRV information. For every SRV request that Leopard sends it must wait for a valid reply. If the request fails, Leopard must try again. If it fails again, Leopard will finally ask for an A record. This is one reason why Mac users are experiencing slow Internet on new Macs with Leopard or after upgrading to Leopard from Tiger.<\/p>\nDomain Name Lookup Chain<\/h3>\n
Diagnosing slow Internet problems under Leopard is difficult due to the many different slowdowns that can occur along the domain name lookup chain when connecting to the Internet in OS X. For an application like Firefox or Safari to find a domain name, this is roughly what happens:<\/p>\n
\n- Firefox\/Safari is asked to load a web page at a domain name (example: “apple.com”).<\/li>\n
- Browser starts work on getting an IP address for that domain (a domain name lookup).<\/li>\n
- Browser checks for recently translated domain names in its own internal “cache” and thus already has the IP address.<\/li>\n
- If “apple.com” is not found in cache, Firefox\/Safari then asks Directory Services (an OS X program that does DNS lookups) for the answer.<\/li>\n
- Directory Services (DS) searches for the domain in its own<\/em> DS cache (view the DS cache using Terminal<\/a>: dscacheutil -cachedump -entries).<\/li>\n
- If domain is not found in cache, DS checks flat (text) files such as \/etc\/hosts for the domain name (see the file using Terminal: cat \/etc\/hosts).<\/li>\n
- If domain is still not found then DS sends a domain name lookup request to the first DNS server listed for your AirPort wireless card or your Ethernet card (your network interfaces<\/em>). The first (and usually only) DNS server is often your router (often listed as 192.168.1.1 in System Preferences => Network => Advanced => DNS tab).<\/li>\n
- If the router doesn’t<\/em> recognize the name lookup request (SRV\/IPv6), the request will be either ignored, returned without result, returned with error. If the router does<\/em> recognize the DNS request, it checks its own DNS cache for a matching domain lookup.<\/li>\n
- If domain name is not found<\/em> in cache, the router forwards the request to the ISP’s DNS server.<\/li>\n
- If the first ISP DNS server doesn’t respond or doesn’t have the record, the router sends a second lookup request to the next DNS server listed in its configuration. Continue until all DNS servers are exhausted.<\/li>\n
- When name lookup result is received by router, it saves the result to cache, then forwards the domain name record back to the requesting computer.<\/li>\n
- Directory Services on Leopard, receives the answer, places it in cache, then returns the results to the requesting application: your browser.<\/li>\n
- Firefox\/Safari receives the DNS record, with IP address, stores it in cache, then starts to retrieve the web page at that location.<\/li>\n<\/ol>\n
<\/p>\n
(Illustration by Lion Kimbro on Wikipedia – Domain Name Systems article<\/a>)<\/p>\nAny one of the links in the chain can be a potential source of slow Internet speeds when browsing or retrieving mail, etc. The difficulty lies is finding out where the problem exists and how it can be fix. Compound this complexity with the number of different DSL routers in use in homes, the number of different firmware (software inside the router), number of different ISP DNS servers<\/p>\n
Caches<\/h3>\n
Caches store recent domain name lookup results in order to save time when the domain is requested again. Each time a domain name lookup is made, caches are checked to see if the lookup has occurred recently and if so, use the cache result. If no result is found in cache, the domain name lookup has failed and the DNS lookup request continues down the chain. A domain lookup may fail all the way down the chain until it’s finally resolved with the second or third DNS server listed, taking maybe 15 seconds to finally succeed. But, once domain lookup has been successfully performed, this domain request “answer” is cached all the way back<\/em> up the chain, for varying amounts of time. Browsers like Safari and Firefox normally cache domain name lookups for 1 minute (30 minutes if you’re Internet Explorer in Vista). Leopard’s Directory Services program caches lookups for one hour (3600 seconds) by default.<\/p>\nOnce a successful domain lookup has occurred, web pages from the same site will load very quickly, since the domain and its IP address are known and cached in memory. When the cached domain lookup result expires, the vicious cycle of slow domain lookups restarts. This often leads to the confusing pattern of fast Internet \/ slow Internet performance that can be seen sporadically throughout a browsing session.<\/p>\n
IPv6<\/h3>\n
IPv6, the new way of addressing all things on the Internet<\/a>, is important and necessary as we’ll eventually run out of IPv4 addresses (like 17.149.160.49). But part of the issue with slow browsing and slow Internet on Leopard is the combination of how IPv6 is used in Mac OS X and the current state of DSL routers and cable modems.<\/p>\nWhenever a program on Leopard can use IPv6 addressing, such as Firefox, it will request IP addresses for domains in IPv6 and if that fails, Firefox will then try IPv4 domain lookups. The reason this adds to the slow Internet problem is that many routers and DSL or cable modems in peoples homes are not capable of handling\/routing IPv6 domain name queries (properly). This can cause repeated, failed DNS queries in IPv6 format, with the requesting application eventually falling back to sending IPv4 domain lookup requests that are successfully answered. The unfortunate problem with this “IPv6 then IPv4” order of domain lookups is users end up with delays of 5 to 10 seconds “looking up” a domain name<\/a>, which is not a very long time to wait, but suffering short delays every time you visit a different website can be extremely frustrating.<\/p>\nSRV (Service Record) Requests<\/h3>\n
Part of the issue may be related to Apple’s decision to follow the Internet Engineering Task Force<\/a>‘s recommendation of using SRV queries instead of “A record” queries when looking up domain names in Leopard.<\/p>\nThe problem with Leopard asking for SRV records<\/a> from DNS servers is that many DNS servers still don’t recognize or respond to SRV type DNS requests, or respond with a non-existent domain (NXDOMAIN) error code. This is not exactly Apple’s fault for asking, it’s actually the fault of DNS server owners who are not updating their servers to the latest standards. Regardless, whenever a program like a web browser requests a DNS record and gets failed responses, or no response at all, the program retries its requests, but only after a certain delay. Each failed SRV request and subsequent retry adds time the user must wait before the browser or application eventually gives up on the SRV requests and tries an old-school basic A record request in an attempt to get the IP address of the domain name. And all DNS servers answer to A record requests, even the old dingy ones not following the latest IETF standards. You, the user, sees this request — no response — retry dance as the browser taking a long time “Looking up domain.com….”, often seen as such on the browser status bar at the bottom left hand corner of the window. Only when the browser or application has received a valid IP address from a domain lookup can it contact the web server and start to download the HTML and display the page.<\/p>\nTimeouts<\/h3>\n
The delay between lookup retries is important to prevent overloading DNS servers, DNS resolvers (like Directory Services on your Mac) and simply makes sense. It’s similar to walking up to someone’s house and knocking on the door: Normally you wait a few moments for a response before trying again. If you don’t wait, you don’t know whether no one’s home, or whether they’re just taking a few seconds to respond. Continued knocking doesn’t help you. (And perhaps will earn you a stern look if not make you the target of a hissy fit).<\/p>\n
Hammering a DNS server with domain lookups without pause is not very productive since the DNS server will simply drop (not answer) requests that it cannot handle within a timely fashion, based on its current load and worse, may get you blocked from the DNS server.<\/p>\n
Next we’ll see how we can solve or workaround the issues discussed above that could be slowing down Leopard’s Internet speed.<\/p>\n
<\/a><\/p>\nSolutions<\/h2>\n\n- Direct DNS \/ Better DNS<\/a><\/li>\n
- Disable IPv6 DNS Lookups<\/a><\/li>\n
- Update DNS Servers on Router<\/a><\/li>\n
- Update Router Firmware<\/a><\/li>\n<\/ul>\n
<\/a><\/p>\nDirect DNS \/ Better DNS<\/h3>\n
Update 080606: Leopard 10.5.3 may have changed the order in which DNS Servers are used<\/a>.<\/span><\/p>\nUpdate 080606: DNS servers entered on a DHCP configured setup are used in reverse order. I.e. the last server entered is the first to be used. If you’ve manually configured a network location, DNS servers are used in the order that you’ve entered them\/see them.<\/p>\n
New 080606<\/strong>: If you wish to save your current network setup and have the option of returning to it easily, follow the instructions for Creating a New Network Location<\/a>. Otherwise, follow the instructions immediately below to quickly add new DNS servers.<\/p>\nAdd DNS servers to Current Network Configuration<\/h4>\n
This is the quickest & easiest way to use new DNS servers, which is to simply add them to the DNS tab found in System Preferences => Network => Advanced => click on DNS tab.<\/p>\n
<\/a><\/p>\nClick on the + sign at the bottom left hand corner near IPv6 or IPv6 addresses and type in the addresses of the DNS servers you wish, in reverse priority order. (Recommended: OpenDNS servers at 208.67.220.220 and 208.67.222.222). I.e. the server that you want to use first, enter it last. Afterwards, click Ok. Then in the Network pane, click Apply to make your changes active. If you’re using an AirPort wireless connection, wait a few moments for the connection to be re-established
\n<\/a><\/p>\nCreating a New Network Location<\/h4>\n
The advantage of creating a new network location is the ease of which you can move back and forth between different network setups. By creating and using a new network location, you can always revert your changes by simply selecting your original (Automatic) network location from the Location drop down list.<\/p>\n
In Leopard, open System Preferences<\/strong> => Network<\/strong> => click the Advanced<\/strong> button (bottom right corner)<\/p>\n
\nClick TCP\/IP<\/strong> tab (top left).
\nWrite down on a piece of paper (or in TextEdit) the IPv4 Address<\/strong>, Subnet Mask<\/strong> (255.255.255.0), Router<\/strong>, and Configure IPv6<\/strong> setting. Click Cancel<\/strong>.<\/p>\n<\/p>\n
Find the Location<\/strong> drop down at top of the Network preferences pane. Click it and choose Edit Locations<\/strong>.<\/p>\n
\nHighlight “Automatic” if not already
\nClick the Gear icon<\/strong> on the bottom center, choose Duplicate Location<\/strong><\/p>\n<\/strong>
\nChoose a name, I used “Home”.
\nChange the Location<\/strong> drop down box by clicking on “Automatic” and then switch it to “Home” (or the name you chose in the last step)
\nYou’ll see the following:<\/p>\n
\nSelect Airport<\/strong> on the left (or Ethernet<\/strong> if you’re not using a wireless connection).
\nClick Advanced<\/strong> at the bottom right.
\nClick on the TCP\/IP<\/strong> tab-button.
\nChange the Configure IPv4<\/strong> drop down box to “Manually”.
\nHere’s where you use the values you saved in Step 2. Fill out IPv4 address<\/strong>, subnet mask<\/strong>, router<\/strong>, configure IPv6<\/strong> settings. Do not<\/em> click OK<\/strong>, instead click on DNS<\/strong> near the top.
\nClick the +<\/strong> button, bottom left hand corner. This creates a blue outline under DNS Servers on the left half of this window.<\/p>\n<\/p>\n
<\/p>\n
Enter in the DNS server of your choice. I recommend OpenDNS at 208.67.222.222. (Don’t include a period at the end). Add a second OpenDNS server by clicking again on the + button and entering 208.67.220.220. These DNS servers will automatically redirect you to the closest \/ best server for you, regardless of whether you’re in France (like me) or in North America. Click OK<\/strong>. You should be returned to the Network preferences pane and see something like the following:<\/p>\n<\/p>\n
At this point you’ve created a new Location called “Home”, having setup AirPort or Ethernet with the correct settings and “Services” (i.e. DNS), but none of these changes have been made active. Let’s make a backup of the configuration file that will be updated before<\/em> you apply your changes. In Finder, click on the hard disk icon at the top left corner (usually Macintosh HD), then navigate to this directory: \/Library\/Preferences\/SystemConfiguration<\/strong> and find this file: preferences.plist<\/strong>. Simply copy the file to your Documents folder or to a spot of your choice. If you have to rollback the applied changes, you can copy this file back to the above location. If you’re using Time Machine, this file should be backed up already. Now you know where this file is, so replacing it with a Time Machine version should be straightforward.<\/p>\nBefore we make our changes effective, we’re going to check how DNS requests are handled now, before the changes, and after to make sure we’ve changed our Network Settings properly.
\n<\/a>
\nLeave the Network window open as is and open up a Terminal window<\/a>. We’re going to be using the tcpdump program to listen to DNS traffic<\/a> between your computer and your DNS server.<\/p>\nType this command and hit Enter: sudo tcpdump -i en1 -s 128 port 53<\/code><\/p>\n(If you’re using Ethernet with a cable, use en0<\/strong> instead of en1<\/strong>, which is the AirPort wireless interface).<\/p>\nSupply your password when asked to do so.<\/p>\n
You should see something like the following:<\/p>\n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
\nlistening on en1, link-type EN10MB (Ethernet), capture size 96 bytes<\/code><\/p>\ntcpdump should now be running.<\/p>\n
Open up another Terminal window and type the following command: curl http:\/\/www.csu.edu<\/code><\/p>\nThis uses the curl program to read the web page located at www.csu.edu.<\/p>\n
Going back to your tcpdump window you should see something similar to this:<\/p>\n
00:31:37.026520 IP 192.168.1.132.56645 > WANADOO-D310.domain: 19279+ SRV? _http._tcp.www.csu.edu. (40)
\n00:31:37.029352 IP WANADOO-D310.domain > 192.168.1.132.56645: 19279* 0\/0\/0 (40)
\n00:31:37.029849 IP 192.168.1.132.56646 > WANADOO-D310.domain: 49549+ SRV? _http._tcp.www.csu.edu. (40)
\n00:31:37.032657 IP WANADOO-D310.domain > 192.168.1.132.56646: 49549* 0\/0\/0 (40)
\n00:31:37.034345 IP 192.168.1.132.56647 > WANADOO-D310.domain: 46004+ A? www.csu.edu. (29)
\n00:31:37.279043 IP WANADOO-D310.domain > 192.168.1.132.56647: 46004 1\/0\/0 A www.csu.edu (45)<\/p>\n
Notice 192.168.1.132. That’s me, or really, my MacBook Pro’s AirPort wireless card. Then there’s a greater than sign (>) showing the direction of DNS traffic. WANADOO-D310 is my DNS server, which is actually the DSL modem\/router, a.k.a. 192.168.1.1, which is passing domain name lookups to the real DNS servers at my Internet Service Provider (WANADOO, yeah I know goofy name). Remember the network settings we wrote down before starting all this? You’ll notice that the DNS server is 192.168.1.1.<\/p>\n
OK, we’ve got a baseline of what our Mac is doing when looking up domain names, let’s apply our new network location “Home” that we created and see the difference.<\/p>\n
Back on the Network preference pane, notice the Apply<\/strong> button on the bottom right hand corner. Once you apply your changes, your Mac will begin using the new Location you’ve created.<\/p>\nTake the plunge and click on Apply<\/strong>.<\/p>\nFor AirPort wireless connections, you may have to click the Turn AirPort Off button, wait fifteen seconds, then click Turn AirPort On again in order for the new DNS settings to be used.<\/p>\n
Going back to the Terminal window where we executed the curl command, and with our changes set, let’s execute another: curl http:\/\/www.unc.edu<\/code><\/p>\nResults will look like the following:<\/p>\n
00:32:33.562589 IP 192.168.1.132.56663 > resolver1.opendns.com.domain: 39356+ SRV? _http._tcp.www.unc.edu. (40)
\n00:32:33.767237 IP resolver1.opendns.com.domain > 192.168.1.132.56663: 39356 NXDomain 0\/0\/0 (40)
\n00:32:33.767856 IP 192.168.1.132.56664 > resolver1.opendns.com.domain: 62833+ SRV? _http._tcp.www.unc.edu. (40)
\n00:32:33.809161 IP resolver1.opendns.com.domain > 192.168.1.132.56664: 62833 NXDomain 0\/0\/0 (40)
\n00:32:33.811130 IP 192.168.1.132.56665 > resolver1.opendns.com.domain: 45293+ A? www.unc.edu. (29)
\n00:32:33.853070 IP resolver1.opendns.com.domain > 192.168.1.132.56665: 45293 1\/0\/0 A www.unc.edu (45)<\/p>\n
Notice what’s changed? WANADOO-D310.doman has changed to resolver1.opendns.com.domain. This is OpenDNS’ name for the DNS server we started using, 208.67.222.222, which we entered as our DNS for the “Home” location. Also, note how instead of just getting a 0\/0\/0 response, we’re getting NXDOMAIN 0\/0\/0? That’s at least the DNS server responding<\/em> saying: that domain doesn’t exist (not exactly true, since the domain does exist, but it just doesn’t have an SRV record), rather than the DNS server sending back nothing, not even an error code. Also, notice how our Mac tried twice on asking for SRV records, and the DNS server responded twice, that no record exists for that domain, and then finally our Mac asks for an A record (A?) and gets one answer record back (1\/0\/0 A ww.unc.edu).<\/p>\nIf you want to see a domain that actually has a proper SRV record, try this in the curl terminal window: curl http:\/\/s3.amazonaws.com<\/code><\/p>\nResults should be something like this:<\/p>\n
09:36:56.440037 IP 192.168.1.132.61010 > resolver1.opendns.com.domain: 34536+ SRV? _http._tcp.s3.amazonaws.com. (45)
\n09:36:56.671881 IP resolver1.opendns.com.domain > 192.168.1.132.61010: 34536 2\/0\/0 CNAME s3-directional-w.amazonaws.com., (97)
\n09:36:56.673894 IP 192.168.1.132.61011 > resolver1.opendns.com.domain: 18143+ A? s3.amazonaws.com. (34)
\n09:36:56.715913 IP resolver1.opendns.com.domain > 192.168.1.132.61011: 18143 2\/0\/0 CNAME s3-1.amazonaws.com., A s3.amazonaws.com (69)
\n09:36:57.263186 IP 192.168.1.132.61012 > resolver1.opendns.com.domain: 32069+ PTR? 171.206.21.72.in-addr.arpa. (44)
\n09:36:57.306060 IP resolver1.opendns.com.domain > 192.168.1.132.61012: 32069 1\/0\/0 PTR s3.amazonaws.com. (74)<\/p>\n
Here we’re getting 2 answer records (the “2” in 2\/0\/0) on the SRV requests, which are CNAME records, first being s3-directional-w.amazonaws.com, second being s3-1.amazonaws.com. CNAME records are “nickname” records, which point to true name, or A Record. Right after that our Mac asks for an A record on the first CNAME that was returned to us (s3-directional-w.amazonaws.com) to get back the actual IP address (72.21.207.246), which you can verify by using the dig program.<\/a><\/p>\nThis fix alone has made my Internet connection much faster since my ISP’s DNS servers were sometimes under heavy load and slow to respond to DNS queries. Most of the time, I’d get name requests done in 200-400ms. Not noticeably slow. But, on occasion domain name lookups would timeout after 7 seconds, multiple times, resulting in up to 21 seconds of waiting for a single name lookup request to occur. This is excruciatingly long when I often open up multiple different websites one right after another when starting a browsing session. To make matters worse, many websites are getting into the practice of placing different parts of the web page on different domain names. Let’s take CNN.com for example. To load this single page of President Obama… oh, I mean senator Obama, waving to the crowd, tcpdump showed name lookups for the following domains:<\/p>\n
<\/a><\/p>\n\n- www.cnn.com<\/li>\n
- edition.cnn.com<\/li>\n
- i.cdn.turner.com<\/li>\n
- i2.cdn.turner.com<\/li>\n
- svcs.cnn.com<\/li>\n
- ads.cnn.com<\/li>\n
- i.cnn.net<\/li>\n
- ad.doubleclick.net<\/li>\n
- metrics.cnn.com<\/li>\n
- m1.2mdn.net<\/li>\n<\/ol>\n
One Page. Ten domains. Ten DNS lookups. Ouch. And I’m not including PTR\/Reverse Lookups for each domain, making it really 20 DNS queries.<\/p>\n
And does anyone wonder why problematic DNS performance in Leopard would slow web browsing to a crawl?
\n<\/a><\/p>\nDisable IPv6 DNS Lookups<\/h3>\n
Firefox and Camino by default do DNS lookups using IPv6 addresses by default, reverting to IPv4 if that fails. This can be a problem when the router that we are using to connect to the Internet doesn’t work with IPv6 DNS requests properly, if at all.<\/p>\n
To disable IPv6 DNS lookups in Firefox and Camino, type the following into the browser address bar:
\nabout:config<\/code>
\nIf you see a large “Be Careful” warning, simply click on “I understand and I wish to continue”. Next, you will see a long list of Preference Name, Status, Type and Value columns. Above all that is a bar in which you can filter which preferences to view. In the Filter bar type: ipv6
\nYou should see something like the following:<\/p>\n<\/p>\n
To change the value for this preference simply double-click the name “network.dns.disableIPv6”. The value you want is “true”, which means that IPv6 DNS requests are disabled. If this value is already “true”, don’t double-click this preference.<\/p>\n
To make the preference change active, close the browser and Quit Firefox completely (Apple Key + Q), then restart Firefox. You may<\/em> have to repeat this Quitting and Restarting to have the change take effect.<\/p>\nAfter making this change, Firefox (or Camino if that’s what you’re using) will use IPv4 only when performing DNS requests.<\/p>\n
<\/a><\/p>\nUpdate DNS Servers on Router<\/h3>\n
If you have access to your router’s administration web page, you may be able to set its DNS servers manually, avoiding the buggy DNS servers located at your ISP. Refer the manual that came with your router, or speak with your service provider about how to access the router’s administration page. Often this page can be accessed at http:\/\/192.168.1.1, so simply type that address into your browser’s address bar and press Enter. With any luck you’ll have access to the Administration login page. Many router administration sites don’t have passwords, don’t have usernames, or use very simple standard passwords such as “admin”, leaving it up to the owner to change it to something more secure. Visit the router manufacturer’s web site for more information about accessing the administration features of the router.<\/p>\n
Keep in mind that updating the router’s DNS servers will not avoid problems you may be encountering with the router’s poor DNS Proxying\/Forwarding support. If your router can’t handle IPv6 or SRV requests coming from your Mac, these DNS requests will stop here at the router and will not be forwarded onto the new DNS servers you’ve just specified, making this fix completely ineffective. DNS requests that your router cannot understand will likely be ignored or returned without answer results. DNS Proxy\/Forwarding issues are discussed further in the next section.<\/p>\n
<\/a><\/p>\nUpdate Router Firmware<\/h3>\n
For those who need to continue making DNS requests through their router, rather than directly against DNS servers, due to VPN or tunneling requirements, your fix may lie in upgrading your router’s firmware. Routers are in effect “the” DNS server for the majority of home broadband Internet connections since it acts as the DNS Proxy, taking domain name lookup requests from your computer, passes them to the ISP’s DNS servers for resolution, receives the results, and finally passes the name lookup results back to your Mac, all transparently in the background. This is why your DNS server address is the same as your “Gateway” which is a fancy name for your router, since all traffic passes through this “gate” of sorts. Thus the Gateway address is often 192.168.1.1, which in turn is also the address of the DNS server for the “Automatic” network Location in Leopard.<\/p>\n
Be aware that DNS Proxying is a common failure point in the domain name resolution chain. If the router is not compliant with the latest Internet Task Force standards, it may not know what to do with SRV requests (which Leopard now uses) and may simply ignore them, return empty results, or return NXDOMAIN (non-existent) errors. Again, a firmware update may bring your router up to the latest standards for DNS servers.<\/p>\n
If the router is a DSL Cable modem\/router, contact your ISP and ask whether there is updated firmware for the model of router you’re using. If you’re more of a do-it-yourself person you can attempt to find the manufacturer of the router\/modem and find the latest firmware from their website, if available. Disclaimer<\/strong>: updating the firmware of your router with the wrong firmware, or not completing the firmware update due to power loss, will render your router useless<\/strong>. Do not attempt to update the firmware if you are not confident of what you’re doing.<\/p>\nNew Information<\/h2>\n
<\/a>
\n Update 080606<\/strong>: As per a discussion on Macosxhints forums<\/a>, Apple may have changed the order in which DNS servers are used<\/span>. In the screenshot, the listed DNS servers are used in the order they are seen, under Leopard 10.5.2. This is true for a manually configured Network Location. In 10.5.3, users are seeing the opposite order, i.e<\/span>. In a DCHP configured Network Location (automatically done by your DSL router and ISP), the DNS servers listed are used in reverse order. (Bottom server is used first, then moves up the list as needed). Thus adding a new Network Location to use a given DNS server<\/a> would be unnecessary.<\/p>\n<\/a><\/p>\nUpdate 080614<\/strong>: Airport Wireless Connection Drops – This is a common problem for Leopard users after upgrading to 10.5.2. This isn’t exactly a slow Internet problem, but rather, a “no Internet” problem. See this related post on wireless problems on Apple AirPort connections<\/a>.<\/p>\nThe Beginning<\/h2>\n
This is not the end, but rather, the beginning of an article that I hope will continue to grow in scope to cover more problems and offer more solutions to slow Internet problems in Leopard. Please leave a comment if you’re experiencing a problem not discussed here and we’ll get working on diagnosing the issue and searching for a cure.<\/p>\n
If you’re having troubles implementing a fix listed above, leave a comment and I’ll try to expand on the topic or reword it so that it is understandable to you and to everyone else I’ve confused.<\/p>\n
Details<\/h2>\n
After upgrading to Leopard, plenty of Mac OS X users have complained of “slow internet” when browsing the web, yet Windows PCs or Macs with Tiger (10.4) on the same network are much faster.<\/p>\n
DNS Lookups<\/h3>\n
A domain name lookup or DNS lookup is done every time you visit a web page, say “apple.com”, as you’re actually visiting “17.149.160.49”. A DNS Resolver on your computer sends a request to a DNS Server that handles this lookup or translation from names (easy to remember) to numbers (hard to remember). Once your browser has this numerical IP address it can start loading the web pages at that server location.<\/p>\n
Domain Name System Lookups in Leopard<\/h3>\n
With Leopard, a major change occurred in DNS lookups. Any program in Leopard that can use version 6 IP addresses (IPv6 explained below) will send out a new type of DNS lookup request – the SRV Record. In Tiger and previous OS X versions, DNS lookups were A record requests.<\/p>\n
SRV records are new (sadly, 8 years old is new in the DNS world), provide more information than A records, but have terrible support<\/strong> in terms of hardware (your DSL router or cable modem) and DNS servers that answer with SRV information. For every SRV request that Leopard sends it must wait for a valid reply. If the request fails, Leopard must try again. If it fails again, Leopard will finally ask for an A record. This is one reason why Mac users are experiencing slow Internet on new Macs with Leopard or after upgrading to Leopard from Tiger.<\/p>\n Diagnosing slow Internet problems under Leopard is difficult due to the many different slowdowns that can occur along the domain name lookup chain when connecting to the Internet in OS X. For an application like Firefox or Safari to find a domain name, this is roughly what happens:<\/p>\n (Illustration by Lion Kimbro on Wikipedia – Domain Name Systems article<\/a>)<\/p>\n Any one of the links in the chain can be a potential source of slow Internet speeds when browsing or retrieving mail, etc. The difficulty lies is finding out where the problem exists and how it can be fix. Compound this complexity with the number of different DSL routers in use in homes, the number of different firmware (software inside the router), number of different ISP DNS servers<\/p>\n Caches store recent domain name lookup results in order to save time when the domain is requested again. Each time a domain name lookup is made, caches are checked to see if the lookup has occurred recently and if so, use the cache result. If no result is found in cache, the domain name lookup has failed and the DNS lookup request continues down the chain. A domain lookup may fail all the way down the chain until it’s finally resolved with the second or third DNS server listed, taking maybe 15 seconds to finally succeed. But, once domain lookup has been successfully performed, this domain request “answer” is cached all the way back<\/em> up the chain, for varying amounts of time. Browsers like Safari and Firefox normally cache domain name lookups for 1 minute (30 minutes if you’re Internet Explorer in Vista). Leopard’s Directory Services program caches lookups for one hour (3600 seconds) by default.<\/p>\n Once a successful domain lookup has occurred, web pages from the same site will load very quickly, since the domain and its IP address are known and cached in memory. When the cached domain lookup result expires, the vicious cycle of slow domain lookups restarts. This often leads to the confusing pattern of fast Internet \/ slow Internet performance that can be seen sporadically throughout a browsing session.<\/p>\n IPv6, the new way of addressing all things on the Internet<\/a>, is important and necessary as we’ll eventually run out of IPv4 addresses (like 17.149.160.49). But part of the issue with slow browsing and slow Internet on Leopard is the combination of how IPv6 is used in Mac OS X and the current state of DSL routers and cable modems.<\/p>\n Whenever a program on Leopard can use IPv6 addressing, such as Firefox, it will request IP addresses for domains in IPv6 and if that fails, Firefox will then try IPv4 domain lookups. The reason this adds to the slow Internet problem is that many routers and DSL or cable modems in peoples homes are not capable of handling\/routing IPv6 domain name queries (properly). This can cause repeated, failed DNS queries in IPv6 format, with the requesting application eventually falling back to sending IPv4 domain lookup requests that are successfully answered. The unfortunate problem with this “IPv6 then IPv4” order of domain lookups is users end up with delays of 5 to 10 seconds “looking up” a domain name<\/a>, which is not a very long time to wait, but suffering short delays every time you visit a different website can be extremely frustrating.<\/p>\n Part of the issue may be related to Apple’s decision to follow the Internet Engineering Task Force<\/a>‘s recommendation of using SRV queries instead of “A record” queries when looking up domain names in Leopard.<\/p>\n The problem with Leopard asking for SRV records<\/a> from DNS servers is that many DNS servers still don’t recognize or respond to SRV type DNS requests, or respond with a non-existent domain (NXDOMAIN) error code. This is not exactly Apple’s fault for asking, it’s actually the fault of DNS server owners who are not updating their servers to the latest standards. Regardless, whenever a program like a web browser requests a DNS record and gets failed responses, or no response at all, the program retries its requests, but only after a certain delay. Each failed SRV request and subsequent retry adds time the user must wait before the browser or application eventually gives up on the SRV requests and tries an old-school basic A record request in an attempt to get the IP address of the domain name. And all DNS servers answer to A record requests, even the old dingy ones not following the latest IETF standards. You, the user, sees this request — no response — retry dance as the browser taking a long time “Looking up domain.com….”, often seen as such on the browser status bar at the bottom left hand corner of the window. Only when the browser or application has received a valid IP address from a domain lookup can it contact the web server and start to download the HTML and display the page.<\/p>\n The delay between lookup retries is important to prevent overloading DNS servers, DNS resolvers (like Directory Services on your Mac) and simply makes sense. It’s similar to walking up to someone’s house and knocking on the door: Normally you wait a few moments for a response before trying again. If you don’t wait, you don’t know whether no one’s home, or whether they’re just taking a few seconds to respond. Continued knocking doesn’t help you. (And perhaps will earn you a stern look if not make you the target of a hissy fit).<\/p>\n Hammering a DNS server with domain lookups without pause is not very productive since the DNS server will simply drop (not answer) requests that it cannot handle within a timely fashion, based on its current load and worse, may get you blocked from the DNS server.<\/p>\n Next we’ll see how we can solve or workaround the issues discussed above that could be slowing down Leopard’s Internet speed.<\/p>\n <\/a><\/p>\n <\/a><\/p>\n Update 080606: Leopard 10.5.3 may have changed the order in which DNS Servers are used<\/a>.<\/span><\/p>\n Update 080606: DNS servers entered on a DHCP configured setup are used in reverse order. I.e. the last server entered is the first to be used. If you’ve manually configured a network location, DNS servers are used in the order that you’ve entered them\/see them.<\/p>\n New 080606<\/strong>: If you wish to save your current network setup and have the option of returning to it easily, follow the instructions for Creating a New Network Location<\/a>. Otherwise, follow the instructions immediately below to quickly add new DNS servers.<\/p>\n This is the quickest & easiest way to use new DNS servers, which is to simply add them to the DNS tab found in System Preferences => Network => Advanced => click on DNS tab.<\/p>\n Click on the + sign at the bottom left hand corner near IPv6 or IPv6 addresses and type in the addresses of the DNS servers you wish, in reverse priority order. (Recommended: OpenDNS servers at 208.67.220.220 and 208.67.222.222). I.e. the server that you want to use first, enter it last. Afterwards, click Ok. Then in the Network pane, click Apply to make your changes active. If you’re using an AirPort wireless connection, wait a few moments for the connection to be re-established The advantage of creating a new network location is the ease of which you can move back and forth between different network setups. By creating and using a new network location, you can always revert your changes by simply selecting your original (Automatic) network location from the Location drop down list.<\/p>\n In Leopard, open System Preferences<\/strong> => Network<\/strong> => click the Advanced<\/strong> button (bottom right corner)<\/p>\n Find the Location<\/strong> drop down at top of the Network preferences pane. Click it and choose Edit Locations<\/strong>.<\/p>\n Enter in the DNS server of your choice. I recommend OpenDNS at 208.67.222.222. (Don’t include a period at the end). Add a second OpenDNS server by clicking again on the + button and entering 208.67.220.220. These DNS servers will automatically redirect you to the closest \/ best server for you, regardless of whether you’re in France (like me) or in North America. Click OK<\/strong>. You should be returned to the Network preferences pane and see something like the following:<\/p>\n At this point you’ve created a new Location called “Home”, having setup AirPort or Ethernet with the correct settings and “Services” (i.e. DNS), but none of these changes have been made active. Let’s make a backup of the configuration file that will be updated before<\/em> you apply your changes. In Finder, click on the hard disk icon at the top left corner (usually Macintosh HD), then navigate to this directory: \/Library\/Preferences\/SystemConfiguration<\/strong> and find this file: preferences.plist<\/strong>. Simply copy the file to your Documents folder or to a spot of your choice. If you have to rollback the applied changes, you can copy this file back to the above location. If you’re using Time Machine, this file should be backed up already. Now you know where this file is, so replacing it with a Time Machine version should be straightforward.<\/p>\n Before we make our changes effective, we’re going to check how DNS requests are handled now, before the changes, and after to make sure we’ve changed our Network Settings properly. Type this command and hit Enter: (If you’re using Ethernet with a cable, use en0<\/strong> instead of en1<\/strong>, which is the AirPort wireless interface).<\/p>\n Supply your password when asked to do so.<\/p>\n You should see something like the following:<\/p>\n tcpdump should now be running.<\/p>\n Open up another Terminal window and type the following command: This uses the curl program to read the web page located at www.csu.edu.<\/p>\n Going back to your tcpdump window you should see something similar to this:<\/p>\n 00:31:37.026520 IP 192.168.1.132.56645 > WANADOO-D310.domain: 19279+ SRV? _http._tcp.www.csu.edu. (40) Notice 192.168.1.132. That’s me, or really, my MacBook Pro’s AirPort wireless card. Then there’s a greater than sign (>) showing the direction of DNS traffic. WANADOO-D310 is my DNS server, which is actually the DSL modem\/router, a.k.a. 192.168.1.1, which is passing domain name lookups to the real DNS servers at my Internet Service Provider (WANADOO, yeah I know goofy name). Remember the network settings we wrote down before starting all this? You’ll notice that the DNS server is 192.168.1.1.<\/p>\n OK, we’ve got a baseline of what our Mac is doing when looking up domain names, let’s apply our new network location “Home” that we created and see the difference.<\/p>\n Back on the Network preference pane, notice the Apply<\/strong> button on the bottom right hand corner. Once you apply your changes, your Mac will begin using the new Location you’ve created.<\/p>\n Take the plunge and click on Apply<\/strong>.<\/p>\n For AirPort wireless connections, you may have to click the Turn AirPort Off button, wait fifteen seconds, then click Turn AirPort On again in order for the new DNS settings to be used.<\/p>\n Going back to the Terminal window where we executed the curl command, and with our changes set, let’s execute another: Results will look like the following:<\/p>\n 00:32:33.562589 IP 192.168.1.132.56663 > resolver1.opendns.com.domain: 39356+ SRV? _http._tcp.www.unc.edu. (40) Notice what’s changed? WANADOO-D310.doman has changed to resolver1.opendns.com.domain. This is OpenDNS’ name for the DNS server we started using, 208.67.222.222, which we entered as our DNS for the “Home” location. Also, note how instead of just getting a 0\/0\/0 response, we’re getting NXDOMAIN 0\/0\/0? That’s at least the DNS server responding<\/em> saying: that domain doesn’t exist (not exactly true, since the domain does exist, but it just doesn’t have an SRV record), rather than the DNS server sending back nothing, not even an error code. Also, notice how our Mac tried twice on asking for SRV records, and the DNS server responded twice, that no record exists for that domain, and then finally our Mac asks for an A record (A?) and gets one answer record back (1\/0\/0 A ww.unc.edu).<\/p>\n If you want to see a domain that actually has a proper SRV record, try this in the curl terminal window: Results should be something like this:<\/p>\n 09:36:56.440037 IP 192.168.1.132.61010 > resolver1.opendns.com.domain: 34536+ SRV? _http._tcp.s3.amazonaws.com. (45) Here we’re getting 2 answer records (the “2” in 2\/0\/0) on the SRV requests, which are CNAME records, first being s3-directional-w.amazonaws.com, second being s3-1.amazonaws.com. CNAME records are “nickname” records, which point to true name, or A Record. Right after that our Mac asks for an A record on the first CNAME that was returned to us (s3-directional-w.amazonaws.com) to get back the actual IP address (72.21.207.246), which you can verify by using the dig program.<\/a><\/p>\n This fix alone has made my Internet connection much faster since my ISP’s DNS servers were sometimes under heavy load and slow to respond to DNS queries. Most of the time, I’d get name requests done in 200-400ms. Not noticeably slow. But, on occasion domain name lookups would timeout after 7 seconds, multiple times, resulting in up to 21 seconds of waiting for a single name lookup request to occur. This is excruciatingly long when I often open up multiple different websites one right after another when starting a browsing session. To make matters worse, many websites are getting into the practice of placing different parts of the web page on different domain names. Let’s take CNN.com for example. To load this single page of President Obama… oh, I mean senator Obama, waving to the crowd, tcpdump showed name lookups for the following domains:<\/p>\n One Page. Ten domains. Ten DNS lookups. Ouch. And I’m not including PTR\/Reverse Lookups for each domain, making it really 20 DNS queries.<\/p>\n And does anyone wonder why problematic DNS performance in Leopard would slow web browsing to a crawl? Firefox and Camino by default do DNS lookups using IPv6 addresses by default, reverting to IPv4 if that fails. This can be a problem when the router that we are using to connect to the Internet doesn’t work with IPv6 DNS requests properly, if at all.<\/p>\n To disable IPv6 DNS lookups in Firefox and Camino, type the following into the browser address bar: To change the value for this preference simply double-click the name “network.dns.disableIPv6”. The value you want is “true”, which means that IPv6 DNS requests are disabled. If this value is already “true”, don’t double-click this preference.<\/p>\n To make the preference change active, close the browser and Quit Firefox completely (Apple Key + Q), then restart Firefox. You may<\/em> have to repeat this Quitting and Restarting to have the change take effect.<\/p>\n After making this change, Firefox (or Camino if that’s what you’re using) will use IPv4 only when performing DNS requests.<\/p>\n <\/a><\/p>\n If you have access to your router’s administration web page, you may be able to set its DNS servers manually, avoiding the buggy DNS servers located at your ISP. Refer the manual that came with your router, or speak with your service provider about how to access the router’s administration page. Often this page can be accessed at http:\/\/192.168.1.1, so simply type that address into your browser’s address bar and press Enter. With any luck you’ll have access to the Administration login page. Many router administration sites don’t have passwords, don’t have usernames, or use very simple standard passwords such as “admin”, leaving it up to the owner to change it to something more secure. Visit the router manufacturer’s web site for more information about accessing the administration features of the router.<\/p>\n Keep in mind that updating the router’s DNS servers will not avoid problems you may be encountering with the router’s poor DNS Proxying\/Forwarding support. If your router can’t handle IPv6 or SRV requests coming from your Mac, these DNS requests will stop here at the router and will not be forwarded onto the new DNS servers you’ve just specified, making this fix completely ineffective. DNS requests that your router cannot understand will likely be ignored or returned without answer results. DNS Proxy\/Forwarding issues are discussed further in the next section.<\/p>\n <\/a><\/p>\n For those who need to continue making DNS requests through their router, rather than directly against DNS servers, due to VPN or tunneling requirements, your fix may lie in upgrading your router’s firmware. Routers are in effect “the” DNS server for the majority of home broadband Internet connections since it acts as the DNS Proxy, taking domain name lookup requests from your computer, passes them to the ISP’s DNS servers for resolution, receives the results, and finally passes the name lookup results back to your Mac, all transparently in the background. This is why your DNS server address is the same as your “Gateway” which is a fancy name for your router, since all traffic passes through this “gate” of sorts. Thus the Gateway address is often 192.168.1.1, which in turn is also the address of the DNS server for the “Automatic” network Location in Leopard.<\/p>\n Be aware that DNS Proxying is a common failure point in the domain name resolution chain. If the router is not compliant with the latest Internet Task Force standards, it may not know what to do with SRV requests (which Leopard now uses) and may simply ignore them, return empty results, or return NXDOMAIN (non-existent) errors. Again, a firmware update may bring your router up to the latest standards for DNS servers.<\/p>\n If the router is a DSL Cable modem\/router, contact your ISP and ask whether there is updated firmware for the model of router you’re using. If you’re more of a do-it-yourself person you can attempt to find the manufacturer of the router\/modem and find the latest firmware from their website, if available. Disclaimer<\/strong>: updating the firmware of your router with the wrong firmware, or not completing the firmware update due to power loss, will render your router useless<\/strong>. Do not attempt to update the firmware if you are not confident of what you’re doing.<\/p>\n <\/a> Update 080614<\/strong>: Airport Wireless Connection Drops – This is a common problem for Leopard users after upgrading to 10.5.2. This isn’t exactly a slow Internet problem, but rather, a “no Internet” problem. See this related post on wireless problems on Apple AirPort connections<\/a>.<\/p>\n This is not the end, but rather, the beginning of an article that I hope will continue to grow in scope to cover more problems and offer more solutions to slow Internet problems in Leopard. Please leave a comment if you’re experiencing a problem not discussed here and we’ll get working on diagnosing the issue and searching for a cure.<\/p>\n If you’re having troubles implementing a fix listed above, leave a comment and I’ll try to expand on the topic or reword it so that it is understandable to you and to everyone else I’ve confused.<\/p>\nDomain Name Lookup Chain<\/h3>\n
\n
<\/p>\nCaches<\/h3>\n
IPv6<\/h3>\n
SRV (Service Record) Requests<\/h3>\n
Timeouts<\/h3>\n
Solutions<\/h2>\n
\n
Direct DNS \/ Better DNS<\/h3>\n
Add DNS servers to Current Network Configuration<\/h4>\n
<\/a><\/p>\n
\n<\/a><\/p>\nCreating a New Network Location<\/h4>\n
\nClick TCP\/IP<\/strong> tab (top left).
\nWrite down on a piece of paper (or in TextEdit) the IPv4 Address<\/strong>, Subnet Mask<\/strong> (255.255.255.0), Router<\/strong>, and Configure IPv6<\/strong> setting. Click Cancel<\/strong>.<\/p>\n<\/p>\n
\nHighlight “Automatic” if not already
\nClick the Gear icon<\/strong> on the bottom center, choose Duplicate Location<\/strong><\/p>\n<\/strong>
\nChoose a name, I used “Home”.
\nChange the Location<\/strong> drop down box by clicking on “Automatic” and then switch it to “Home” (or the name you chose in the last step)
\nYou’ll see the following:<\/p>\n
\nSelect Airport<\/strong> on the left (or Ethernet<\/strong> if you’re not using a wireless connection).
\nClick Advanced<\/strong> at the bottom right.
\nClick on the TCP\/IP<\/strong> tab-button.
\nChange the Configure IPv4<\/strong> drop down box to “Manually”.
\nHere’s where you use the values you saved in Step 2. Fill out IPv4 address<\/strong>, subnet mask<\/strong>, router<\/strong>, configure IPv6<\/strong> settings. Do not<\/em> click OK<\/strong>, instead click on DNS<\/strong> near the top.
\nClick the +<\/strong> button, bottom left hand corner. This creates a blue outline under DNS Servers on the left half of this window.<\/p>\n<\/p>\n<\/p>\n<\/p>\n
\n<\/a>
\nLeave the Network window open as is and open up a Terminal window<\/a>. We’re going to be using the tcpdump program to listen to DNS traffic<\/a> between your computer and your DNS server.<\/p>\nsudo tcpdump -i en1 -s 128 port 53<\/code><\/p>\ntcpdump: verbose output suppressed, use -v or -vv for full protocol decode
\nlistening on en1, link-type EN10MB (Ethernet), capture size 96 bytes<\/code><\/p>\ncurl http:\/\/www.csu.edu<\/code><\/p>\n
\n00:31:37.029352 IP WANADOO-D310.domain > 192.168.1.132.56645: 19279* 0\/0\/0 (40)
\n00:31:37.029849 IP 192.168.1.132.56646 > WANADOO-D310.domain: 49549+ SRV? _http._tcp.www.csu.edu. (40)
\n00:31:37.032657 IP WANADOO-D310.domain > 192.168.1.132.56646: 49549* 0\/0\/0 (40)
\n00:31:37.034345 IP 192.168.1.132.56647 > WANADOO-D310.domain: 46004+ A? www.csu.edu. (29)
\n00:31:37.279043 IP WANADOO-D310.domain > 192.168.1.132.56647: 46004 1\/0\/0 A www.csu.edu (45)<\/p>\ncurl http:\/\/www.unc.edu<\/code><\/p>\n
\n00:32:33.767237 IP resolver1.opendns.com.domain > 192.168.1.132.56663: 39356 NXDomain 0\/0\/0 (40)
\n00:32:33.767856 IP 192.168.1.132.56664 > resolver1.opendns.com.domain: 62833+ SRV? _http._tcp.www.unc.edu. (40)
\n00:32:33.809161 IP resolver1.opendns.com.domain > 192.168.1.132.56664: 62833 NXDomain 0\/0\/0 (40)
\n00:32:33.811130 IP 192.168.1.132.56665 > resolver1.opendns.com.domain: 45293+ A? www.unc.edu. (29)
\n00:32:33.853070 IP resolver1.opendns.com.domain > 192.168.1.132.56665: 45293 1\/0\/0 A www.unc.edu (45)<\/p>\ncurl http:\/\/s3.amazonaws.com<\/code><\/p>\n
\n09:36:56.671881 IP resolver1.opendns.com.domain > 192.168.1.132.61010: 34536 2\/0\/0 CNAME s3-directional-w.amazonaws.com., (97)
\n09:36:56.673894 IP 192.168.1.132.61011 > resolver1.opendns.com.domain: 18143+ A? s3.amazonaws.com. (34)
\n09:36:56.715913 IP resolver1.opendns.com.domain > 192.168.1.132.61011: 18143 2\/0\/0 CNAME s3-1.amazonaws.com., A s3.amazonaws.com (69)
\n09:36:57.263186 IP 192.168.1.132.61012 > resolver1.opendns.com.domain: 32069+ PTR? 171.206.21.72.in-addr.arpa. (44)
\n09:36:57.306060 IP resolver1.opendns.com.domain > 192.168.1.132.61012: 32069 1\/0\/0 PTR s3.amazonaws.com. (74)<\/p>\n<\/a><\/p>\n\n
\n<\/a><\/p>\nDisable IPv6 DNS Lookups<\/h3>\n
\nabout:config<\/code>
\nIf you see a large “Be Careful” warning, simply click on “I understand and I wish to continue”. Next, you will see a long list of Preference Name, Status, Type and Value columns. Above all that is a bar in which you can filter which preferences to view. In the Filter bar type: ipv6
\nYou should see something like the following:<\/p>\n<\/p>\nUpdate DNS Servers on Router<\/h3>\n
Update Router Firmware<\/h3>\n
New Information<\/h2>\n
\n Update 080606<\/strong>: As per a discussion on Macosxhints forums<\/a>, Apple may have changed the order in which DNS servers are used<\/span>. In the screenshot, the listed DNS servers are used in the order they are seen, under Leopard 10.5.2. This is true for a manually configured Network Location. In 10.5.3, users are seeing the opposite order, i.e<\/span>. In a DCHP configured Network Location (automatically done by your DSL router and ISP), the DNS servers listed are used in reverse order. (Bottom server is used first, then moves up the list as needed). Thus adding a new Network Location to use a given DNS server<\/a> would be unnecessary.<\/p>\n<\/a><\/p>\nThe Beginning<\/h2>\n
![\"\"](\"https:\/\/installingcats.com\/wp-content\/uploads\/2008\/06\/feed-icon32x32-1.png\" "\\"RSS")
<\/a> Keep in the Loop<\/p>\n