A popular “metric” in the space are benchmarks depicting speeds of DNS lookups. Sales guys love to tell you “your existing DNS is slow” and that theirs is fast.
Salespeople love to show you a chart or refer to “independent test results” that clearly vindicate them as having the fastest DNS servers on the internet.
The truth of the matter is “DNS speeds” are largely a red herring and is basically another example of a non-issue being dressed up as a feature. (Stay tuned for the following section “ How DNS Lookups actually work” to understand exactly why).
Are your users complaining about “slow DNS speeds” ? Are there legitimate complaints about the response times of your website or your applications which your own systems and IT people have definitely traced back to “slow nameservers” and then “your slow nameservers”?
I’ll tell you a secret about almost every single nameserver connected to the internet right now and that is nearly every single one of them is probably on their own fast enough. What will make a difference are the networks they are deployed on, transient issues like congestion and packet loss, whether they are unicast or anycast, but beyond a certain point, pretty well all of the professional DNS deployments (and even a good chunk of the half-assed ones) are fast enough.
The most vociferous complaints about your nameserver speeds are probably coming from salespersons employed by a DNS provider attempting to sell you services. Unless you have a corresponding stack of emails in a folder tagged ” COMPLAINTS: SLOW DNS”, I wouldn’t let this sway you into a big purchasing decision.
Lookup speeds are not what separates a reliable, bullet-proof DNS infrastructure from an unreliable one.
What really counts when it comes to DNS infrastructure are things like: redundancy, resilience, network dispersion (this is not so your dns is “faster” everywhere, it is so your dns is reachable everywhere under more conditions) and security (by security I mean that the servers themselves are secure and you’re not running an unpatched version of Bind 8 on a box that’s wide open).
Because here’s the unpleasant truth that DNS salespeople can’t come to grips with: Rock solid reliable DNS isn’t usually a performance boost, it’s an assurance of performance.
It’s one less thing that can go wrong, or at least, one less thing that is likely to go wrong. And if you are using a professional DNS outfit to host your DNS, if it does happen to go wrong, it will at least be handled by people who specialize in making DNS problems go away, instead of your systems guys frantically leafing through the Cricket book.
How DNS Lookups actually work:
One seldom examined issue around the entire “DNS speed” competition in the space is the methodology around measuring these speeds in the first place. There are several companies on the internet that do nothing but measure uptime of third-party systems. As a side effect, they will usually also measure response speeds. These speeds are then seized upon by the (lucky) victor as “proof” that “their nameservers are the fastest”.
But are they? Some monitoring services are run out of a single datacenter. If you happen to have a DNS server located in that same datacenter, then guess what? You’ll win. But it really has nothing to do with overall, average speeds across the entire internet because in reality, there are so many transient, shifting factors involved that this changes on literally a minute-to-minute basis.
While measuring the response time of a webserver may have practical utility, when it comes to nameserver speeds they do not convey very much useful information.
When a benchmarking company goes to test the response of a nameserver, it probably does so by taking a domain it knows to be hosted on those servers, and then asking those servers directly for an answer:
markjr@phoenix:~/$ time dig easydns.com @dns1.easydns.com ; <<>> DiG 9.2.4 <<>> easydns.com @dns1.easydns.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9876 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 7 ;; QUESTION SECTION: ;easydns.com. IN A ;; ANSWER SECTION: easydns.com. 300 IN A 205.210.42.30 ;; AUTHORITY SECTION: easydns.com. 300 IN NS dns3.easydns.org. easydns.com. 300 IN NS dns4.easydns.info. easydns.com. 300 IN NS dns1.easydns.com. easydns.com. 300 IN NS dns2.easydns.net. ;; ADDITIONAL SECTION: dns1.easydns.com. 300 IN A 66.225.199.10 dns1.easydns.com. 300 IN AAAA 2001:1838:f001::10 dns2.easydns.net. 60 IN A 72.52.2.1 dns3.easydns.org. 60 IN A 64.68.193.10 dns3.easydns.org. 60 IN AAAA 2620:49:a::10 dns4.easydns.info. 43200 IN A 194.0.2.19 dns4.easydns.info. 43200 IN AAAA 2001:678:5::13 ;; Query time: 11 msec ;; SERVER: 66.225.199.10#53(dns1.easydns.com) ;; WHEN: Fri Apr 22 12:39:51 2011 ;; MSG SIZE rcvd: 303 real 0m0.048s user 0m0.000s sys 0m0.000s
Notice that the bolded line in the “dig” comment shows the query time as 11 milliseconds, but the “real” time reported back by our unix “time” command (a shell command that measures how long another command takes to execute), tells us 48 milliseconds. What does this mean? It means it took 37 milliseconds for the local DNS resolver to even find the authoritative DNS server. More than three times longer than it took for the actual lookup to occur. The “bottleneck” then, if there is any, is in your local computer DNS resolver getting the result back from a DNS lookup and handing it back to the networking application that is asking for it.
It gets even more meaningless, because in reality, no actual applications or clients will actually do a DNS lookup like that. If they really could go straight to the nameservers in question then you wouldn’t actually need dns!
What really happens is that your client applications have to ask their own local dns resolver for an answer, and that resolver goes through the entire DNS lookup chain to find an answer (look carefully at the bolded lines below):
markjr@phoenix:~/$ time dig +trace easydns.com ; <<>> DiG 9.2.4 <<>> +trace easydns.com @dns1.easydns.com ;; global options: printcmd com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. ;; Received 489 bytes from 128.8.10.90#53(D.ROOT-SERVERS.NET) in 20 ms easydns.com. 172800 IN NS dns3.easydns.org. easydns.com. 172800 IN NS dns1.easydns.com. easydns.com. 172800 IN NS dns2.easydns.net. easydns.com. 172800 IN NS dns4.easydns.info. ;; Received 171 bytes from 192.35.51.30#53(f.gtld-servers.net) in 89 ms easydns.com. 300 IN A 205.210.42.30 easydns.com. 300 IN NS dns2.easydns.net. easydns.com. 300 IN NS dns4.easydns.info. easydns.com. 300 IN NS dns1.easydns.com. easydns.com. 300 IN NS dns3.easydns.org. ;; Received 243 bytes from 64.68.193.10#53(dns3.easydns.org) in 21 ms real 0m0.171s user 0m0.000s sys 0m0.000s
If you see the example above, we can look at the response times for each “hop” in the DNS authority chain, and my word, it looks like F-Root (one of the internet Root Servers) took an ungodly 89 milliseconds to return the authoritative DNS servers for my domain? I should call Paul Vixie and tell him “the f-root looks pretty slow to me”.
Once the local resolver goes through this process and obtains an answer, it caches it. Any future queries for this record will, for the time being, be returned by the resolver, not the authoritative nameserver.
So what is truly the single, most important, actual real-life factor that affects DNS response times and lookup speeds in real world applications is more the local DNS resolvers that any given application is using, than the authoritative DNS servers that they actually pull their answers from.
What this means: is that you could have the undisputed, undeniably, uncontested fastest nameservers everdoing primary DNS for your domains, but the lookup speeds that will be experienced by your users will be more closely affected by whatever their ISP or their organization is using for a DNS resolver, and you have pretty well zero control over that.
So the best you can hope for in authoritative DNS servers when it comes to speed is that they are fast enough (there’s that phrase again), that they do not add undue latency to the overall sequence. In other words, they don’t exacerbate any other slow points in the chain by being unduly slow themselves. But I’ve always viewed their utility as a “performance enhancer” is more marketing than reality
(As an aside I’ve also asked one of the most successful “domainers” in the world about his experiences. We’re talking about a guy who has so many domain names that he owns his own Registrar and earns an almost mythical amount of money via domain parking. His results from testing a DNS solution from one of the big enterprise providers that ran him $20,000 / month? – “no difference in anything” – no “bump” in page views, no increased traffic, nothing. And to a domainer, any lift they can get at the front end of the funnel would translate in an almost linear fashion into a direct revenue boost. So if it was there, they’d go with it. Now he runs his own small, DNS anycast infrastructure in-house and has had no real problems to speak of.)
DNS Responses period: What’s really important.
What we know is that there are few people in the world who even have an awareness of DNS speeds, and most of those people are salesmen employed by DNS providers (except here at easyDNS, where we do not employ any salespeople).
In practical terms, most people will not notice if one nameserver reports back in 45ms and another one reports back in 90ms. It takes you almost four times longer to blink than the difference between response times on that scale.
DNS is more of a boolean thing. What counts is that you get a response: period. Because this is the eternal truth behind DNS: Nobody notices it (or cares) unless it stops working.
And then, all hell breaks loose. Twitchhunts, shitstorms, smackdowns #fail #fail #fail. Debacles don’t erupt because a DNS response took 30ms longer to arrive than Company X’s DNS response. They erupt because they just….stop….arriving.
So the big important thing you need to evaluate when looking at your DNS solution is “How good is this system at keeping things running?” Forget “query response times”, how does it hold up if half the internet is dark? What happens if a 10Gig/Second DDoS attack gets launched at YOUR current DNS servers? How many nameservers do you have and how many can you lose and keep operating? Or rather, if 10 or 12 or 15 of your nameservers got wiped out today, how many would you have left to carry your business?
These are the important questions.
You can view the easyDNS nameserver deployments here:
https://easydns.com/our-nameservers
Just in case you were wondering, they are pretty fast (fast enough). But more importantly: Our Enterprise DNS SLA provides for 100% DNS Uptime.
If you found this post of interest and would like to subscribe to the author’s Domain Insights mailing list, sign up here.
It means it took the local recursive name server ~37 ms to resolve
dns1.easydns.com. Without knowing the cache state of the local
recursive name server it is hard to say if this is good or bad.
Right, that makes sense. Again, it comes down to the state of the local DNS resolver.
The cache state can of course be set by running the command more than once.
From here it took half a second to resolve dns1.easydns.com the first time, after that I have query time plus 16 milliseconds which appears to be query time plus 16ms local CPU (local recursive name server is my PC).
However work involved can make a difference to DNS performance, having low TTL for records, especially name server records does make a visible difference to users as the local cached copy needs to be refreshed more often requiring a round trip away from the local cache.
Well designed local networks and OSes will have low latency on cached DNS lookups – so like my PC most of the time is spent on any required off network fetches.
In this case the slow (37ms) is most probably because dns1.easydns.com has a 300 second TTL so was probably expired from the recursive name server cache requiring off network fetches. This is “fixable” by increasing the TTL on the record, which for stable DNS with Anycast could presumably happily be the same as dns*.easydns.org?
Of course the TTL of the resulting data is probably more crucial, but that doesn’t mean with an average of 13 DNS queries per website by some estimates that slow look up of authoritative DNS is unimportant.
I’ve had great fun in the past discussing DNS server performance with Rick Jones at HP, but 15 years ago well specced desktop PCs could saturate 100Mbps line with DNS traffic which is way more than 99.9% of name servers will need even the way Microsoft abuse the protocol.
I’d argue as a result that it is DNS configuration that is almost entirely the limiting factor on DNS look-ups, correct delegation, TTL choice.
No matter how fast it is, it is better not to do it if you don’t have to.
Yah. One lookup isn’t so bad at 30msec, but when you have to do 30 lookups in serial (not parallel) 30msec per query adds up.