How much does a TLD affect your web application performance?

There was once a time when the Internet consisted of only a few top-level domains (TLDs) – .com, .net, .org and a few others – but not anymore. TLD-List reports there are now over 3,745 domain extensions and growing, with some brands even having their own organisation extensions such as .barclays and .bbc in use for careers sites, product pages and more.

As well as their obvious and well-documented impact on SEO, did you know they can also negatively impact your website performance – particularly on load times and TTFB?

In this blog, we’ll uncover how we re-platformed some of our web assets to overcome an issue with SEO performance we didn’t even know we were having.

Background on the roots of DNS

DNS – or Domain Name System – is an often-overlooked part of the Internet today, but is very much a key building block for the rest of the web. Before we can discuss why differing TLDs impact performance, it is useful to have some grounding in DNS concepts first.

At its heart, DNS is a tree hierarchy – with an invisible dot as the mandatory root. At a base level, the main job of DNS is to resolve a domain such as www.google.com to an IPv4 or IPv6 Address such as 8.8.8.8 for TCP/IP to start the packet connection process to.

Let’s explore this with the well-known subdomain calendar.google.com. Firstly, although you don’t type this with the suffixed dot (.), it is very much there. Don’t believe us? Try this in a command prompt:

ping calendar.google.com.

Here’s what we get:

ping calendar.google.com.

Pinging calendar.google.com [142.250.180.14] with 32 bytes of data:
Reply from 142.250.180.14: bytes=32 time=7ms TTL=119

Ping statistics for 142.250.180.14:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 7ms, Average = 7ms

ProTip: Ever tried to ping or nslookup something external like website.com only to have the result come back as website.com.internal.corp.acmeco.local on you? Same difference– Windows commands like nslookup assume everything is a subdomain of your DNS Suffix Search List if you don’t suffix a “.” (dot) at the end. Most applications like web browsers automatically do this in the background for you; much the same as they silently add:443 to the end of HTTPS websites.

If we deconstruct calendar.google.com, and process it right-to-left from the perspective of the DNS tree hierarchy, it’s composed of:

• Root – . (invisibly added in)
• Top Level Domain (TLD) – com
• Domain – google
• Subdomain – calendar

The hierarchy is important because each layer informs which signpost needs to be used for the IP Address Lookup up the tree. Name servers (or “NS”) are used to act as the signpost for domain name to IP address resolution. There are two main “types” of name server (DNS Purists will come for us – we know, we know…):

Root Zone (Internet Bodies)

• Run by organisations similar to IANA and ISC for the good of the wider Internet itself, as a going concern

DNS Zone (Registrars and Organisations)

• Run by either Domain Registrars such as Namecheap, ISPs and CDNs such as Cloudflare or end user organisations themselves – out of the organisation’s own interest

This distinction is important when it comes to the level of detail signposted by a given name server at any given level of the DNS hierarchy.

Function of a name sever

The level of a name server within the hierarchy determines the amount of information it returns.Normally, the higher the level (towards the root) gives less information andis likely to only signpost to another name server with the detailed IP information. Using the same example, let’s see this in practice with the same calendar.google.com example and walk through the hierarchy:

As can be seen, the function of each upper-level of the hierarchy is to point to another signpost element lower-down in the hierarchy that knows the IP address answer. The reason for this is scaling – it wouldn’t scale to have a flat hierarchy of all the 628.5 million registered Domain Names in the web, let alone the many hundreds or thousands of subdomains each of those could have.

In practice, the client rarely probes the actual authoritative DNS resolver for a given DNS zone, usually the DNS recursion chain is such that a client resolves against a caching DNS server run by their downstream ISP, CDN, Cloud or other DNS provider. Caching plays a role here to offload lookup stress on the DNS ecosystem; the above example is simplified to show the concept in isolation of the impact of DNS optimisations such as DNS caching and Anycast.

The famous thirteen

You may have been around the Interwebs long enough to have heard of the infamous “13” Root Servers which effectively act as the name server phonebook for the original TLDs such as .com and .net, and are currently:

As it turns out, these aren’t the only root name servers in town; there are an ever-increasing set of root servers to support the ever-increasing amount of TLDs proliferating today, as recorded by the IANA Root Zone Database.

What’s more, these aren’t all created equally – as it turns out, not everyone is as passionate about DNS performance optimisation as internet society organisations like the IETF are.

Sometimes, Root DNS is three quarters of the response time 

We were looking into why the response time of some parts of our previous Job Board cacins.careers were so bad and had just moved from using cURL commands into the ReqBin REST Testing Tool when we spotted the above. Assuming no DNS caching in play, of the 668ms response time, DNS resolution took up a shocking 509ms – or 76% – of the entire HTTP GET process.

So, the journey began. Using the IANA Root Zone Database, we undertook the following process to confirm whether it was indeed just us:

1. Collate a bunch of TLDs operated by differing TLD Managers
2. Perform a DNS lookup to their associated root DNS server from the IANA Root Zone Database
3. Measure the time of this lookup in Windows using powershell “Measure-Command { nslookup domain.tld. root.tld.server.tld. }”

i.e. For fast.com this command was: powershell “Measure-Command { nslookup fast.com. a.gtld-servers.net. }”

Here are our quasi-scientific results:

We only picked the fast domain because we thought it would be most likely to be registered across a selection of some technology-related TLDs and not give a false-positive with a NXDOMAIN response. Also, maybe we want you to think we’re really fast at doing things.

Clearly, this isn’t accounting for the following:

• DNS Anycast effect on root name server choice and availability
• DNS Anycast routing effect on geographic location
• DNS Recursion Chain effect on lookup client (an ISP, CDN, Cloud or dedicated DNS Name Server)
• DNS caching of lookups (an ISP, CD, Cloud or other downstream DNS Resolver will cache responses for a time)
• Appeasing the DNS Gods with your latest incantation.

However, it does give some food for thought on the impact that a seemingly invisible part of every web app request – the DNS lookup – can have, and how such a low-level component such as choice of TLD can affect this. Turns out it’s not just SEO that can be impacted by TLD choice.

How can CACI can help you

At CACI, our Network Services team are well-practiced on a variety of DNS, Network and Cloud systems. If you have any enquiries into how we can assist on your infrastructure issues, we can help.