gDNS: Taking a chance on improving internet performance
Google’s public domain name server
As we have discussed before, the Internet is basically held together by a series of devices known as Domain Name Servers, more commonly referred to by the acronym DNS. While the actual behavior of these devices can be quite complex and varies with the software and hardware used, they can basically be thought of as a phone directory of the Internet. By that, I mean that it converts the human readable server name, such as ScientificComputing.com into the numeric form that the Internet uses to route traffic, in this case 65.126.154.64.
In operation, these are configured into a distributed tiered structure to try and prevent any one server from being overloaded. There are 13 top-level DNS root name servers supported by InterNIC. These in turn point to other DNS servers responsible for administering the top-level domains (e.g. COM, NET, GOV, etc.). When an address resolution request is issued, it will sometimes reach this upper level look-up server, but most frequently it will be intercepted by another DNS server further down the network which will respond to the request with a cached value of the address. The responding server may be one maintained by an Internet Service Providers (ISP), a company, or even a limited subset maintained in your local wireless router or the DNS cache in your computer.
It is frequently stated that updates to DNS addresses made at one point in the system will eventually propagate through to the rest of the network depending on a number of factors, such as the Time to Live (TTL) set on each DNS. Time to Live determines how long an address will be maintained in a server’s cache. Once the TTL has elapsed; that address is discarded. The reality is that propagation really isn’t the most correct term, as it implies that the values are spreading out to the other servers from the top-level domain servers. In reality, on any specific DNS server the reference for that domain name/address simply disappears until another request is received to resolve it, at which time it will forward a new request up the tree and the new value will be populated until its TTL expires. Because of the number of servers in this chain, any updates made will usually not be immediately visible to the average user. In addition, this network is subject to a variety of cache ‘poisoning’ attacks, that is someone manages to compromise a DNS and substitute a phony IP address for the one actually assigned to a domain name, redirecting all of its network traffic to someone else. Even when cache poisoning has not occurred, many ISPs will take the opportunity to redirect traffic from failed DNS lookups to Web pages of their own, sometimes search pages, sometimes some type of promotional page, but normally not the type of page you are looking for.
On December 3, 2009 at 08:35 (PST), in The Official Google Blog, Google announced an alternative to some of these issues discussed in the previous paragraph. Specifically, they announced the introduction of the Google Public DNS (gDNS). gDNS appears to be both an exercise in enlightened self-interest and an experiment in improving Internet performance. According to the documents on the Google site the goal of this project is to “improve the browsing experience for Internet users globally”. There are several factors which play into this. One aspect is speeding up address lookup; another is making this lookup more secure.
The speed of an address lookup might not seem that critical at first, but it can be highly variable. For simple look-ups this might not be a big deal for most users, however, as the Web pages you encounter become more complex, the total look-up delay for all of the embedded components can rapidly become significant. This is particularly true in instances where look-ups must be performed sequentially, rather than in parallel. While many components may load within a few seconds, it’s not uncommon to have to wait 10 seconds, 20 seconds, or even more for all components to load. Admittedly, this is sometimes due to server response delays, rather than DNS server look-up times, but it’s a definite factor. Google describes a number of approaches that they are using to minimize this look-up time, including pre-fetching, load-balancing, and appropriate provisioning of their DNS servers. They also include a discussion of the limitations these various approaches have.
Perhaps of more interest to serious users are the ways they are experimenting with ways of preventing both cache poisoning and denial-of-service (DoS) attacks. Approaches implemented range from basic validity-checking to rate-limiting requests (preventing DoS and amplification attacks) to removing duplicate queue entries (reducing the risk of “birthday attacks”) and adding entropy to resolution requests (making more sophisticated spoofing attacks less likely to succeed).
Google provides a detailed description of how to use gDNS on their Code site, or you can download a PDF of the instructions. These instructions cover MS Windows, Mac OS X, Linux, routers, and mobile devices. However, with the variety of routers and mobile devices available, instructions for these devices are understandably rather generic. Basically there are two IP addresses you can use to access the Google Public DNS; they are the easily remembered 8.8.8.8 and 8.8.4.4. If you are running a home network through a wireless router, it would make sense to configure this look-up in the router, automatically providing it to all connected devices. If you want to try testing it in a single device first to avoid impacting the rest of your network, just go into the network configuration on your machine, as described in the instructions, and change the values relative to the DNS addresses. Note: Do carefully record all of the initial values and any other changes you make to simplify restoring your system to the original configuration. For experimentation purposes, it would make sense to enter only the gDNS addresses. However, as most systems will allow you to enter addresses for multiple DNS servers, you could later add some of these other addresses back in for contingency protection. Just remember that these addresses are normally entered in order of priority, that is, the system uses the top/first address first, then steps down through the rest until it receives a response. Though doing this might leave you vulnerable to some of the network attacks that Google is trying to block.
Is there a downside to using gDNS? It seems to depend on whom you ask. There are those who are whole heartedly encouraging people to try it. On the other hand, there are those who are very …leery. Many of these don’t seem to have a particular concern with what they are trying to do technologically; after all, OpenDNS offers a somewhat similar service. Their concern seems to be that Google has already consolidated so much information about you and they are uncomfortable with providing it with any more. As this is a more subjective issue, you’ll have to decide how comfortable you are with using it. Personally, while it is conceivable that this information could be misused, I think it is worth checking out. I find myself much more concerned with the illegal (at the time) monitors that George Bush had placed on the Internet than I do with what Google might do with this information.
Web Resources
Domain Name System (Wikipedia) en.wikipedia.org/wiki/Domain_Name_System
Google Public DNS code.google.com/speed/public-dns/
Using Google Public DNS (PDF) code.google.com/speed/public-dns/images/using.pdf
OpenDNS www.opendns.com
John Joyce is the LIMS manager for Virginia’s State Division of Consolidated Laboratory Services. He may be contacted at [email protected].
