8 ms·
Worldwide DNS Performance
- beauzero 12y agoDoes godaddy use a third party DNS or were they just not on the list?
- scrollaway 12y agoHow is OpenDNS and DNSCrypt not in the list? Am I missing something?
- lucaspiller 12y ago"Asia DNS performance" 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!
- jlgaddis 12y agoAnd, FWIW, it appears (to me, at least) that the Asia testing likely only happens from Japan, Hong Kong, and Singapore. I imagine the latency from any of those locations to "Central Asia" is probably pretty high anyways.
- baconhigh 12y agoSame goes for "The Pacific" and probably "Europe". Very generic - depending on where the testing was actually done the results could vary a lot.
- niklasber 12y agoAgreed. Any plans on releasing this open source? Would be cool if others who are interested could set up country-by-country versions for Asia for example. Like one for Vietnam, Japan etc.
- SixSigma 12y agoMy turn to be pedantic : Speed is is the magnitude of velocity so bigger is faster. What is displayed here is the time taken - the reciprocal of speed. Personally I run dnrd, a dns caching proxy http://dnrd.sourceforge.net/ http://dnrd.sourceforge.net/
- ajkjk 12y agoNo. Speed has a different meaning when talking about latencies.
- SixSigma 12y agorequests per second
- cbd1984 12y ago> Speed is is the magnitude of velocity so bigger is faster. If you're going to be pedantic, velocity is a vector, and vectors must reside in a vector space, so what vector space do the velocities in this context reside in? Ignoring all context to call into doubt the use of a perfectly well-understood word adds nothing to the discussion.
- SixSigma 12y agorequest to and from the server are in opposite directions and travel along edges of a graph via nodes.
- contravariant 12y agoThat vector space would be the real numbers.
- tribaal 12y agoInteresting for me to see DigitalOcean perform so badly (in this particular metric), especially since they seem to be pretty fast for me in general.
- danielsamuels 12y agoThey recently switched to using CloudFlare, look at the detail graphs - http://www.dnsperf.com/provider/DigitalOcean http://www.dnsperf.com/provider/DigitalOcean I'm not sure why they're still so high though.
- aeden 12y agoMy 2c: DNS latency is only one factor in overall perceived performance, and it can be affected greatly by routing, traffic load, and other factors. Additionally, many requests you'll make will likely go through a resolver with caching anyhow, so that too can have a significant impact on perceived latency. Thus DO (or any provider for that matter) only really needs to provide reasonable resolution times from their servers to be effective. A more important matter is consistency, i.e. are they consistently returning responses or are they actually dropping packets due to load. With a service that's growing quickly, keeping up with the increase in load on their network probably presents a more significant problem.
- rgbrenner 12y agoIs 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. 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.
- aeden 12y agoNot really, no. In general tests for latency aren't that valuable except to perhaps show providers where they might want to place their next PoP, since if you have the ability to look at a finer grain you can actually identify generally where latency presents the greatest problem (i.e. areas where instead of 40ms response time, you see 400ms).
- ukandy 12y agoNot forgetting cache, and the fact that slower response times aren't horrendous in the scheme of things.
- colmmacc 12y ago[Full disclosure: I've worked on Amazon Route 53] 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. 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. 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. A write up for Route 53's consideration of the trade-offs is here: http://www.awsarchitectureblog.com/2014/05/a-case-study-in-global-fault-isolation.html http://www.awsarchitectureblog.com/2014/05/a-case-study-in-g... (there's also a video about the role this plays in withstanding DDOS attacks: https://www.youtube.com/watch?v=V7vTPlV8P3U https://www.youtube.com/watch?v=V7vTPlV8P3U around the 10 minute mark). 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. 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. 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!
- mslot 12y ago
- jimaek 12y agoHey everybody, im the creator of dnsperf. I just wanted to clear some things up. 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. 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" 3. Some people are confused about the node locations. Here is the map http://www.dnsperf.com/network http://www.dnsperf.com/network 4. Its not open source but some time in the future it will be. 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. Thank you for your comments and love. I'm glad people liked the service :) Feel free to email me with your feedback or questions.
- deleted 12y ago[deleted]
- Florin_Andrei 12y agoThe word "speed" usually suggests that more is better. What the graphs actually display is latency - in which case less is better. That was confusing for a few moments.
- jimaek 12y agoI guess I will need to fix that. thanks for the feedback
- windexh8er 12y agoLatency is a function of the speed of light - and in most engineering realms "speed" is well understood when using latency as a description. I had no qualms understanding what the creator meant, but I agree that the technical reality is the graph should be defined by "query latency" vs "query speed". Either way, fantastic data! Hopefully this data is trended over daily, weekly, monthly, quarterly, and yearly rollups. I see monthly when drilling into a provider, but that's all. A rolling annual graph would really tell a true story of how consistent a provider is and that, in itself, is very important when considering outsourcing DNS.
- corford 12y agoI was surprised Dyn weren't faster. Drilling down, I wonder what was going on between 25th Feb and 11th March? http://www.dnsperf.com/provider/Dyn http://www.dnsperf.com/provider/Dyn
- jimaek 12y agoI can say that it was nothing related to dnsperf. The perf change was on Dyn's side
- andypiggott 12y ago<disclaimer>I'm from Dyn</disclaimer> Dyn's early results were not representative of our network or service. This was as a result of the limited number of nodes currently testing and the location of these nodes. We found a routing issue between Azure and ourselves via one carrier leading to elevated results for a short period of time. There's been great commentary on here about providers showing as fast because of the proximity of the tests. This will only be rectified by adding more monitoring and a broader base of test locations. I know jimaek is working on getting new locations online - if anyone here can assist in providing or sponsoring test locations, I encourage you to reach out to him.
- baconhigh 12y agoWorth noting, similar things being done here: https://atlas.ripe.net https://atlas.ripe.net 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) 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.
- corford 12y agoNice! Just signed up to host a probe but looks like they'll only send you one if they don't already have good coverage of your location/network. Not holding out much hope as afaict Europe is already pretty much blanketed :(
- Ono-Sendai 12y agoX-axis should be labelled.
- puzzlingcaptcha 12y agoNice 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.
- windexh8er 12y agoThrowing my $0.02 into the pool... 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. 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. 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.
- Thaxll 12y ago100ms on Google DNS, there must be something wrong with your test...
- rilita 12y agoThe site is very clean looking and it is entertaining to look at the results. That said, there are a number of problems with this: 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. 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. 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?
- acdha 12y agoThis 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. 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. 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.
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- andypiggott 12y ago<disclaimer>I'm from Dyn.</disclaimer> 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. 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. 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. 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. It would also be great to see raw lookup performance between providers, exclusive of network latency. 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: https://cloudharmony.com/reports/state-of-the-cloud-dns-0315-report https://cloudharmony.com/reports/state-of-the-cloud-dns-0315...