Home / server / Questions / 451428
Accepted
thomasrutter
Asked: 2012-11-23 18:43:10 +0800 CST

For Australian audiences, would an uncached .com.au domain resolve faster than an uncached .com?

  • 772

Is there any speed benefit to using a .com.au domain rather than a .com if your customers, hosting and DNS services are in Australia, specifically in the worst typical case (domain is not cached in any local DNS relay for customer)? Assuming that both domains pointed to the same nameservers in the end.

I know this is mostly academic because we are talking about a DNS lookup that would take at most a few hundred milliseconds and would only be relevant once at the beginning of a session. I just was curious.

I know that an uncached .com lookup will involve consulting at least one ?.gtld-servers.net. server and an uncached .com.au will involve consulting at least one ?.au. server.

Now, what I guess I'd need to know is

  • Are the various ?.gtld-servers.net. servers using anycast technology that would have local fully authoritative nodes in Australia, making them just as fast to Australians as ?.au. and avoiding a 200ms+ overseas latency, or are some or all of them hosted only in the US or in the northern hemisphere?
domain-name-system

1 Answers

  1. Best Answer

    My preliminary research indicates the answer is yes. Using dig <domain> +trace I've been noting the time that the relevant top level name server takes to return the nameservers from the next step (in most cases, the step that returns ns1.someisp.com and ns2.someisp.com).

    While a surprising number of queries both for .au domains and .com domains come from nameservers that seem to involve a round-trip to the USA, this was occurring more for .com domains than .au domains.

    ...

    Ok, so I've done some more research, and I thought I may as well report the results.

    • All DNS queries start with the root zone, though it's very unlikely a query in the root zone will ever have to query a root zone server, as it will almost always be cached (this is a small zone, which only resolves the names "com", "org", "au", etc. The root zone nameservers have a fairly good presence in Australia (I think about 4 out of 13 have a node in Australia). But we probably don't need to worry about this.

    • Then a DNS query will query the top-level domain servers. For an unknown domain name, this won't be cached, so this step is important in how fast something resolves.

      Of the 13 TLD servers for the .com and .net domains, 1 of them will reply from Australia (most likely because it uses anycast addressing and has an Australian node). Upon trying a random name server for an unknown .com domain there is a 1/13 chance it will return quickly (by which I mean <25ms for Australians, as opposed to 190-280ms which is typical for a roundtrip to the US).

      Of the 12 TLD servers for the .au domain, 4 of them will reply from Australia. Upon trying a random name server for an unknown .*.au domain there is a 4/12 (or 1/3) chance it will return quickly. FYI, two of these reply in less than 5ms from the Sydney based location I tested.

      Of the 6 TLD servers for the .org domain, 1 of them will reply from east coast Australia, and another 1 will reply from a nearby location that's ~55ms away (which could mean, for example, Singapore), so we'll give that a half point. Upon trying a random name server for an unknown .org domain there is a 1.5/6 (or 1/4) chance it will return quickly.

      Testing I did of time to resolve .au vs .org backed this up: the return times for uncached domains varied because the DNS server tested chose nameservers randomly. But lookups for .au domains averaged 203ms (12 trials) and for .com domains averaged 278ms (12 trials). As I discuss below, this can potentially become much faster when using a busy DNS server (one with a well-primed cache).

    • A busy recursive DNS server running something like a recent copy of BIND will cache the RTT (return trip time) for various nameservers and will favour the ones that have previously returned fastest. This is good news, but for this to work well it has to be a fairly large traffic DNS server. The RTT information for a server is decayed over time and discarded when it's either 30 minutes old or when a certain number of queries to the faster servers has completed. To "prime" this RTT cache well requires dozens, or hundreds, of queries for different domains (so that you hit every ?.gtld-servers.net nameserver, every ?.au nameserver, etc at least once). To keep it primed would therefore require dozens or hundreds of queries per half hour.

      A typical pair of recursive DNS servers for a large ISP should do pretty well at this.

    • It's not just enough to get the result from the TLD server - that just refers you to the domain's own nameservers. Then you have to query those too. And if there's no glue records at the TLD servers (which there won't be if, for example, your domain is example.com and your name servers are ns?.example.org), this requires a whole new DNS lookup all over again for the name server address.

    When I initially did this test I was surprised at how many of the .au nameservers replied in > 190ms (indicating that they were almost certainly in the USA).

    • 6