DNS servers - just a short comparision ...

I'm a member of

Quicksearch

Codenews Search

Disclaimer

The individual owning this blog works for Oracle in Germany. 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

Books

Recommended Sun and Solaris Books

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
http://twitpic.com/22vkb7 - In the hindsight

twitter.com/codenews
6966476 syseventd timeout due to lengthy pool_stats ioctl http://bit.ly/cWdEfN

twitter.com/SunPatches
133391-08 - Cumulative Maintenance Sun StorageTek Unisys CSC 5R1 5-1-28. Available since Jul/05/10. http://bit.ly/cg3egG

twitter.com/SolPatchesX86
Security patch: 111607-08 - SunOS 5.8_x86: /usr/sbin/in.ftpd patch. Available since Jul/02/10. http://bit.ly/azglba

twitter.com/SolPatchesSPARC
Security patch: 111606-08 - SunOS 5.8: /usr/sbin/in.ftpd patch. Available since Jul/02/10. http://bit.ly/9gcHsH