Friday, September 19th, 2008

DNS Presolving with Google Chrome

Category: Browsers

<p>One of the nice performance features in Google Chrome is the DNS pre-resolving technique that asynchronously does DNS lookups to seed the cache, at appropriate times. For example, based on links in a page, search suggestions, your favourite end points at startup.

The article goes into the details, and this is a long running discussion.

This Simple Failover article (PDF) talks about how DNS servers cache lookups at the various levels. The Operating System itself does some caching, proxies can do more, and applications such as browsers also cache even more:

It has been suggested that some ISPs configure their DNS servers to cache all DNS records for a minimum period (such as 60 minutes) in an attempt to reduce DNS network traffic.

This may have been the case in the past, but this does not appear to be very common today, probably because more and more web sites and Internet services depend on quick updates to DNS records.

DNS network packets are extremely compact and take up very little bandwidth compared to everything else we send across the Internet, so this is not a good place to look for bandwidth savings anyway.

“www.cnn.com” is one example of a well-known larger web site, which depends on low TTL values to enable quick changes to their web site (they currently use DNS TTL values of 5 minutes). Also, many small web-sites today depend on low TTL values because they run on ADSL or cable connections with dynamic IP addresses, and therefore require frequent DNS updates (when their IP address changes)

Windows

Microsoft Windows 2000 and later includes a DNS cache – the “DNS Client” service. You can display the contents of this DNS cache by typing “IPCONFIG /displaydns” at a command prompt, or clear it by typing “IPCONFIG /flushdns”. This DNS cache honors TTLs as described earlier in this document, and so this does not cause any caching beyond the original TTL.

Browsers

Internet Explorer 4, 5, and 7 by default caches all DNS record for a period of 30 minutes no matter what the TTL value is. This means that there is up to a 30-minute delay before they will discover DNS
changes.

This of course only affects visitors who have visited the web site immediately before a DNS update. New visitors or return visitors who closed their browser or waited more than 30 minutes since their last visit are not affected.

It is possible to adjust the length of time I.E. caches DNS records by updating a registry setting on the client machine. But this is of course only practical in an intranet scenario.

Internet Explorer v. 6 does not cache DNS A-record responses. It only caches DNS CNAME-record responses. Simple Failover only uses DNS A-records. This means that this browser version practically discover DNS changes made by Simple Failover instantly.

All versions of the Firefox and Mozilla/Netscape browsers since mid 2004 by default cache all DNS records for 1 minute no matter what the TTL value is. This means that they will discover DNS changes within one minute. Earlier versions of Mozilla/Netscape browsers cache all DNS records for 15 minutes no matter what the TTL value is.

Posted by Dion Almaer at 7:21 am
2 Comments

+++--
3.5 rating from 11 votes

2 Comments »

Comments feed TrackBack URI

This is great to see Chrome so focused on performance. I was hoping to see other info about DNS caching in Chrome. Does Chrome cache DNS resolutions longer than the TTL? Similar to IE’s 30 minute cache, or Firefox’s dnsCacheExpiration setting? How many resolutions does it cache (a la FF’s dnsCacheEntries)? Does re-use of the domain within a certain time period affect the cache, similar to what FF’s network.http.keep-alive.timeout value does?

Although the average in this sample is 271ms, that seems high. The median is 87ms, which is more typical in my experience.

Comment by souders — September 19, 2008

Dion, Simple DNS failover is bad technique. Please see here: http://www.netwidget.net/books/apress/dns/info/failover.html

Comment by berend — September 19, 2008

Leave a comment

You must be logged in to post a comment.