How much does a TLD affect your Web Application performance

 Aug 07, 2023  devops  Twitter  GitHub  info@caci.co.uk

Time was the Internet consisted of just 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 even some brands 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?

We'll investigate how we replatformed 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

(Yes it's a pun, yes we're proud of that if you got it. Yes, we are hiring...)

DNS - or Domain Name System - is an often overlooked part of the Internet today, but is very much a key building block to the rest of the Web. Before we can discuss why differing TLDs have impact on 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 automagically 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 made up 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 - for the Organisation's self-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 Server

The level of a Name Server within the hierarchy determines the amount of information it returns, and normally the higher the level (towards the root), the less information it gives (is just likely to 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 ultimately 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 numerous 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. Here caching plays a role 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 equal - as it turns out, not everyone is as passionate about DNS Performance optimisation as internet society organisations such as the IETF are.

Sometimes Root DNS is three quarters of the response time

Please, take a seat - it shocked us too. 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 awesome 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.

"Surely it's just us, surely other domains aren't affected as well?"

"It can't... you can't... five-HUNDRED-milliseconds?"

"You're making these quotes up just to make the Blog sound more plausible? I can't believe you'd do such a thing!"

So the journey began. Using the IANA Root Zone Database, we undertook the following not-really-that-scientific process to check if 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's 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, really fast at doing things

Clearly this isn't taking into the account the following:

• DNS Anycast affect on Root Name Server choice and availability
• DNS Anycast routing affect on geographic location
• DNS Recursion Chain affect on lookup Client (in reality an ISP, CDN, Cloud or dedicated DNS Name Server)
• DNS Caching of lookups (in reality an ISP, CD, Cloud or other downstream DNS Resolver will cache responses for a time)
• Appeasing the DNS Gods with your latest incantation...

But 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 impact this. Turns out it's not just SEO that can be impacted by TLD choice.

Need help with your own three-part DNS Murder Mystery?

At CACI Network Services we're well practiced in going full-blown Poirot on a variety of DNS, Network and Cloud murder mystery investigations. We've completed so many we think we're in for a shot with being the guest stars on the next Midsomer Murders.

In the meantime, if you'd like us to keep go all Pink Panther on your very own Infrastructure Conundrum, we're all (pink) ears - get in touch and let us help you go from Inspector Clouseau to clue-solved.

And whatever you do, don't start humming the Pink Panther theme tune in your head, you'll never get it out... Sorry. No really. Sorry.