How Does the New Google DNS Perform? (and Why?)

Tarinth writes "Google just announced its new Google DNS platform. Many have viewed this as a move to increase ad revenue, or maybe capture more data. This article explores those questions, as well as the actual benchmarking results for Google DNS — showing that it is faster than many, but not nearly as fast as many others." We also recently discussed security implications of the Google Public DNS.

Comments

Pointless hype

[suso]

Its funny how the Google hype is driving so much talk about something like DNS, a service which probably 95% of non-tech people don't know exists. Most people
wouldn't care about DNS normally, but since its Google it must be something to get excited about. I doubt really that any significant number of people will
switch to using 8.8.8.8, but I worry that if they do, one of the the original goals for DNS will be lost. That its distributed.

Just ask yourself one question, if you don't trust your internet provider enough to do DNS correctly, should you trust them at all?

Re:Pointless hype

[drinkypoo]

Just ask yourself one question, if you don't trust your internet provider enough to do DNS correctly, should you trust them at all?

You trust your ISP? I sure don't. Perhaps I am asking for abuse, but I trust Google far more. On the other hand, I trust my hosting provider to provide sufficient DNS; but if I were hosting my application on a cloud somewhere, I'd want some cloud-based DNS; if I were hosting my application with Google, then Google would be the logical host for my name service. I'd probably want to use them as my registrar as well. :p

Google has the best uptime and the most distributed architecture of any single computer system, unless you consider the internet to be a single entity; it has slightly better reach overall.

I doubt really that any significant number of people will
switch to using 8.8.8.8, but I worry that if they do, one of the the original goals for DNS will be lost. That its distributed.

Google is distributed. Is there any reason using one IP is unworkable?

Re:Pointless hype

[jhoegl]

I got money on the fact that this DNS server will be a part of their Android and Chrome OS services. You know, a default setting.

Re:Pointless hype

[Krneki]

I use OpenDNS because in my country they dared to censor the Internet twice using DNS.
Once it was for bwin.com and another time it was a leaked political document (both for 1 week). No, I don't bet, but I do not tolerate this political bulling.

Google DNS could be useful if they don't implement any censorship, considering how much hate P2P sites gets from corporations we will see if they manage to stay neutral.

Re:Pointless hype

[omnichad]

They have two IP's - 8.8.4.4. So even if one IP fails to route to any anycast destination at all, they still have a backup.

Re:Pointless hype

[Akido37]

Just ask yourself one question, if you don't trust your internet provider enough to do DNS correctly, should you trust them at all?

Personally, I'm sick of DNS lookups resulting in a page of ads.

Re:Pointless hype

[suso]

Then you are a fool. This is exactly what I mean by trusting your ISP. I sympathize with you and your situation (and I understand that it happens), but all your country has to do is implement some system that will change the UDP packets coming from Google DNS to change the answers, thus accomplishing the same censorship. The more people who use Google DNS, the more likely a country or ISP is to do this.

Re:Pointless hype

[Anonymous Coward]

Fair enough -- you don't trust your ISP.

How does using google's DNS help you? You really think your ISP isn't logging your DNS traffic regardless of if you're using their DNS servers or not? A simple tcpdump udp port 53 on a passive tap is enough for them to collect your DNS traffic no matter what you do unless you use TOR or a vpn.

So, now google *and* your ISP have logs of what you've been looking up. How are you better off?

Oh -- and if you really don't trust your ISP, how are you to be sure that they aren't redirecting your port 53 traffic to their DNS servers *anyway*? Comcast -- I'm looking at you... Why is it that 5% of responses that *should* be an NXDOMAIN from a root server instead are an A record to some site that happens to be running a web server?

Re:Pointless hype

[sexconker]

Google has the best uptime and the most distributed architecture of any single computer system, unless you consider the internet to be a single entity; it has slightly better reach overall.

No it fucking doesn't you fucking moron.

Oh this is slashdot. I meant "Citation needed.".

Re:Pointless hype

[camcorder]

You don't need to trust your ISP, they are legally binded to protect your privacy on most of the countries. Since you have a contract that means that's a card in your hand which you can use in case of violation. However with Google, you have nothing. All the contracts you have with google is the legal aggreements to use their services in return of losing your privacy at all.

To summarize, your option to trust google is just useless since it doesn't matter if you trust them or not.

Re:Pointless hype

[Anonymous Coward]

If your ISP is like mine, they break basic DNS functionality. Instead of a correct could not find error, they serve up a page of badvertising. If you opt out of that, they serve up a page that says that it could not find, not returning the real error. If you have your iPhone connected to your home wifi, and you attempt to use the google app on your phone, it breaks the search results page...

ALL of these annoyances are fixed with gDNS.

Re:Pointless hype

[mzs]

Google is using anycast for their DNS servers. There are not just two machines at 8.8.8.8 and 8.8.4.4 as the sole DNS servers. You get a relatively close-by server. This is a tried and true technique for DNS. In fact there is a technical feature about the google approach that is neat. It is likely that google is using many of the same servers it is for search for the DNS servers as well. They are running the caching DNS at each facility, such that if one server at the facility gets a record, then any other DNS server at that facility uses that response. That is one cool way to limit the delays for someone else making a DNS request. I've not seen that mentioned much before, and that is neat. I wish slashdot comments about stories that are trying to be technical would have technical comments on them near the beginning, instead of rehashing of all this privacy stuff, for a third or fourth story.

Another approach that was mentioned a lot before is that after the DNS server provides a response, the server checks to see if time is running-out regarding the TTL. If it is and has not expired yet, it asks again and pretends that the TTL counter has begun again. This again is trying to limit a DNS delay for some poor schmuck.

Another technical detail I have not seen mentioned much is that google DNS servers are returning largely authoritive answers only, often in cases where other DNS servers do not. For example, look-up a private IPv4 such as 192.168.1.1 with google's servers and some others. Others typically return non-authoritive responses, say to RFC1918.private.net. There is a lot of subtly misconfigured software-out there, hopefully this will bring it to the fore front about dealing with non-authoritive answers more carefully.

As to regarding the performance of google DNS, from a few locations for me, seems very fast. Is faster (much) than AT&T, bit slower than comcast, bit slower than work, comparison with OpenDNS is in the noise. What is more important is that they treat all records correctly, so for example kx509 _kca._udp.REALM style SRV records are handled unlike the DNS servers from some ISPs which seem to think that DNS is only for A records.

Another interesting feature is that google DNS is playing tricks with case in DNS queries and replies as yet another stop-gap-measure against DNS cache poisoning attacks. That's clever, I believe it was proposed before, but bind folks presented some issues and left it at that.

Re:Pointless hype

[nacturation]

If, for example, the telephone company's accounting system goes down for a few seconds then they lose hundreds of thousands of dollars.

There are 31,556,926 seconds in a year. At a hundred thousand dollars a second, your telephone company makes $3,155,692,600,000 a year from time-metered services?

Re:Pointless hype

[mcrbids]

On the other hand, I trust my hosting provider to provide sufficient DNS; but if I were hosting my application on a cloud somewhere, I'd want some cloud-based DNS;

Could you give me an example of an "Internet-based DNS" that isn't also "cloud-based"? The definition of "in the cloud" IS "on the Internet". Your arbitrary distinction simply makes no sense at all. You are asking for DNS with a "distributed architecture" but DNS itself IS a distributed architecture!

I hate to sound trollish, but your over-eager Google fanboyism betrays your underlying non-comprehension of the issues involved! DNS is a distributed architecture, and all that's necessary for you to provide extremely high availability is to provide two (or more) DNS servers at different locations. This eliminates the "single point of failure" and with each location providing better than 99.95% uptime, the odds of both going down at the same moment is measured in hundreds of years. When you consider DNS caching, due to its distributed architecture, (there's that word again) if your hosted DNS were actually completely down for an hour or so, that few of your customers would even notice, that makes the problem even that much more tractable.

PS: "Cloud-based" IS "Internet-based". Please don't treat "the cloud" as if it were different. "The cloud" only has relevance in sales meetings - it's otherwise just Internet-based computing! See what Larry Ellison has to say about this!

Re:Pointless hype

[shentino]

I recently had to deal with a firewall that just flat out BLOCKS outbound DNS. You HAVE to use the network's DNS, which of course is site-filter enforcing.

Mandatory censorship.

Re:Pointless hype

[drinkypoo]

Could you give me an example of an "Internet-based DNS" that isn't also "cloud-based"?

DNS servers are just DNS servers. There's a pool of them that handle requests to a given server. If google Public DNS is implemented like other Google services, your queries will be handled by whichever google node is nearby, idle, and knows the address you're requesting. This seems robust than the way even the existing root servers are implemented. Google has more sites than almost anyone else non-government (there are a few notable exceptions, but none of them have an architecture like google's) and is continually opening more.

Re:Pointless hype

[Sleepy]

>Then you are a fool. This is exactly what I mean by trusting your ISP. I sympathize with you and your situation (and I understand that it happens), but all your country has to do is implement some system that will change the UDP packets coming from Google DNS to change the answers, thus accomplishing the same censorship. The more people who use Google DNS, the more likely a country or ISP is to do this.

A non-sequitur. More people using Google DNS or any other DNS resolver does NOT make it more likely that a country or corporation can impose censorship.

In your previous statement you even hint that you know this - you suggest that a country could "change the UDP packets coming from Google DNS to change the answers", but why would a country target JUST GOOGLE DNS for censorship?

If you took 30 seconds to Google the world's best known DNS censorship project (http://www.google.com/search?q=great+firewall+of+china) you would know that China does not target *specific* DNS resolvers (such as you suggest might be done with "Google DNS"). No, China hijacks ALL port 53 traffic which should be obvious then that the DNS provider is 100% irrelevant.

In fact, a third party DNS provider is MORE likely to offer DNS resolver service on a non-standard DNS port, thus becoming an ANTI-censorship tool that China can not defeat (not without blocking or filtering ALL ports which kills their Internet entirely).

You should be careful about calling someone else a "fool", when speaking of topics on which you have your facts wrong.

Re:Pointless hype

[johny42]

Mandatory censorship.

That doesn't seem like a very mandatory way of censorship. Not being able to translate a site's domain name to its IP address has nothing to do with not being able to access the site.

Re:Pointless hype

[shutdown -p now]

At a hundred thousand dollars a second, your telephone company makes $3,155,692,600,000 a year from time-metered services?

That's easily explained if said telephone company is a mobile operator in USA.

Re:Pointless hype

[mcrbids]

DNS servers are just DNS servers. There's a pool of them that handle requests to a given server. If google Public DNS is implemented like other Google services, your queries will be handled by whichever google node is nearby, idle, and knows the address you're requesting.

And... how is this different than your "local" DNS server? how do you know that Google's DNS is "nearby, idle, and knows the address"?

This seems robust than the way even the existing root servers are implemented. Google has more sites than almost anyone else non-government (there are a few notable exceptions, but none of them have an architecture like google's) and is continually opening more.

Perchance, because this is pretty much how existing root servers are implemented? There was a slashdork article a while back about the challenges of running a root DNS server. Let me assure you, redundancy is paramount - they've NEVER all been down. Ever.

Again, I defy you to please clarify what you mean by "cloud" computing to be any different than "Internet" computing? Because there is no difference. The Internet IS the cloud. Drawing a distinction between the two is like drawing a distinction between your pants and your britches.

And, once again, DNS is a redundant, multi-point, caching, distributed-architecture protocol, and has been for some 20 years.

Do you not know what this means?

"Cloud based" is a marketing term that describes what hosted application providers have been doing in various forms for some 20 years.

Google is average

[jhoegl]

This just in, Google is average at something they did. Google's parents are very upset and will not be posting this on their refrigerator. In other news, detractors of Google throw party.

My Testing Results

[Anonymous Coward]

Resolve www.yahoo.com

local.isp 12msec
4.2.2.2 30msec
208.67.222.222 55msec
8.8.8.8 57msec

My own more detailed analysis

[bramp]

I ran my own set of experiments benchmarking both Google DNS and OpenDNS as well as two UK ISPs. I showed more detailed results, and infer some information about how these systems are run. http://bramp.net/blog/google-dns-benchmarked

Most ISP's DNS servers are broken.

[KingSkippus]

Just ask yourself one question, if you don't trust your internet provider enough to do DNS correctly, should you trust them at all?

My ISP's nameservers are broken. Whenever I try to resolve a name that doesn't exist, instead of the DNS server telling me it doesn't exist, it returns the address of one of my ISP's web servers, which presents me with an ad-laden search page for whatever name I typed in. This is clearly not what the DNS spec says it is supposed to do.

While this might not sound like such a big deal, for developers it's a pain in the butt. For one thing, if I want to test to see if, for example, a name I have registered has propagated, I can't just do an nslookup to see if I get a response; I have to actually verify that the address that is returned (since all lookups will resolve to something) is the actual correct address instead of my ISP's web server. Also, on the client side, when my applications communicate via the web, they have to not only verify that an address resolved, but actually verify with the back-end application that it is what it's supposed to be instead of an ISP's search page. Just since I changed my DNS servers last week, I've already saved at least a minute or two I shouldn't have had to spend in the first place.

Plus, even if all of that still doesn't convince you that Google is actually doing something helpful, there's the simple fact that my ISP's servers actually had on average an hour or so down time every couple of months. It wasn't scheduled or anything (that I know of, anyway), I would just all of a sudden not be able to resolve any addresses. If I called technical support, the goobs there would insist on me plugging my computer directly into their modem, and when it still wouldn't work, they'd schedule a time a few days out for a technician to come out to my house. They simply wouldn't acknowledge that the problem was on their end, not mine, and they didn't understand simple concepts like nslookups, tracerts, etc. I'd invariably just give up, tell them not to send anyone, and wait without Internet access for their network people to figure it out after a lot more people called in.

I started using OpenDNS a long time ago because of all of the problems with my ISP's DNS servers, even though they also redirect queries that aren't found to their search page. If I wanted other features OpenDNS offers like parental controls and such, I'd probably stay with them. As it is, though, consider me another happy consumer of another helpful Google service. As the informal tech support guy for most of my family and friends, I'll be switching as many of them over as I can too, so I can avoid just a few more "Hey, I can't get to the Internet" calls.

Re:Most ISP's DNS servers are broken.

[Shawndeisi]

If you're using a *nix box somewhere on your devel network, "dig +trace host.domain.tld" is a beautiful thing as you'll avoid the cache (and therefore any potentially broken caching nameserver behavior) as all the nameservers you hit will be authoritative. You can see if it truly has propagated, which you can't do with a simple nslookup due to negative caching if your first lookup wasn't successful. Right now you could have a negative record cached for the TTL in the SOA and would have to wait until it expires before you see the live record, while it was already live for everyone else. You'll also be able to devel your app faster because you won't hit the caching server until it's live. There may be an equivalent flag on nslookup but I haven't found it after a few minutes of poking around.