DNS servers - just a short comparision ...

I'm a member of

Quicksearch

Codenews Search

Disclaimer

The individual owning this blog works at Sun Microsystems GmbH in Germany, a subsidiary of Oracle. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.

Navigation

< Groklaw about the Moglen letter | links for 2009-12-05 >

DNS servers - just a short comparision ...

Friday, December 4. 2009

Either the DNS servers of my ISP are extremely good or other providers have extremly bad DNS servers. I've repeated each request ten times and took the second-best result:

Google DNS:

$ dig @8.8.8.8 facebook.com | grep "Query time:" ;; Query time: 31 msec

OpenDNS:

$ dig @208.67.222.222 facebook.com | grep "Query time:" ;; Query time: 44 msec

Telekom T-Home VDSL

$ dig @217.237.150.205 facebook.com | grep "Query time:" ;; Query time: 22 msec

Posted by Joerg Moellenkamp in English at 22:31 | Comments (15) | Trackback (1)
View as PDF: This entry | This month | Full blog

Trackbacks

Trackback specific URI for this entry

Google macht jetzt auch DNS schoen
Goggle. Mal wieder. Gestern haben sie ihre oeffentlich zugaenglichen DNS Resolver vorgestellt. Googel bietet damit jetzt an, was die SPD oder das BKA auch schon im Programm hatten. Mittlerweile haben SPD und BKA das abstellen (lassen) aber zumindest die S

Weblog: netzsheriff.de
Tracked: Dec 05, 14:07

Comments

Display comments as (Linear | Threaded)

Haha. Why did you take the second best? Was the first better on the non-ISP servers?

#1 lulzymclulz on 2009-12-04 22:44 (Reply)

No ... because i considered the best result of the T-Home DNS as an anomaly as an measuring error, it was even faster ...

Taking the second best result resulted in numbers that was more in line with the otherl results. The best result for OpenDNS was 3 msecs better ... the best result for Google 2 msec better.

#1.1 Joerg M. (Homepage) on 2009-12-05 06:20 (Reply)

this is how it looks here:

for ip in 8.8.8.8 208.67.222.222 217.237.150.205; do echo ${ip} $(for i in `jot 10 1 10`; do dig @${ip} facebook.com | grep "Query"; done | awk '{ print $4 }' | sort | head -2 | tail -1)ms; done

8.8.8.8 13ms
208.67.222.222 29ms
217.237.150.205 24ms

there is heavy correlation with the measured RTT to this destination (max 1 to 2 ms difference), the last one do not answer to icmp.
Looks for me as if the network is the limiting factor, the dns servers themselve are much faster in this cases where the result is already within the cache.

#2 Jürgen Unger (Homepage) on 2009-12-04 23:21 (Reply)

hey dwalin

8.8.8.8 52ms
208.67.222.222 60ms
217.237.150.205 51ms

(slow atom-based computer, bad wifi signal, 3MBit/s T-DSL)

#2.1 Sebastian (Homepage) on 2009-12-05 01:52 (Reply)

Nice one-liner

Interestingly it looks differently to my results at home when i start this script on my root server.

primary:~# for ip in 8.8.8.8 208.67.222.222 217.237.150.205; do echo ${ip} $(for i in `jot 10 1 10`; do dig @${ip} facebook.com | grep "Query"; done | awk '{ print $4 }' | sort | head -2 | tail -1)ms; done
8.8.8.8 5ms
208.67.222.222 21ms
217.237.150.205 10ms

#2.1.1 Joerg M. (Homepage) on 2009-12-05 06:32 (Reply)

... because handing over even more information to the world's foremost data mining company is a great idea.

#3 isolation on 2009-12-05 03:06 (Reply)

Well ... it's an decision: What do you get back for giving your data? In my example ... nothing ... so there is no reason to use it ... for other people this may look differently ...

#3.1 Joerg M. (Homepage) on 2009-12-05 06:23 (Reply)

isolation,

have you actually read the terms of service? They seem to be more than fair. Your IP-Adress will be liked to your query only for 24-48 hours.

Or what could they legally do with that data in those 24-48 hours? Maybe, if they saved a state vector of each and every internet user, they could adjust it to the additional data. But I'm not sure if that's legal, and in my interpretation of the TOS, it does not happen.

Oh yeah, and I'm not querying google's search-enginen directly, but via proxy, don't let it set cookies, and map google-analytics to 127.0.0.1 etc...
and sometimes I use exalead, when I'm searching for things that "normal" people might search for and with google one might therefore find only link-farms and wikipedia-entries...

#3.2 Santa Klau's on 2009-12-05 10:50 (Reply)

Results early this Saturday morning don't differ that much between my ISP and Google, with OpenDNS left behind:

@8.8.8.8 (Google): 10 msec
@208.67.222.222 (OpenDNS): 24 msec
@82.212.63.20 (KabelBW, my ISP): 11 msec

#4 Jens (Homepage) on 2009-12-05 09:01 (Reply)

I guess I should consider switching to Google DNS:

8.8.8.8 2ms
208.67.222.222 15ms
217.237.150.205 8ms

#5 Stefan on 2009-12-05 09:51 (Reply)

Been using OpenDNS here for a few years and you'll see why …

8.8.8.8 109ms
208.67.222.222 53ms
156.154.70.22 55ms
217.237.150.205 114ms

So think it'll be a while before I switch!

#6 Craig on 2009-12-05 10:56 (Reply)

Depending on the location of the server from which I made the requests (two in Germany, one from France and one from the USA):

Google (8.8.4.4): 7 up to 37ms
OpenDNS (208.67.222.222): 0 up to 32ms
Level 3 (4.2.2.2): 9 up to 105ms
my own resolver (x.x.x.x): 4 up to 175ms

#7 Jens (Homepage) on 2009-12-05 14:11 (Reply)

At my parents ... T-DSL as well, but ADSL at 6 MBps ...

$ for ip in 8.8.8.8 208.67.222.222 217.237.150.205; do echo ${ip} $(for i in `jot 10 1 10`; do dig @${ip} facebook.com | grep "Query"; done | awk '{ print $4 }' | sort | head -2 | tail -1)ms; done
8.8.8.8 53ms
208.67.222.222 64ms
217.237.150.205 44ms

#7.1 Joerg M. (Homepage) on 2009-12-05 14:37 (Reply)

Ok, this is my situation at home behind a 50mbit VDSL line:

Google (8.8.4.4): 37ms
OpenDNS (208.67.222.222): 42ms
Level 3 (4.2.2.2): 30ms
my own resolver (x.x.x.x): 24ms

#7.1.1 Jens (Homepage) on 2009-12-05 15:04 (Reply)

here at Sao Paulo, Brazil...
8.8.8.8 10ms
208.67.222.222 138ms
10.1.1.1 10ms

10.1.1.1 being my local resolver cache

#8 Yuri on 2009-12-06 05:03 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	E-Mail addresses will not be displayed and will only be used for E-Mail notifications. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above: Standard emoticons like :-) and ;-) are converted to images. Enclosing asterisks marks text as bold (word), underscore are made via _word_.
	Remember Information? Subscribe to this entry

View as PDF: This entry | This month | Full blog

Competition entry by David Cummins powered by Serendipity v1.0

Links in this article

The LKSF book

The book with the consolidated Less known Solaris Tutorials is available for download here

Twitterfeeds

twitter.com/c0t0d0s0
just blogged: links for 2010-03-19: Gedanken eines Fliegenden: Freikoerperkultur ... http://bit.ly/c21ARU

twitter.com/codenews
6935782 need to manually increment build number one more time http://bit.ly/aMqEbX

twitter.com/SunPatches
Security patch: 120228-40 - Messaging Server 6.3-11.01: core patch. Available for SPARC since Mar/17/10. http://bit.ly/bk1hw3

twitter.com/SolPatchesX86
122301-49 - SunOS 5.9_x86: Kernel Patch. Available since Mar/17/10. http://bit.ly/9ETInV

twitter.com/SolPatchesSPARC
122300-49 - SunOS 5.9: Kernel Patch. Available since Mar/17/10. http://bit.ly/b9ZvRJ