If you hadn’t heard of time-to-live known as TTL, you might feel it is the kind of term that spells out some sort of ending. And you’d be right. In computer networking, TTL settings are in many places and impact lots of services but the main function is to end an instruction. For this article, we are going to talk about the TTL settings that instruct your website Domain Name Servers (DNS) and later on, how TTL impacts Content Delivery Networks (CDNs).

So What is TTL?

TTL is a setting placed on all Internet Protocol packets in the form of a numerical value to limit how long the packet ‘lives’ inside the Internet transmission system. This number value is known as the hop limit.

If we start with the DNS and how the TTL hop limit works within it, we can see how TTL has a direct impact on how fast your website will load. 

If you own a domain with the view to operating a website, you'll know your DNS helps people get your website up on their devices. How fast a DNS can do this is measured in TTL hops. The more hops, the longer the time it takes to load your website.

Your website makes many hops as it travels towards each person's device. But there's a limit. The first thing to learn is that TTL is always a number value. In this case, usually somewhere between 0 and 255 hops.

The ‘hop limit’ is the technical term describing what happens between the time your website sits on a hosting server and begins its life and the amount of hops it can take before it runs out of hops, reaching a limit and ceasing to live. If we go for 255 hops, the website can travel to 255 servers and hop from each one before the website arrives on a person’s device.

At this point you might think ‘well, why are we stopping the hopping?’ And the simple explanation is TTL is a way to safely stop unusual DNS ‘looping’ activity (when hops exceed 255) which they may do if your website DNS is under attack — more on this below.

How Does TTL Work?

Your authoritative domain server holds all the current website records which make up your complete site. When the DNS website records begin their journey and start to hop, they are visiting resolver servers which verify your website name and all the content on there (or packets). There are many servers involved in this process. The TTL count subtracts 1 from the TTL number each time the records query any server, which can be as high as 255. The records continue to travel the Internet infrastructure, through many servers, to a destination client (or workstation in the diagram above). 

If the TTL count gets to 'zero,' this would mean the information has traveled across 255 servers. Unfortunately, if this happens, the requested 'packet' is automatically discarded. Or no longer 'lives.' This is called TTL expiry and if you were requesting a website you would see a message saying ‘website not found’ in your browser.

An example of a TTL expiry message indicating an error and the connection has “timed out” because the domain name track.namecheap.net “took too long to respond”.

TTL and security from DNS DDoS attacks

Now that the web is truly worldwide, TTL is the way to stop website name requests for DNS records endlessly circling (hopping) server networks. Allowing infinite queries would be a bit like running your electricity and then never turning a switch off.

This query circling is also known as 'looping,' which is expensive. It causes servers to get busy, 'overload,' and then become vulnerable to information hacks. TTL can mitigate the time allowed for the ask and re-ask, or hops permitted to query the DNS server, thus protecting your uptime.

Information is what hackers are after, so they design attacks on the DNS layer of the Internet. DNS query attacks, more commonly known as Distributed Denial of Service (DDoS), make a server busy asking and re-asking for your website name to be resolved (a DNS resolver forwards query). 

TTL and paid-for DNS services

To best understand how a paid-for DNS service uses TTL, let’s look at how Namecheap's PremiumDNS guarantees 100% website uptime. For a moment, think about your DNS service as similar to the postal service.

When using the postal service, you don’t want people to:

·  read your private letters;

·  deliver your letters wrongly;

·  or lose your letters.

Premium DNS using TTL:

·  encrypts information as it travels;

·  puts TTL limits on 'delivery' times;

·  and securely deletes information if the TTL runs out.

PremiumDNS sets TTLs to protect your website against DNS DDoS attacks known as 'deeper-layer' attacks because they target the 'delivery' or transport system layer of the Internet. TTL is a way to identify unusual DNS activity. PremiumDNS actively mitigates any DDoS attacks by helpfully distributing your website to an alternative server when the TTL runs out. 

So TTL times give a finite value to 'hopping' or traveling website ‘packets’. Think of this as a timely 'DNS records refresh.' No more endless hopping and looping, yet, your web visitors get the latest refreshed website faster because their DNS query never gets stuck in the system.

DNS records on the move — SOA TTLs

A SOA (Start of Authority) record is a type of resource record in the Domain Name System containing administrative information about the DNS zone, especially regarding zone transfers.

Things are not quite so simple each time there's a journey' hop. Because the Internet is a dynamic place, there are five Start of Authority (SOA) record journeys with their own TTL times which could impact your website's journey.

1. SOA TTL – To get the name of your website, there's an interval time when the SOA record refreshes.

2. Refresh TTL – To make sure visitors see the latest version of your website, this is the interval at which secondary servers (secondary DNS – closer to clients) check with the authoritative name server.

3. Retry TTL - The number of times a secondary server will retry to refresh the data from the authoritative server if the refresh in step 2 has failed.

4. Expiry TTL - If Refresh and Retry fail a certain number of times, the current records become no longer authoritative for the given zone, and the records' die'.

5. NX TTL - If requesting the domain results in a non-existent query (NXDOMAIN), which can happen if DNS hosting servers don't have a record for your domain name, this NXDOMAIN response will be cached for a specified number of seconds.

The DNS resolver forward query process involves all of these TTL settings. As your website DNS records travel along to the client workstation, it’s a bit like every time there's a hop, these five settings are active, and some of them reduce by one (when appropriate).

Standard-Times for DNS TTL

There are a few ways people can set DNS TTL values, but it's not wise to change them unless you have a specific need. The standard times for DNS TTL are between 1 and 255, though not many would go below 30 hops.

TTLs provide security against hacking by minimizing the amount of time expired website information is cruising the Internet. Think of this as especially pertinent if you handle e-commerce transactions and personal data through your website.

CDN, DNS, and TTL Traffic

If a server is experiencing multiple and simultaneous requests for your website content, CDN systems, like Namecheap's Supersonic CDN, work hard to get around traffic spikes to speed up your website performance.

To combat slowdowns, CDNs optimize content using intelligent applications. Known as server load-balancing, algorithms measure and then divert HTTP (HyperText Transfer Protocol) content by pushing it in a forwards direction to the next closest server by geo-location. All of this is regulated by CDN TTL times for what we can think of as content ‘hops’. Content will hop to servers with spare capacity.

"The key difference between CDN and DNS is when we talk about CDN, we talk about website content, and when we talk about DNS, we talk about website records."

The main benefit of a CDN is to deliver your content more efficiently, even when a server goes down. Why does a server 'go down'? One way, we've already learned about, is when its DNS will not respond because of DNS forwarding query congestion, which might be a DDoS attack.

Remember, DNS queries travel the same servers as your website content. When under a DDoS attack, the server prioritizes DNS propagation. DNS propagation is the process of delivering a new website all over the world's servers. When under attack, a server thinks it has to keep doing this, which is a longer and more challenging process for it to execute.

Now, extra busy, out of need, it will reduce HTTP (HyperText Transfer Protocol) traffic reaching that server. HTTP delivers your website content using the top application layer of the Internet (layer 7) and is regarded by the server as less critical. After all, you can't display content without a website? Right?

This auto-defense slows your content traffic down and can stop it altogether during a DNS DDoS attack. If you use a CDN service which places hops into your content packets, and then is able to smartly re-direct your content, you won’t experience any service disruption (unless the hacker is extremely, genius-level clever).

Significant slowdowns caused by content-type DDoS attacks concentrate on making the target server endure endless HTTP requests for content. This won't bother the server, which is mainly concerned with DNS delivery. So it would be best if you had a CDN to act, and one of the ways it does this is to divert your content to another server.

This diversion technique takes microseconds, which means your content is still delivered everywhere — super fast.

As soon as the CDN identifies the attack, the CDN diverts the content, making a hop, reducing the content TTL by one or more.

A CDN system benefits your website by instructing your content to neatly 'leapfrog' over any stuck servers.

By now, you must be wondering why a Content Delivery Network (CDN) is something you have to buy? Shouldn't it be built-in? To explain this, I must go further back in time.

The DNS Records System

The DNS system was initially designed in 1983. Yet, DNS security and content delivery wasn't something anyone had worried about in the eighties. The networked users were trustworthy defense-types and academics who would never dream of hacking or damaging their own user experiences. Yet, they were struggling with remembering numerical addresses, and the DNS system resolved these into easy to remember names — a bit like making an internal phon e book.

The CDN System

Fast forward to the nineties, and CDNs come into existence. But why?

Due to a needs/must dilemma, users surfing the Internet increased to such a vast number that DNS TTL hops between institutions got jammed up in places. More users meant more content.

This congestion caused individual servers to go down due to zone apex node failures. Think of these nodes as busy traffic light intersections on the internet highway, leading to major routes. The architects of CDN quickly realized that if an important website, also called ‘mission-critical’ websites (or websites that need to be on all the time — or else) went down, something needed to be done to solve this cause for concern.

How TTLs affect DNS and CDNs

It was clear a content solution was needed to free-up those busy nodes and ensure content delivery. The Content Delivery Network was born.

The resulting CDN is a technology that has delivered two great innovations. Firstly, a CDN stores all of your website on global Anycast servers (which is how Namecheap's Supersonic CDN does it). When someone requests your website, they just get the updated content refreshed, and — you guessed it — time-to-live settings exist to keep refreshing your website copies.

It's a bit like the global Anycast server network anticipates HTTP content requests and pro-actively stores your website content. A CDN will look for the most up-to-date version of your website because the content is stored at several geo-locations. This avoids some international node congestion.

The second innovation happened when those CDN inventors thought about what happens when you update your website with a new content element of any kind. What if you could deliver only the new bits of content to all the copies of the website sitting on the international servers? Instead of reinventing the whole thing?

This makes for a smaller, thinner content packet. Busy zone apex nodes are less likely to clog up the highway and the tiny packets get past. Your visitors get all your website content faster because very little stops the packets.

The TTL settings for these tiny packets (or your content refresh) is part of a CDN process known as content caching. Think of your website in its entirety. It's full of software, pictures, text, styles, videos, — whatever you want to put on there. What happens if you store (or cache) copies in a stationary way, all over the world? 

You save on delivery time for one. The website is now sitting closer to its users, so fewer delivery hops are required. Faster delivery – guaranteed!

TTL & CDN New Content Caching

Now add in the idea that you can slow down how often your website copies look for newer content from your host/home/origin server, and this is how TTL works in a CDN.

·  You can set a higher TTL for content update searches. When you are happy to let your website exist in a still or static way for a longer time and not update it that often.

·  You can set a lower TTL for content update searches when you want to make many changes and get them out there quickly. (But this will enlarge your packet – but only for a short while when you make the content changes).

·  Alternatively, you could have a very dynamic website and need to make content changes all the time. Then, you would set an even lower TTL because your content updates are crucial or mission-critical.

In a way, a CDN helps important dynamic websites stay functioning faster (like banks) while less content-dependent sites (like blogs) take up less node space when new content is pushed out and over the server network. But both get faster service.

Remember, when a server goes down, you won't know what is causing this unless you follow the Service Announcements on your hosting provider's website. Attacks are out of anyone's direct control — that's why they are 'attacks.' By having a CDN service, your content TTL settings ensure your content is still getting pushed out to your website audience even when there are server failures.

You can even be looking at your hosting server as down, but everyone worldwide can still see and use your website.

CDN, DNS, and TTL Working Together

Your CDN TTL does not affect your DNS TTL, but they do happily co-exist. Your DNS TTL impacts how many times someone can request your website's latest copy by its name, not what they see when they get there. DNS TTL stops looping lookups or endless hops, while a CDN TTL reduces the time and energy needed by servers to deliver up-to-date content worldwide. This helps everyone to have a safer and guaranteed internet viewing experience.

Hopefully, you can see now why DNS TTL is an essential part of website security and has its own ICANN protocol for that reason. It does mean a DNS service provider needs to make the DNS instructions included in every packet delivery header raise the alert if there’s suspicious activity. This makes requests safer for all of your website users, from the very start.

CDN TTL is more like a content safety system, using algorithms and code to help your content get somewhere on time. Because you rent space on global servers from a CDN provider, your website gets delivered, even if there’s a HTTPs attack, or the DNS layer throws up an obstacle.

Why you need a paid-for CDN and DNS service

As soon as DDoS attacks appear, both services together keep your website up and running and cause the measures described in this article to kick in most efficiently. CDN and DNS services are the best ways to guarantee uptime, run your IT infrastructure more efficiently, and not wear out your on-site servers and switches. You also pay less for hosting bandwidth (because CDN packets are smaller). You can go it alone, but unless you have your finger on the TTL trigger any time a DDoS attack comes at your website, you risk your website going down or your content getting stuck.