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

[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

[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

[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

[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

[interval1066]

Hey, that's fucking hilarious.

To continue, and briefly, a friend of mine worked for a company who had a network spur that was little used, and served by these two OpenBSD machines, and these machines sat for a few years almost forgotten when one day their whole network started acting funny, a few name queries would end up in strange and obviously incorrect domains. A days of poking around led me to these two machines. Seems whomever set them up wanted them as a back door into this intranet, so they let one serve up a telnet port as well as name service. I don't think it was anything malicious, but whatever it was whomever set it up let the machine serve up bare, un-covered telnet, like a fool, no ssh tunnel, no nothing. Late at night I noticed both machine unusually active, so I took a look. Connected to the one machine was a telnet session with an endpoint somewhere in China. A closer look revealed the server's kernel had been recompiled. I didn't do any further analysis, I just shut down that port at the firewall and reported what I found. I think the company ended up retiring those servers and bringing that part of their intranet into the main fold of the corporate server stable.

Multiple, parallel, DNS server settings?

[NevarMore]

I suspect this has been asked before. Is there some way to set up multiple DNS servers and simply query them in parallel?

That way whichever one is fastest gets me the address sooner. It is a little bit rude, but since it would seem that most DNS providers have the opportunity to be shady and feed landing pages or collect usage data, they'd be just as happy to have me make a request and discard the answer.

Re:UDP block - use pdnsd with tcp_only

[yukam]

Did not found way to force system resolver to use tcp-only, but something like this should work:
aptitide install pdnsd
=== cut /etc/pdnsd.conf ===
global {
query_method = tcp_only;
}
server {
ip = 8.8.8.8, 8.8.4.4;
label = "google";
}
=== cut /etc/resolv.conf ===
nameserver 127.0.0.1
That's slower than udp, but better than nothing (and pdnsd cache will compensate slowdown from tcp usage).