InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

8.8.8.8, A DNS Number for Faster Browsing

Posted by Abel Avram on Dec 04, 2009

Sections
Architecture & Design,
Development,
Operations & Infrastructure
Topics
Architecture ,
Performance & Scalability ,
Internet
Tags
Chrome ,
Google ,
Browsers

Google is offering two DNS servers for public use, namely 8.8.8.8 and 8.8.4.4, in an attempt to further speed up browsing.

A DNS server is used to translate a web name, a literal identifier, into a numerical identifier used by the underlying network protocols. An average user needs hundreds of such translations to be done in a typical browsing day, according to Google. Many web pages are complex these days incorporating content from multiple domains, each domain being in need of a domain name resolution. The name resolution process - connecting to a DNS server, finding the numerical ID and returning the response – increases the browsing latency resulting sometimes in completely loading a page in seconds, even 11 seconds as this example shows.

Google finds this DNS latency unacceptable and has opened up two globally distributed DNS servers to public use hoping to improve browsing speed. They are trying to address three main issues:

  • Speed: Resolver-side cache misses are one of the primary contributors to sluggish DNS responses. Clever caching techniques can help increase the speed of these responses. Google Public DNS implements pre-fetching: before the TTL on a record expires, we refresh the record continuously, asynchronously and independently of user requests for a large number of popular domains. This allows Google Public DNS to serve many DNS requests in the round trip time it takes a packet to travel to our servers and back.
  • Security: DNS is vulnerable to spoofing attacks that can poison the cache of a name server and can route all its users to a malicious website. Until new protocols like DNSSEC get widely adopted, resolvers need to take additional measures to keep their caches secure. Google Public DNS makes it more difficult for attackers to spoof valid responses by randomizing the case of query names and including additional data in its DNS messages.
  • Validity: Google Public DNS complies with the DNS standards and gives the user the exact response his or her computer expects without performing any blocking, filtering, or redirection that may hamper a user's browsing experience.

Google says their DNS servers are better because they are

  • Provisioning servers adequately to handle the load from client traffic, including malicious traffic.
  • Preventing DoS and amplification attacks. Although this is mostly a security issue, and affects closed resolvers less than open ones, preventing DoS attacks also has a benefit for performance by eliminating the extra traffic burden placed on DNS servers. For information on the approaches we are using to minimize the chance of attacks, see the page on security benefits.
  • Load-balancing for shared caching, to improve the aggregated cache hit rate across the serving cluster.
  • Pre-fetching name resolutions, to overcome the limits of conventional, passive caching and aim to serve the majority of requests out of cache. We are experimenting with a DNS pre-fetching technique which we think offers a significant opportunity for DNS speed-up. Below, we give an overview of the benefits, limitations, and challenges in implementing pre-fetching, and how we hope to meet those challenges with additional techniques such as traffic prioritization and cache partitioning.
  • Providing global coverage for proximity to all users.

On a similar but different note, Google has unveiled how Chrome deals with name resolution to increase browsing speed even more. Jim Roskind, a Chrome Software Engineer, gave some tips:

  • When a page is loaded, Chrome analyzes all links and gets the IPs in advance by asking the operating system to resolve the names. When the operating system has done that, the response is thrown away because the response is now in OS’ cache. So, when an user clicks on a link, the browser will ask for the corresponding IP and that will be returned from the cache without having to resolve it again.
  • Another solution is to monitor the mouse. When an user wants to click on a link, it takes him some 200ms to hover over the link and actually click it. In this time, Chrome tries to get the link’s IP.
  • Another solution implemented in Chrome is to keep a long lasting cache of previous resolved names, so when the user revisits a particular page, Chrome already has a list of IPs prepared to be used.
  • Chrome asks the operating system to solve the home’s page IP before the browser is loaded by the OS. When the browser’s loading is finished, the home page can be quickly loaded because its IP is already saved in OS’ cache. This shaves down 250-500 ms from the start-up time.

For the future: some 1-2% of the TCP/IP packets are lost in transmission and the TCP/IP stack has a 3 seconds time-out on Windows after which it starts resending it. When the first packet is lost, the user waits expecting for the page to be load, but the target website hasn’t actually been contacted. 3 seconds is way too much for Google, so they will implement a mechanism in Chrome to either resend a TCP/IP packet which was not answered or to open up a new connection when the server does not answer in a reasonable time.

Isn't this primarily aimed at speeding up Google apps? by Bartosz Klimek Posted
Gathering more information by Fabio Mancinelli Posted
Re: Gathering more information by Bobby Hargett Posted
Re: Gathering more information by Rob Record Posted
Re: Gathering more information by Chris Peterson Posted
OpenDNS by Al Tenhundfeld Posted
  1. Back to top

    Isn't this primarily aimed at speeding up Google apps?

    by Bartosz Klimek

    With this solution, the easiest way to improving users' experience with Google apps would be to handle requests for all Google's domains before processing any other domains. If worldwide users decide to switch to their DNS service en masse, they'll have a mighty tool to gain advantage over competitors. But, at the end of the day, that's ok - they don't force you to use it.

  2. Back to top

    Gathering more information

    by Fabio Mancinelli

    Looks like Google wants to be able to detect what is directly typed in the navigation bar or the links that are clicked past the initial search results. This could surely improve their ranking algorithms but also poses a HUGE privacy problem.

  3. Back to top

    OpenDNS

    by Al Tenhundfeld

    There's a good response from the OpenDNS folks:
    blog.opendns.com/2009/12/03/opendns-google-dns/


    To think that Google’s DNS service is for the benefit of the Internet would be naive. They know there is value in controlling more of your Internet experience...

    [but also]

    ...it means that Google is bringing awareness to a wide audience that there is a choice when it comes to DNS and that users don’t have to settle for what their ISP provides. And we believe that having choice is a good thing...

  4. Back to top

    Re: Gathering more information

    by Bobby Hargett

    As opposed to the isp peeking in your info. Look for microsoft to do the same things.

  5. Back to top

    Re: Gathering more information

    by Rob Record

    Very good point, Bobby. Many companies already do have access to this info.

  6. Back to top

    Re: Gathering more information

    by Chris Peterson

    Look for microsoft to do the same things.

    And Microsoft has the power to silently "reset" Windows users' DNS settings to point to Microsoft-hosted DNS servers in the next Windows Update.

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.