NNSquad - Network Neutrality Squad
[ NNSquad ] Iljitsch van Beijnum on ars technica about google dns
----- Forwarded message from David Farber <dave@farber.net> ----- Date: Thu, 3 Dec 2009 21:02:37 -0500 From: David Farber <dave@farber.net> Subject: [IP] Iljitsch van Beijnum on ars technica about google dns Reply-To: dave@farber.net To: ip <ip@v2.listbox.com> Begin forwarded message: From: suresh@hserus.net (Suresh Ramasubramanian) Date: December 3, 2009 7:36:16 PM EST To: dave@farber.net Subject: Iljitsch van Beijnum on ars technica about google dns http://arstechnica.com/security/news/2009/12/google-public-dns-service-not-ideal-for-everyone.ars Google Public DNS service not ideal for everyone In its effort to organize the world's information, Google is offering to handle your DNS lookups, but the new service may only be really attractive for those with bad ISP-provided DNS service. By Iljitsch van Beijnum | Last updated December 3, 2009 5:20 PM Apparently on a quest to to provide every Internet-related service itself, Google has now added the Google Public DNS service. The search giant claims performance benefits for many users (depending on their geographic/network location) and security benefits for everyone who adopts the new service. So should we all dive into our network settings and point our computers away from our ISP's DNS servers and towards Google's? Not necessarily. For almost two decades, the Internet didn't have a Domain Name System, and the translation from human-friendly names into the IP addresses that computers and routers use to make packets flow to the right destination happened through a local file on each computer. In the late 1980s, a distributed system was created for this purpose: the DNS. 8.8.8.8 The distribution is possible through a hierarchical naming scheme, where different organizations manage different parts of the namespace. So the Internet Corporation for Assigned Names and Numbers (ICANN) manages the "root" or starting point of the system. A set of root servers know which addresses the servers for the next level in the hierarchy live on: the Top Level Domains (TLDs), such as .com, .net, and .jp. The TLD servers in turn know where to find the servers that contain the information for the names registered under the TLD in question. So the .com servers point to the google.com and arstechnica.com servers. Those servers are the ones that know which address maps to www.google.com, mail.google.com, and the like. It would be rather time-consuming to follow the entire delegation chain from the root servers through the TLD DNS servers and the DNS servers for the domain in question every time a browser wants to load a page, an image, or send an e-mail. To avoid this, ISPs, many businesses, schools, and so on have caching nameservers. Those follow the delegation chain to find a name-to-address mapping the first time, but then cache this information for some time. Google Public DNS is a large set of those caching DNS servers placed around the world. Interestingly, even though the number of caching DNS servers is apparently quite high, Google only uses two addresses for them: 8.8.8.8 and 8.8.4.4. (It looks like Google turned to Level3 to get some easy to remember addresses for this purpose, rather than use addresses out of their own, less-memorable address ranges.) The routing system simply delivers packets addressed to either address to the closest Google Public DNS location. So users in different places around the world will be talking to different instances of these addresses, making for faster round-trip times, which is important for good DNS performance. This mechanism is called anycast. Google uses clusters of servers at each of the anycast locations that collectively cache information, allowing requests to be rerouted from one server in the cluster to another. This provides better caching and thus better performance than simply distributing incoming DNS queries over a set of independently operating servers. Additionally, they've developed a system that can refresh information that is about to expire (all DNS records contain a "time to live" value), rather than removing stale information and then having to do a lengthy lookup when it's requested again by a user. The DNS protocol has some flaws that make it possible for attackers to inject false information in a DNS server cache, allowing the attacker to make users load pages of the attacker's choice for a given domain name. This can result in anything from unexpected porn banners on normally clean sites to phishing of bank logins. The most recent DNS software is mostly resistant to this, but it's an ongoing battle until DNSSEC is widely deployed. Open recursive (caching) DNS servers are especially vulnerable to cache poisoning attacks, but Google has implemented several mechanisms to counter these, including one system that wasn't adopted in the IETF because there are some problems with it (randomizing the case in DNS names). Apparently Google is prepared to see how big these problems are in practice for the benefit of the IETF. Unfortunately, despite the anycasting, advanced caching, and extensive security features, Google Public DNS is not the ideal DNS service. For one thing, it's not called "experimental" for nothing. From my home, I can't reach 8.8.8.8. Packets end up ping-ponging between the addresses 9.9.9.18 and 9.9.9.17. Apparently some routing engineer at Google is a bit dyslexic. (It does work from another location that I have access to.) Also, despite Google's claim that it provides NXDOMAIN responses whenever a domain name doesn't exist, its servers actually respond with REFUSED when looking up a name that goes with a private address (such as in the 192.168.x.x or 10.x.x.x ranges). My Mac doesn't seem to like this, so it keeps repeating those requests over and over. OpenDNS, which also runs a network of public, open DNS servers, doesn't have this problem. OpenDNS also allows users to set up malware blocking and NXDOMAIN redirection through a dashboard. You also generally don't want to hard-configure your laptop or smartphone to use a fixed set of DNS servers, but rather use the ones provided locally at each place where you connect to the network. This avoids the situation where the hardcoded DNS servers have bad performance, are blocked, or are improperly anycasted. (Note that under Mac OS X, you can have different "locations" with different network settings, and you can set one up with automatic DNS configuration and one with Google Public DNS or OpenDNS.) However, if your ISP's DNS servers don't perform well, it can be useful to set up alternative DNS servers in your local router or DHCP server, and computers and other devices will use it automatically without having to be configured. Google's setup instructions walk you through the process. Last but not least, there's the privacy aspect. Two people that I talked to immediately brought this up: "Google already sees enough of my 'Net activity, thankyouverymuch." If that's a concern of yours, Google has an extensive privacy page to set your mind at ease. ------------------------------------------- Archives: https://www.listbox.com/member/archive/247/=now RSS Feed: https://www.listbox.com/member/archive/rss/247/ Powered by Listbox: http://www.listbox.com ----- End forwarded message -----