If Google’s claims are true, their Public DNS technology will vastly improve our Web surfing, and who doesn’t want that? DNS is a simple concept, yet it is incredibly complex to implement. With that in mind, let’s take a quick look at what DNS is. Then, we’ll explore what Google has come up with.

What is DNS

Domain Name System (DNS) is all about making it easier for us. We like names, computers like numbers. DNS translates names (domains) into numbers (IP addresses). If your computer cannot access DNS and get the proper IP address, you will see the “Server not found” error being displayed by the Web browser.

The DNS system consists of protocols RFC 1034, RFC 1035, and the following components:

Resource records are the data sent back to the application making the DNS query. The address record is the one we are concerned about. It matches the domain name to an IP address. The slide below depicts a zone file of example.com, with the address record showing the IP address for example.com being 192.168.254.3 (courtesy of Zytrax.com).


Name servers: Name servers are repositories for zone files like the slide above. Resolving servers are name servers that store only address records. How it all works is not important, right now. We just have to remember that a DNS resolving server returns the IP address required by the Web browser. The slide below shows how the resolution process takes place (courtesy of O’Reilly.com).

For in-depth information about the inner workings of DNS, please refer to the O’Reilly book DNS and Bind, 3rd Edition by Paul Albitz and Cricket Liu.

Latency is the problem

Because of DNS’s complicated structure, latency is invariably introduced by the following:

  • Latency between the user app and resolving server: The round trip between the user’s computer and the resolving server takes time and is influenced by physical distance, network crowding, packet loss, and server loading. Any of which can increase the delay.
  • Latency between the resolving server and upstream name servers: Resolving servers hold address records only for a certain length of time. If a query comes in and the resolving server does not have the right address record, it must query other name servers for the information, which takes additional time.
  • Name server overloading: Any time a name server is taxed to its limit, queries get queued or dropped, depending on the severity of the over loading. This again adds additional time.

Google’s improvements

Google looked at all three of the above issues and came up with the following improvements:

  • Provisioning server clusters adequately: Google intends to have more than enough server capacity available for anticipated loading.
  • Load balancing for shared caches: Google is making provisions to handle high volumes by using innovative load-balancing techniques. Google expressed concern about cache fragmentation due to poorly implemented load balancing. They plan on fixing this by using two approaches: global caches and partitioning caches by name. That way, all queries for a particular domain go to the same server.
  • Prefetching name resolutions: I mentioned earlier about resource records having a time-to-live and the latency that occurs while trying to find an expired record. To prevent that, Google intends to automatically renew certain resource records whether users are sending queries for those domain names or not, which eliminates additional latency.
  • Adequate name server distribution: This is one area where Google will not have a problem. Google intends to host Public DNS in all their data centers worldwide.

To try Public DNS

For those who want to use Google Public DNS, change the DNS primary and secondary IP addresses to 8.8.8.8 and 8.8.4.4. Google also has a Web page with configuration instructions for most operating systems and devices (also see Rick Vanover’s recent post on configuring Google Public DNS).

I have timed a few queries, and it does appear to be faster. I found this blog post by Manu, who did significant testing, to have some insightful comments.

My concern

Google applications enhance my Internet experience, yet I am concerned about the amount of personal information Google captures. That dilemma is now more perplexing. Along with everything Google accumulates about me, my using Google’s Public DNS system allows them to track every Web site I visit. (Of course, as fellow TechRepublic blogger Chad Perrin points out in a recent post, before you get too paranoid about Google, you might want to reflect on the amount of sensitive information your current ISP has on you.)

The people at Google must be aware of my concern. I read a ComputerWorld article by Juan Carlos Perez, where he quotes Prem Ramaswami, product manager of Google Public DNS, as saying:

“Google Public DNS will retain the end-user’s IP addresses for no longer than 48 hours before deleting it. It will store for about two weeks more general data about the user’s ISP and city.

Furthermore, Google will not use Google Public DNS traffic data to complement data it collects from users in its other services. We’ll never correlate this with our search logs or anything like that to add to the information we have about you specifically. We do recognize DNS gives us a wider swath of information, and we want to make sure that there aren’t these privacy concerns.

This is about making the Web faster; it’s not about collecting more data.”

For an interesting take on this subject, you might want to read “Still Waiting for an Evil Google? It’s Not Going to Happen,” a blog post by Louis Gray. I definitely would like to know what you think.


Final thoughts

Making the Web faster is indeed in our best interest, and truthfully, it is also in Google’s best interest. Knowing that, it appears that Public DNS has merit. As long as you believe Google’s CEO Eric Schmidt and his now famous line “Trust us.”