Who Is The Top Public DNS Provider? Google Is

When Google Public DNS launched in late 2009, it was only ever supposed to be an experiment. But yesterday, Google announced that it’s now the most popular public DNS in the world, handling over 70 billion requests per day.

What is DNS? LEARN HERE

To use Google engineer Jeremy K. Chen’s own simile, as expressed in the official blog entry, DNS – short for Domain Name System – is like the Internet’s phone book. When you put a URL into the browser, the DNS service looks it up and matches it to an IP address. Google Public DNS aims to be the most complete, fastest, and most secure listing of its kind out there for users all over the world.

In fact, Chen writes that 70% of Google Public DNS traffic comes from outside the US, thanks to existing nodes in North and South America, bolstered support in Europe, and all-new nodes for regions like Japan, Australia, India and Nigeria.

Of course, Google critics are wondering what good could come of the search giant having access to even more user data – in this case, a log of every single website that Google Public DNS visitors go to, all day, every day.

Now, Google says that it “never blocks, filters, or redirects users, unlike some open resolvers and ISPs,” but, well, here’s InformationWeek’s rock-solid summary of its privacy policy:

Google also maintains a separate privacy policy for Google Public DNS. The company says it maintains two sets of server logs related to the service: temporary and permanent. The temporary logs contain user IP addresses and those are deleted in 24 to 48 hours (barring a court order to the contrary). The permanent logs, which contain city-level location data but nothing personally identifiable, are retained for at least two weeks. A small random sample taken from the permanent logs is kept indefinitely.

It’s still unclear if Google Public DNS’ privacy policy will be streamlined into Google’s streamlined, unified document that’s going live on March 1st, but regardless, it seems extremely likely that Google will stick to its guns as far as not sharing that data with anyone else. And on a slight tangent, I highly doubt that we’ll see Google Public DNS added to that unified privacy policy, given the comparatively unique legal precautions it’s already caused Google to take.

In the final analysis, the measure of how okay you should be with Google Public DNS and its privacy implications depends on whether or not you feel like Google is, in fact, evil. In the meanwhile, Google’s holding the line that it protects user privacy at all costs.

Thanks to

www.howstuffworks.com

www.zdnet.co.uk

en.wikipedia.org

Google wants to see your addresses in DNS queries

Late Wednesday evening, Google employees posted an “Internet-Draft” outlining proposed changes to the DNS protocol that allow authoritative DNS servers to see the addresses of clients. This way, geographically distributed content delivery networks can tailor their answers to a specific client’s network location. So a client from California would talk to a server in California, while a client in the Netherlands would talk to a server in the Netherlands.

Currently, authoritative DNS servers don’t see the client address, only the address of the resolving server that is typically operated by the client’s ISP. So in the current situation, if our Californian and Dutch clients both use a DNS resolver in New York, a location-optimizing authoritative DNS server would give them both the addresses of servers in or around New York. By including the client’s address in the request, the authoritative server can send a better response and improve the subsequent interactions between the client and server because the request/response round-trip times across the network are shorter.

Google does have a plan to avoid the most egregious privacy concerns. “Recursive Resolvers are strongly encouraged to conceal part of the IP address of the user by truncating IPv4 addresses to 24 bits.” Coincidentally, 24 bits maps directly to the minimum address block that can be carried in the Internet’s routing system. Carrying any more than that won’t help solve the network distance problem using the routing tables. For IPv6, there is no corresponding number that everyone agrees to, but the authors of the draft suggest truncating IPv6 addresses as well. Of course, the owner of the authoritative DNS server still gets to see the client’s full IP address when the HTTP request for the actual content is sent.

Internet-Drafts are working documents within the Internet Engineering Task Force. Anyone in possession of a keyboard and time on their hands can write one. Drafts live on the IETF servers for six months and are then deleted, so authors must post updates twice a year. If there is interest and no technical objections, a draft may progress to become an RFC (Request For Comments). The bar is relatively low for “experimental” and “informational” RFCs, but much higher for those that are intended to become Internet standards. Very few drafts get that far.

In this particular case, it’s not clear whether purists will object to embracing “two-faced DNS” so explicitly. Although many organizations have DNS servers that serve up different answers to internal users than to external users, this practice isn’t held in high esteem by those in the IETF who care about the Internet’s architecture.

Interestingly, the Google and Neustar employees who wrote the document chose a model where the authoritative server sees the client addresses, rather having the authoritative server publish the full list of server addresses so that the resolving server can figure out which is closest. And if Web protocols and practices weren’t so sensitive to round-trip times, this effort would be largely irrelevant. (Altough not having to carry packets from continent to continent would still save bandwidth costs.)

It’s too early to make guesses about the success of this effort at the IETF, but Paul Vixie, well known as the original author of the BIND DNS software and no less for his strong opinions, set the tone in a message to the IETF DNSEXT mailing list. “if we’re going to add client identity to the query, can we do so in a more general way? i’d like to know lat-long, country, isp, language, and adult/child.”

Further reading

• A proposal to extend the DNS protocol (googlecode.blogspot.com)
• Client IP information in DNS requests (ietf.org)