Google recently launched the Google Public DNS, aimed at increasing the speed of Internet name resolution.

DNS (Domain Name System) resolution is responsible for converting a website’s name into an IP address (www.google.com -> 64.233.163.163). This service is used whenever your computer needs an Internet address. Every time a new name is converted into an IP address, the result of this conversion is stored in a quick access table on your computer to speed up future accesses, or simply put, a cache.

For example, resolving www.google.com. The first time you access the domain, the DNS service on your computer will check the local cache and return the IP address, but since it’s the first time you’ve tried accessing Google today, it won’t find this domain name in its table cache. When this happens, a request will be made to your DNS server.

A DNS server also caches recently searched domains, but it will resort to the Internet’s Root Servers if it also doesn’t have the domain registered. And that’s how DNS and the entire Internet work today. The big question is to understand the problem that Google Public DNS Solves.

The first problem is that the time of access between computers on the Internet can be measured in milliseconds (an eternity in terms of data transmission :-). The response time (Round Trip Time - RTT) is simply the time it takes for one computer to send a packet and receive the response from another computer. In other words, the time it takes for Computer A to receive a response from Computer B. A practical example is the time displayed by the ping command. The ping command sends a packet using the ICMP protocol and waits for the response from the other system, printing the time between the request and the reception of the response.

The farther apart the computers are, the greater the access time. This effect is caused by transmission media (fiber, satellite, cables, etc.) and Internet routing.

When a DNS server doesn’t find a domain name/host in its cache table, it needs to perform a new search. In the case of www.google.com, the first search will be made to the server responsible for .com domains about the address of Google’s servers. Then your server will make another search, this time asking Google’s server for the address of www. The situation worsens when you have names with multiple levels, but the server caches these requests to avoid all that work on each access. The response time of each of these searches is equal to the response time between the servers plus the processing time for the response itself.

The problem that Google Public DNS solves is centralizing this information in a Google-like way. This means being able to use Google’s global network to store and update these conversion tables. Another point is responding requests very quickly, something Google is champion at doing. Many Internet access providers have mega-caches of domains, but updating this cache is another problem. Google aims to solve the problem of large caches and increase the level of security of the name resolution service (DNS).

For example: imagine that the response time between your DNS server is equal to T. To respond to the IP address of www.google.com, we would have something like 3T or 4T. Consider that in Brazil, with slow networks, this T is quite large (>100ms). Also think that a simple web page can have dozens of names to resolve. This causes a huge delay to the total page load time. Using Google’s service, the response time approaches T (since Google’s cache tables tend to be larger and faster than your poor or rich server).

A complete description of the problem and solution can be found here.

Now, how to use this. The temptation may be to simply replace your DNS server IP with 8.8.8.8 and 8.8.4.4. This is a very interesting solution and is described on the service pages, but the best thing is to configure your local DNS server to use this service. This minimizes access time for all machines in the network and since access time to the local server is much smaller than accessing Google’s server, domain resolution time will be low.

For those who use BIND on Linux without having it set up as a local or main domain server or primary, simply as DNS cache, just add the following lines in /etc/bind/named.conf (the address may change according to your Linux distribution).

Add the lines with Google’s servers (in bold) right after directory, inside options:

options {

directory “/var/bind”;

forwarders { 8.8.8.8; 8.8.4.4; };

forward only;

After this, reload the BIND configuration (/etc/init.d/named reload) and all done. Now you have your local cache and Google’s public service. The difference is noticeable.

You can also get a good performance by configuring Google’s servers on your wireless access router, but this will depend on the response time of the same. Worth trying!