dns traversal and dns performance

fyi: managed dns services - edgedirector.com

The depth of a dns traversal can have a significant influence on the total time taken to satisfy a dns query. Mismatching the tld extension and available name server names can exacerbate any existing problems.

The example below arose from a forum discussion of the purported performance benefits of anycast dns. As it turns out, the dns traversal was shown to be the real culprit. The content below is a reformatted version of the original forum discussion.

The claim was:

I dunno. Using example.com I see DNS resolution times make up almost all of the time loading my site for the "using my own" dns resolver domain (ktunnel.com) (>100ms in the US, 200-800ms everywhere else), whereas for my dns made easy domain (vtunnel.com), it brought down the total time to load the site by a lot (at least 100ms), with some locations doing under 50ms that were at 200ms or more using my own resolvers.

Third party dns traversal tools showed the following results:

vtunnel
Asking a.root-servers.net (198.41.0.4) for vtunnel.com (type A)
Asking a.gtld-servers.net (192.5.6.30) for vtunnel.com (type A)
Asking ns0.dnsmadeeasy.com (208.94.148.2) for vtunnel.com (type A)  

ktunnel
Asking a.root-servers.net (198.41.0.4) for ktunnel.com (type A)
Asking a.gtld-servers.net (192.5.6.30) for ktunnel.com (type A)
Asking a.root-servers.net (198.41.0.4) for ns1.freeproxies.org (type A)
Asking a0.org.afilias-nst.info (199.19.56.1) for ns1.freeproxies.org (type A)
Asking ns1.freeproxies.org (206.217.212.195) for ns1.freeproxies.org (type A)
Asking ns1.freeproxies.org (206.217.212.195) for ktunnel.com (type A)

In plain language, the difference lays in the doubling of the number of queries due to dns traversal problems.

ktunnel is hobbled as compared to vtunnel because a lookup for ktunnel.com requires three extra lookup as compared to vtunnel.com. Looking up ktunnel requires *double* the number of lookups. No wonder it looks slower.

These extra lookups are caused by the fact that the name servers for ktunnel are at freeproxies.org. In that scenario, an initial query at the root servers will yield a referral to the name servers, but without glue records. The querying server then has to query three extra times. Once for .org, once for freeproxies.org and once to confirm the glue. Couple this with the fact that of all the generic tld's, the .org parents are the slowest, and it is predictable that ktunnel lookups will be slower than vtunnel lookups.

As ktunnel is a .com, the best thing you can do to remedy the situation is to move them to name servers that are themselves in a .com or .net tld. This is because the .com and .net parent servers are common and will return glue for name servers with either tld. That will cut the dns traversal in half, from 6 queries to 3 queries. Just like for vtunnel.

Our users don't get hit with this problem because the control panel contains recommendations on which name server series to use with which tld. Every recommendation has been checked by hand.