Hey everybody, im the creator of dnsperf.
I just wanted to clear some things up.<p>1. The point of the service is to have an objective way to compare different DNS services. dnsperf is supposed only to help you in your search for the best DNS service and not crown the absolute winner.<p>2. I plan to add as many locations as possible to get more reliable data. More locations will also solve the problem of "DNS at the same datacenter as my test nodes"<p>3. Some people are confused about the node locations. Here is the map <a href="http://www.dnsperf.com/network" rel="nofollow">http://www.dnsperf.com/network</a><p>4. Its not open source but some time in the future it will be.<p>5. The tests I am running are supposed to exclude variables such as local/ISP caching, DNS proxies, resolvers, SRTT and so on. I wanted to test the nameservers directly and get the raw performance data of the provider himself. I believe thats the best way to do fair comparison.<p>Thank you for your comments and love. I'm glad people liked the service :)<p>Feel free to email me with your feedback or questions.
"Asia DNS performance"<p>This should really be taken with a grain of salt as Asia is a big place, and unlike Europe or the US, the interconnects between countries are poor. From where I am in the Middle East it's faster to ping Europe (~180ms) than Central Asia (~250ms). I'd love to see a report that takes this and CDN performance into account on a country-by-country basis!
Worth noting, similar things being done here: <a href="https://atlas.ripe.net" rel="nofollow">https://atlas.ripe.net</a>
with real-world examples (measurements from peoples home internet accounts, workplaces, etc - not 'sponsored' vms, not from some random data centre) and measuring just about anything (DNS and websites)<p>You can join, host a probe (get it sent to you, plug it in) and then run your own measurement tests based on the 'credits' you earn from having the probe running.
Is this a good test? The fastest result is 5.9ms.. that means that DNS provider won because they happened to be in the same city where dnsperf tested from. That node is in Sao Paulo Brazil.<p>There are about 400m people in south america, and this test declares a provider to be the fastest for South America because both the provider and the test taker happened to pick Sao Paulo.
My turn to be pedantic :<p>Speed is is the magnitude of velocity so bigger is faster.<p>What is displayed here is the time taken - the reciprocal of speed.<p>Personally I run dnrd, a dns caching proxy <a href="http://dnrd.sourceforge.net/" rel="nofollow">http://dnrd.sourceforge.net/</a>
[Full disclosure: I've worked on Amazon Route 53]<p>It's always neat to see nice data collection like this, but unfortunately the average speed to the authoritative name servers isn't a very meaningful measurement. Real world resolvers bias heavily towards the fastest name server for your zone, and they are so latency sensitive that they'll do things like issue concurrent queries to several name servers at the same time.<p>The upshot of that is that what really matters is the latency to the closest name server, or at worst the latency to the 3rd fastest server; for the rare boot-strapping cases. Bind, the most common resolver by far will issue up to 3 concurrent queries to different name servers as part of its SRTT algorithm. The next most common resolvers; Unbound, OpenDNS, and Google Public DNS perform pre-fetching and so the latencies aren't contributing to the user experience except for extreme outlier queries.<p>Some large DNS providers design to this behaviour, and seek to increase the average distance to their DNS servers by operating the name servers for each domain in different data centers. That gives routing and path diversity for the DNS queries and responses. Since network path diversity increases with distance, this works best when you include a location or two that are quite far away, which increases the average latency to those servers - but thanks to resolver behavior doesn't do much to the user-experience.<p>A write up for Route 53's consideration of the trade-offs is here: <a href="http://www.awsarchitectureblog.com/2014/05/a-case-study-in-global-fault-isolation.html" rel="nofollow">http://www.awsarchitectureblog.com/2014/05/a-case-study-in-g...</a> (there's also a video about the role this plays in withstanding DDOS attacks: <a href="https://www.youtube.com/watch?v=V7vTPlV8P3U" rel="nofollow">https://www.youtube.com/watch?v=V7vTPlV8P3U</a> around the 10 minute mark).<p>Where the average latencies are low, all of the name servers are in close proximity to the measurement point and I would wager that the network path diversity is probably quite low. A small number of link failures or ddos/congestion events, maybe even one, might make all of the servers unreachable.<p>A more meaningful measurement of the speed itself is to perform regular DNS resolutions, using real-world DNS resolvers spread out across your users. In-browser tests like Google analytics go a long way here, and it's fairly easy to A/B test different providers. The differences tend to be very small. Caching dominates, as others here have mentioned.<p>Apologies if I seemed to rain on dnsperf's parade here; it's a neat visualization and measuring this stuff is tough. It's always good to see someone take an interest in measuring DNS!
The site is very clean looking and it is entertaining to look at the results.<p>That said, there are a number of problems with this:<p>1. As stated by other people here, this is only from the perspective of where the tests originated, and is somewhat irrelevant once the DNS result is cached by your ISP.<p>2. If you are using any of a number of modern browsers, DNS will be prefetched before you even click on any link, so the DNS time from a user perspective will be zero the majority of the time.<p>3. The point of this was originally for choosing a good host for shared JS files. It is much more meaningful to use a distributed host with location based DNS to point you to the nearest fastest server, rather than just making the DNS request itself as fast as possible. Why do you think Google has so many servers all around the world?
<disclaimer>I'm from Dyn.</disclaimer><p>We're thrilled to see a new DNS performance monitoring tool in the public domain. It takes courage to release things like this to the world and open them up for critique, I applaud jimaek, the author, for doing just that.<p>As many have noted, the results are highly varied from many of the other reports we see today but more locations and tests are going to continue to improve accuracy.<p>The testing is synthetic, that is, it's run from within datacenters. I'd encourage anyone who can help provide/sponsor a VPS or resources to also do so. Providing consistent benchmarks against Authoritive Queries from know locations is great but the test network itself needs to expand to get truly meaningful comparisons between providers.<p>I'd hope to see real-user data also get added in the future, that is, testing on the end of home cable/broadband connections, these tests perform differently to synthetic tests but represent end-user experience more accurately.<p>It would also be great to see raw lookup performance between providers, exclusive of network latency.<p>For those interested in diving deeper into DNS performance, I'd also recommend reviewing Cloud Harmony's reports, the latest of which can be found here: <a href="https://cloudharmony.com/reports/state-of-the-cloud-dns-0315-report" rel="nofollow">https://cloudharmony.com/reports/state-of-the-cloud-dns-0315...</a>
This a a great service – and I'm really happy to see that “world-wide” isn't defined as “North America and Europe”. Hopefully it won't be too hard to add Africa, the Middle East and India to the mix as I've seen much more network variability in those regions.<p>For this kind of measure, it would really be better to use either a median or, better, reporting multiple percentile performance. In my experience, DNS timings have extremes which might be surprising (e.g. most people see 50ms but 10% of visitors see 5+ seconds) and a few large samples will distort an average.<p>Your 2 second cap will cap the distortion, which is much better than e.g. Google Analytics which will merrily record multi-hour timings, but I'd really prefer to see e.g. 50th, 75th and 95th percentiles to see whether a particular provider might have better worst-case performance than another.
Throwing my $0.02 into the pool...<p>I've been very happy with DNSMadeEasy (although I think the name somehow diminishes it's technical viability somehow - not sure why, but it sounds "cheesy" which is not reflective of the service at all). I am very glad to see them in the top 10 for the most part, they offer a fantastic product, well documented easy to use API and great management panel.<p>For comparison I've tried Zerigo, PowerDNS, UltraDNS, Dyn and Route53 and dropped them all for either cost or technical reasons. For my small use cases I've found DNSMadeEasy to be a nice middle-ground.<p>Would be interesting if the OP could add some sort of subjective rating options from outside sources in terms of user reviews. Could rank the providers on performance (latency), cost, functionality (API, Anycast, etc) and management.
I was surprised Dyn weren't faster. Drilling down, I wonder what was going on between 25th Feb and 11th March? <a href="http://www.dnsperf.com/provider/Dyn" rel="nofollow">http://www.dnsperf.com/provider/Dyn</a>
Nice to see OVH doing well. I have been really happy with their smallest 'VPS classic', at a third of a price of a t2.micro or linode (2.40€) it's a lot of bang for the buck. Plus I have a top level domain from them for like one euro per year (.ovh) so I can get a free ssl cert from StartSSL as well. Dirt. Cheap.