8.8.8.8, A DNS Number for Faster Browsing (2024)

Integrating AI into Hybrid Architectures with HPE Ezmeral (Webinar May 2nd)

Write for InfoQ

Feed your curiosity. Help 550k+ global senior developers each month stay ahead.Get in touch

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.

Related Topics:

• Development
• DevOps
• Chrome
• Web Browser
• Web Development
• Google
• Chrome OS
• Internet
• Operating Systems
• Infrastructure
• Architecture

We protect your privacy.