Understanding DNS propagation.

Technology is the keystone of modern life. It has made many things easier! It has also accelerated many processes and daily tasks to the point we humans now expect everything to happen at light speed. Today, waiting three seconds can be a reason to abandon a web search or a website because that feels “too long”.

The reality is, massive processes, even with advanced technology involved, still, require much more than milliseconds to be completed accurately. Like DNS propagation!

What’s DNS propagation?

DNS propagation is the time period that it takes to update DNS modifications across the Internet.

Why should I need to modify DNS records?

The regular maintenance of your network or online business demands DNS modifications. Of course, the amount and frequency differ based on the kind of business. But to add, edit or remove DNS records is a common task for administrators. Every time they have to route the e-mail, redirect visitors to any subdomain, modify IP addresses, TTL (time-to-live) values, etc.

How does DNS propagation work?

When you modify a DNS record (or more), you have to make it on the authoritative DNS nameserver. But a network includes not only a server but many of them to comply with different functions. So your modifications got saved in the authoritative nameserver, but there are many recursive servers distributed globally that have to be updated. Otherwise, they will keep serving the previous copy (outdated) of the DNS records. Remember, all recursive servers save a copy of the DNS records within their cache memory

Clearly, the goal is for the new update to be available worldwide. Until DNS propagation gets completed, the goal will be achieved.

How long does it take for DNS propagation to be completed?

Usually, DNS propagation takes from 24 hours to 72 hours to be completed. This is an approximate time, but it can take less or even more! Basically, because there are extra factors that can make this process faster or slower. In any case, you can be sure that this is not about milliseconds. Better be patient! 

Which factors can affect DNS propagation?

  • DNS modifications on a high DNS level (hierarchy) take longer. 

The TTL for TLD and root servers is usually defined with higher values, 48 hours, or even more. This is a common practice used to avoid stress on these servers due to high demand. 

For instance, if you change the authoritative nameserver of your domain, meaning the server with your original DNS data, this is not a minor modification. You must change it on the TLD level by communicating with the domain registrar. DNS propagation of such a change will definitely take longer. 

  • TTL of the DNS records.

Recursive servers keep a copy of the DNS records, the time the TTL set on those records allows. Until the TTL expires, recursive servers will keep the old copy. Therefore, full DNS propagation depends on those TTLs.

  • TTL of the ISPs’ servers.

For Internet service providers to set higher values (TTL) on their servers is convenient. They can make the traffic more agile and optimize their resources. This can delay the DNS propagation until the TTL on the ISP servers expire.

  • DNS cache on users’ devices.

Devices save (cache) DNS records of the websites accessed by the user. This information remains cached for the time defined by the TTL. An update could happen after the records expire. 


Understanding DNS propagation is vital to know how to influence this process in your favor. With the fast pace technology advance, one day, this will happen quicker. But meanwhile, be patient! 

DNS spoofing – How to prevent it?

The creation of the Domain Name System (DNS) in the early 1980s was a big achievement. Its design considered a vast functionality, but security was not a priority almost four decades ago. The problem is that criminals knew it, and soon they took advantage of this weak point. Criminals developed different attacks using the DNS, like the dangerous DNS spoofing. 

What is DNS spoofing?

DNS spoofing is a hacking attack. Criminals enter spoofed or forged entries or DNS records into the cache of a recursive server to respond to DNS users’ queries with a spoofed record, for instance, a forged IP address. This way, legit traffic is maliciously directed to dangerous destinations (forged websites). Once there, users can be pushed to type sensitive data (passwords, bank card details, etc.) for criminals to take advantage of later.

How to prevent DNS spoofing?

Almost forty years have passed since the DNS creation. Attacks have become more harmful. And with the migration of more offline services to the online world, users’ sensitive data are strongly at risk every day. As a website owner, to protect users’ security is essential not to lose trustability and clients! 

Monitor and Filter the DNS traffic exhaustively.

Currently, different software alternatives for scanning all data received are available. Data are not sent unless they pass through this scanning. If the software detects something wrong, data will be stopped.

Filtering has proved to be an efficient method to detect attacks. There are different solutions on the market. Quality ones offer two-way traffic filtering at different levels like DNS, HTTPS, and HTTP.

Protect your DNS by adding DNSSEC.

DNSSEC or Domain Name System Security Extensions verifies the authenticity of the data. This suite includes digital signatures, advanced cryptography, and more methods for validating answers to domain name requests. DNSSEC makes sure that malicious redirections don’t happen.

Encryption is an efficient tool for protecting DNS data integrity, meaning DNS requests and answers. Encryption involves the use of two keys, a public and a private one. Without the private key that is in the hands of the website’s owner or administrator, criminals can’t sign their spoofed DNS records. Even if they manage to enter them into the cache, those forged records won’t be validated by the public key.

Patch regularly your DNS servers.

Not only endpoints but servers also have vulnerabilities that can be fixed by patching them. To keep patching up on time can save you problems. There are tools for automating this process. 

Prove if the authoritative name server matches what is locally answered.

In the past, many requests needed validation of their PTR (reverse) records. But the practice has become rare. The advantage of this validation is that if the authoritative name server gives a different answer than what is locally answered, the DNS packet gets an invalid mark. TCP/IP protocols can see this and be aware of the spoofed packet, not to allow it. Unfortunately, this doesn’t work yet for HTTP requests.

Users also can prevent DNS spoofing. Remember, their sensitive data are the main target of criminals.

  • Use VPN (a virtual private network), especially if you will send sensitive data. Public networks are too risky. 
  • Look for security and authenticity signs on websites before you type any data. The padlock symbol on the address bar is a good beginning.
  • Avoid strange links. Not clicking blindly can save you from dangerous traps.


DNS spoofing is a big threat for website owners and users. Security technology and safe practices are a good combo to prevent it!

What is the role of the Recursive DNS server?

We could talk a lot about DNS functionality, however, let’s concentrate at the moment on one major DNS component, the recursive DNS server. 

Recursive DNS server explained.

The Recursive DNS server is responsible for searching for data that is required for answering the queries of the users. Recursion in computing is associated with a method for solving a problem. That means a program or solution is going to repeat itself until it reaches the goal.

The recursive server operates between the authoritative DNS server and the end-users that make the requests.

Every time a user wants to visit a website, it requests its domain name, and the recursive DNS server is the one seeking its IP address (IPv4 or IPv6). Once the recursive server gets the required IP address, it goes back to the device (browser) of the user that initiated that request the first time. Then the laptop, smartphone, or whatever device is using the user receives the information, and it is able to connect to the IP address and load the website.

Types of lookup

The recursive DNS server could complete the lookup for the information in two different ways.

The first type of search needs a more extended period of time to be performed. This is because the recursive server has to go through a long path to get the wanted data. First, it reaches the root server, next to the TLD (Top-Level-Domain) server, and lastly to the authoritative DNS server, which provides the answer to the query. 

For that reason, the recursive server has only one goal – to search for information.

The second type is the easier and quicker path. The recursive server is able to get the IP address from its cache memory. For a certain amount of time, this server can store the data in its cache. The administrators can set for how long by the TTL (time-to-live) value. 

When the user makes a query, the recursive server will first check for the IP address in its cache memory. The query finds its answer if the data is still available there and the TTL has not expired yet. That is a great advantage because the response is quick, and the recursive server doesn’t have to look further in other servers.

DNS cache poisoning attacks and Recursive DNS server

It occurs when the recursive DNS server seeks an IP address from a different DNS server. The cybercriminal stops the request, and instead of the accurate data, the attacker gives a fake answer. Usually, it is an IP address pointing to a malicious website. That is how the DNS cache poisoning attack is completed.

The issue is not just that the recursive server provided the user with a fraudulent IP address. Further, the server will save the answer on its cache, leading to a significant problem. Each user who wants to visit that website is going to receive the fraudulent IP address and enter the malicious website. Such an attack could affect a lot of users. 

3 common usages of FQDN

What is FQDN?

Fully Qualified Domain Name, or for short FQDN, presents exactly the complete name of a specific domain name. Moreover, that applies to servers too and not only to websites. The Domain Name System (DNS) is built and organized hierarchy. It begins from the top level that is the root, followed by the TLD, a level below is the domain, and finally, the last level is the particular hostname.

To make things simple, let’s see the complete syntax of a fully qualified domain name (FQDN):

hostname. domain name. TLD 


Here are some examples of a fully qualified domain name that you probably have seen:




Keep in mind that the dot “.” that is last in the syntax is commonly neglected. It simply represents the root level. Typically the FQDN ends with the TLD. Yet, there are some cases where that dot is required, and you are going to need to add it. Also, it depends on the software you are currently applying.

With a Fully Qualified Domain Name, you are able to see where exactly an object exists in the hierarchy of the Domain Name System.


The Fully Qualified Domain Name has 3 main components. They are the following: 

  • The first component is the TLD (Top Level Domain) – It is described with the extension in the end that you can view in an FQDN. Usually it includes 2 or 3 letters, for instance .com, .eu, .net etc.
  • The second component is the subdomain – You can see it as the domain one level below the Top Level Domain (TLD). For illustration, domain.com.
  • The third component is the hostname – It is described with the signs located at the start of the Fully Qualified Domain Name. A simple and very familiar example is www in www.domain.com. The domain owner could create various hostnames as they are connected with a subdomain. For illustration:
    • mail.domain.com
    • www.domain.com
    • ftp.domain.com

Use cases of FQDN

  1. If you want to get an SSL Certificate – Almost every site has one, and you need to provide the FQDN to receive it.
  2. If you want to connect to a host remotely – The Fully Qualified Domain Name is a requirement when you want to connect to a remote host. That means that it isn’t local to your ISP.
  3. If you want to access a specific Domain Service or Protocol – The FQDN is required, for instance, when you want to establish email for particular applications.

What is PQDN (Partially Qualified Domain Name)?

The Partially Qualified Domain Name, or for short PQDN, is a Fully Qualified Domain Name, simply with an absent part. It does not contain all of the components, which give the exact position on the DNS hierarchy. To make things more simple, for instance, a PQDN is google.com. The reason for that is there is an absent web host (www.) before the domain name. 

Everyday users usually apply PQDN because it is more accessible and easy. Besides, it is shorter, which makes PQDN more simple to use.

DNS cache: Why should you care about it?

What is DNS cache?

The DNS cache is a mechanism for storing the DNS data of previously queried domain names. Different devices, such as DNS recursive servers, mobiles, computers, and tablets, have such cache memory. It has a specific purpose: to reduce the time for resolving a domain name. Thanks to it, the DNS recursive server is not necessary to perform a complete DNS lookup every time a particular domain name is requested.

The DNS information that is kept in the cache memory includes the various different DNS records, such as A record of a specific domain name and the corresponding IP address. However, the data is stored temporarily only for a specific amount of time. Therefore, it is estimated through the TTL (Time-To-Live) value of the DNS records. Once the TTL expires, the DNS resolver will have to perform a new DNS lookup.

Let’s take, for instance, a news website that you visit every morning. The first time you want to visit that specific website, a DNS lookup is completed for the needed IP address. The DNS recursive server receives the IP address and saves it in its cache. The next day, when you type the domain name of your news website, it is going to be a lot faster and easier to load. The reason is the DNS cache that keeps the IP address. Also, a new DNS lookup is not required. 

It provides responses to DNS queries of the users faster and optimizes the resources efficiently. DNS recursive only makes the absolutely necessary lookups. 

You should you care?

DNS cache is very useful, and unfortunately, cybercriminals are well aware of that. They have found and established a way to take profit from its functionality.

The attackers manage to perform DNS poisoning by inserting fraudulent IP addresses or domain names. That way, they direct the user to a malicious website that is very similar to the original one.

Technical issues or administrative errors could corrupt the DNS cache. Yet, often if something like that appears, it is a sure sign for criminal activity in motion. So, to prevent this risk, it is a good idea to flush the DNS cache regularly. 

How to delete the DNS cache?

The process of deleting the cache depends on your OS and your browser that could have different separate DNS cache. 


  1. Open the Terminal. Then type the following command – sudo killall -HUP mDNSResponder
  2. Next, write your password and press Enter. Ready!

Linux (Ubuntu 20.04 LTS)

  1. Open the Terminal. Then type the following command – sudo systemd-resolve –flush-caches. 
  2. Next, write your sudo password and press Enter. Ready!


  1. Start the Command Prompt or Windows PowerShell. Then type the following command – ipconfig /flushdns.
  2. You have to receive a confirmation message. The DNS is now clear.


  1. Go to “Preferences” and next “Advanced.” There, in the menu bar, search for “Show develop menu.” 
  2. Next, find “Develop” and then “Empty Caches.”
  3. Now, just restart your browser. You are ready! 

Google Chrome/Edge/Opera

  1. Copy this text – chrome://net-internals/#dns. 
  2. Paste the text inside your address bar. Then press Enter.
  3. On the page you see, search for “Host resolver cache” and click on “Clear host cache.”
  4. Ready!

Managed DNS: Take your performance to the next level

Let me tell you a real story. I had a blog, which had no additional DNS service and was using just the name servers of the domain registrar, and I was using a regular shared hosting. You can imagine that neither the domain resolution speed nor the web hosting was great. I am experiencing the bad consequences of people clicking and not waiting for my site to load, leaving it faster than expected and not satisfying positioning on the search engines’ rankings.

The blog was loading in 20-30 milliseconds from the continent (Europe), where the servers were, but around 200-300 milliseconds on all of the rest (North America, South America, Australia, Asia, etc.).

I was losing many visitors until I started to use a Managed DNS!

The Managed DNS first brought speed, but many more features too, that improved the visitors’ experience greatly. Here you can have my observations:

Boosted speed.

Yes, you can imagine that a paid Managed DNS service will bring significant improvement when it comes to domain resolution. First, get a plan with name servers located as close as possible to your biggest audiences. Like that, you will shorter the route of the DNS queries and speed the process up. With a good provider, your domain could be resolved in less than 10 milliseconds! 

Load balancing for better performance.

Not only that the speed will be better, but also you can enjoy the advantages of the load balancing that many Managed DNS services offer. The queries can be managed between the name servers and provide better performance and, most importantly, redundancy. Even if some of the servers are down, the visitors’ queries can still be answered from another of the working DNS servers. So, thanks to the load balancing, you won’t miss visits, leads, and conversions, just because your domain was offline.

No overspending.

Yes, you can rent several dedicated servers or virtual private servers and use software like Bind 9, to manage your domain on your own. But this could be hundreds of times more expensive than what a Managed DNS plan can offer. And you don’t need to think about software support because it is a SaaS (software-as-a-service). All the support, hardware and software, are the responsibility of the DNS provider.


Related to the previous point, you can also benefit from cloud DNS providers’ scalability. You want more resources, then you just pay and start using them in a matter of minutes. No need to set up whole OSes and software. Click a few times, perform a zone transfer, and you have another Secondary server up and running.

Top-notch security.

If you haven’t managed a server on your own, you might not know how much pain in your rear end is to secure a server if you use a DNS provider, all that responsibility and weight fall on it. You will get all the benefits of a good firewall, smart monitor of traffic, DDoS protection, and automatic triggers. I can’t really express myself how much time and effort not having to worry about security helps your business.


Having a Managed DNS took that blog to the next level. It was a significant and visible improvement. Sure it costs, and maybe it is an expense that you don’t want to add in the beginning. But when your site starts growing, it is a must-have DNS that will boost your overall performance.

Use DNSSEC to boost your security.

As you know, the Domain Name System (DNS) infrastructure is the soul of pretty much everything on the Internet. There’s no web hosting, e-mail or messaging services, etc., that can exist online without the DNS.

And being that important, yes, the DNS has its Achilles heel: security. Its focus is not there, and that makes it vulnerable. But don’t worry, DNSSEC already exists! A reliable choice to boost security!

What is DNSSEC?

DNSSEC or Domain Name System Security Extensions is a suite of extension specifications for encrypting DNS records sets and proving the original authoritative nameserver. It’s not about cryptographically signing DNS requests and answers but directly signing DNS data by their owner.

Then, if a criminal (man-in-the-middle) manages to snatch these DNS records, they will be unreadable due to the encryption.

DNSSEC serves for authentication, too, through digital signatures that use public-private key cryptography combinations. Each DNS zone owns its key pair (public/private).

A big DNSSEC advantage is it covers every domain’s level. From the very top, the root, all the way down to the hostname. It builds sort of a chain of trust all across the DNS tree. Every level up verifies the one below through the combined use of the public and private keys. If there’s a failure on one of the levels, the chain gets broken. Therefore data is considered unreliable.

Let’s try an example of the hierarchical digital authentication DNSSEC practices. Think about an exampledomain.net lookup. .Net nameserver authenticates the zone below, which is exampledomain.net

DNSSEC DNS record types.

DNSSEC adds the following DNS records in order to enable signature validation. 

DNSKEY. This record holds the public key that can verify RRSIG.

DS. It’s a delegation signer, and it contains the DNSKEY record’s hash and is put in the parent zone to verify the one under. 

RRSIG. It holds the signature for the recordset.

NSEC, NSEC3. Used for denial-of-existence of a DNS record, and to link to the next secure record.

How does DNSSEC boost security?

DNSSEC boosts your security, providing you with the tools (suite) to ensure that DNS records are not altered. This strengthens your protection and decreases the chances for criminal attempts like DNS cache poisoning. When a criminal manages to alter DNS records on the fly, the client receives them and gets dragged to a different server controlled by the criminal. 

Besides, DNSSEC allows you to authenticate the source of DNS data. By now, you should know about the frequency and different techniques criminals use to attack the DNS. This authentication feature is really significant. To have the certainty that data really belongs to the source they claim to be, meaning to the right authoritative name server, is gold. This reduces the chances of fake servers operating successfully.

If you activate DNSSEC, DNS recursive servers can authenticate data they work with really come from a legit source, so it’s reliable. Fake data will be discarded. And if by any chance the recursive can’t authenticate data, they won’t use them to keep the security. They will retry the authentication process to avoid the use of unreliable or forged data.


The use of DNSSEC to keep the DNS security is a good decision. Online risks and direct attacks to the DNS are not uncommon nowadays. Of course, DNSSEC costs, but you know that prevention always will be cheaper than the cost of fixing the unfortunate consequences of a criminal attack.

A breakdown of rDNS.

Are you experiencing problems with your e-mails? Perhaps they are going to the spam folder or missing. If this is your case, it’s possible that the origin of the problem is that you haven’t configured reverse DNS (rDNS).

What is reverse DNS (rDNS)?

The rDNS or reverse DNS is the DNS lookup of an IP address, with the goal to find the domain name behind it. Yes, it’s exactly the opposite of the regular DNS lookup, in which a domain name points to the IP address where it’s hosted.

The rDNS service usually is supplied by managed DNS providers. Basically, when you get it, you have the chance to create a reverse Master zone. By adding PTR records to this zone, you can verify the correct match between IP addresses and their domain name. PTR records become the evidence you need to prove the IP address really corresponds to the domain name and, therefore, avoid frauds.

The rDNS functions with IPv4 (A) and IPv6 (AAAA). 

What is a reverse Master zone?

A reverse Master zone is a Primary DNS zone on an authoritative DNS server you need for resolving IP addresses to domains. Its creation is a must because it’s the environment PTR records require for functioning correctly.

When a rDNS lookup is triggered, it will travel through the DNS hierarchy like a regular DNS lookup. The difference is rDNS lookups require a specific root domain: in-addr.arpa. Within this domain, subdomains are produced with the numbers of an IP address in reverse. There’s a reason for this: the IP address information is more specific from the left to the right direction.

What is a PTR record?

The PTR or pointer record contains an IP address linked to the domain name. It’s the antithesis of an A record. This last supplies the corresponding IP address of a domain name. And actually, being opposites, they are teammates. You need an A or AAAA record for each PTR you add.

Let’s explain it through an example. When an e-mail is sent, the recipient’s mail server will verify the PTR record to confirm that the IP address corresponds to the domain it says to come from. This is an rDNS lookup. To ensure this match and avoid risks, there will be a second check, but the attention will go to the A or AAAA record.

PTR records are helpful for servers to confirm senders’ identity, for the recipients to trust that the sender’s IP address is not a forged one.

Suppose you wonder what happens when an e-mail server doesn’t have rDNS enabled. Well, they still try to protect security in a basic way. They discard the message or mark it as dangerous. The choice depends on their configuration.

Why do we need rDNS?

To prevent spam. Unwanted messages can be simply rubbish or dangerous threats. They can be looking for advertising or spreading malware, phishing, etc. rDNS can really reduce spam by verifying the IP addresses. If they are legit, rDNS will find it out!

To get easily readable logs. Logging systems register just IP addresses, those long sequences of numbers you perfectly know. Well, with rDNS those numbers can become domain names easier to be read on the logs.

To fix e-mail delivery problems. If your e-mails are going to the spam folder or missing, you can stop these problems by enabling rDNS. 


The rDNS is an efficient solution you should add to enhance your security. So check your configuration and set it up today!

4 DDoS attacks in recent history

The DDoS attacks are devastating businesses all around the globe. They are coming each time more potent and last longer, without any sign of going away. Even the big companies are not safe from them. Cybercriminals have diverse tactics and use different protocol vulnerabilities, extensive networks of bots, and amplification methods. 

Having a large network of DNS servers and advanced DDoS protection was not enough in these 4 DDoS attacks in recent history. Here you can see how bad could it be to receive a DDoS attack. 

2.3 Tbps DDoS attack against Amazon in 2020

The large DDoS attack happened in February 2020, and Amazon’s AWS said it was the largest ever recorded DDoS attack in history with its 2.3 Tbps*. The attack used CLDAP reflection (a known UDP reflection vector) to amplify the attack. Apparently, the cybercriminals used the vulnerability well when you think about the power of their attack. It lasted for 3 days, which is not a lot, and Amazon’s claim that there was no downtime, but still, such an attack can bring down many servers. 

*At that time, the attack on Google from 2017 was not public yet.

2.54 Tbps DDoS against Google in 2017

Can you believe that in 2017, there was such a huge DDoS attack?! 2.54 Tbps is still the record of the strongest DDoS traffic ever recorded. Google came out about the attack long after it happened. Whole 3 years later! What we know about the attack is that most of the traffic originated in China. There were 167 million packets per second that were attacking 180000 targets. Immense numbers! Google says that it had no impact on its services, and there were no negative consequences.

6 Mrps against Google’s client in 2020

Google and people who are using their services don’t have it easy when it comes to DDoS attacks. A massive flood attack of 6 Mrps (millions of requests per second) and 690 Mpps (mega packets per second) happened last year. That was extremely unexpected to see such a massive IoT DDoS attack. What we can see of this case is that in the future, we can expect even stronger attacks with more requests per second and a bigger traffic size. 

Ransom DDoS attacks on the rise in 2021

Did you know about the Ransom DDoS attacks? Cybercriminals target a company’s servers and send massive traffic coming from multiple sources until the servers can’t respond anymore. Typical DDoS attack, but the twist here is that these attacks can last months, and the goal of the criminals is to get a ransom for stopping it. According to John Chambers from JC2 Ventures, there will be at least 65 000 ransom DDoS attacks in 2021. A popular hacking group that is often related to this type of attack is Fancy Lazarus. They ask for between 2 and 5 bitcoins as a payment. Other previous names they used were Fancy Bear, Lazarus, and Lazarus Group.


No matter the size or industry, we are all under constant DDoS threat. What can we do about it? Stop most of them. Having DDoS protection might not be a 100% guarantee for perfect defense, but it is still worth it. Imagine how many small, medium-sized, and even huge DDoS attacks can most of the DDoS protection stop. 99% uptime is a lot better than 90%! And, in case of a ransom attack, be prepared with a backup of your business. Better recover your computers than to pay and not to get a thing in return. 

Best Practices for Setting Your TTL.

Expiry dates, deadlines, waiting, appointments… sometimes can stress you. But time is a helpful tool for efficiently working, complying with processes, and reaching objectives. The TTL is a good example! Learn these best practices for setting your TTL and manage your domain better.

What is TTL?

Time-to-live is the time or the number of hops every data packet is set up for being alive. Either on a network or devices, like a recursive server’s cache memory.

When a data packet already complied with its configured number of hops or its time expires, routers will discard it. In the case of devices, it will be removed from their cache not to use it anymore.

There’s TTL also on the DNS records of your domain. Their TTL points to the time they will be alive and until when the information they hold will be valid.

Why do we need TTL?

We need TTL to control the amount of data packets that exist. For example, have you ever thought about how many data packets travel every minute across a network? Imagine a scenario without an expiry date. Even the first data packet ever sent could be around without purpose, just traveling non-stop.

Time-to-live helps optimize traffic of data packets, identifies if the data they hold are still valid, and allows to obtain information about them too. For example, you can know how long a data packet has been around, and you can track its route. This information is really valuable in a cyber world full of threats.

Best Practices for Setting Your TTL.

Time-to-live can slow down or speed up important processes of your domain. DNS propagation, for instance. Learn how to use time in your favor! Just follow the best practices for setting your TTLs.

  • To define a convenient TTL value, consider the kind of DNS record you will add or edit and how many changes it can need in time. 
  • If you want to speed your DNS resolution, set up higher TTL values on your DNS records for them to be longer saved on the cache of the DNS recursive servers.
  • If your domain demands constant modifications of the DNS records, a high time-to-live value on them can slow down your propagation process. Lowering TTL values to speed the propagation is the best practice for you.
  • TTL for DNS records that are barely changed should be higher.
  • Domains of mission-critical services like aircraft, railway, electric power grid operating, and control systems require frequent updates and DNS load balancing setups. The best time-to-live practice in these cases is definitely, to define low TTL values. 
  • When you set up the cache TTL for your domain, differentiate between dynamic and static resources. Your dynamic content, specifically what involves users’ interaction, is frequently modified by them. Think about your comments section as an example. When you do not control changes or additions of content, better don’t cache. It will be hard for you to calculate an adequate TTL that keeps that content cached and refreshed on your domain.

But if you control the content, for instance, prices on the products you sell. Since you know how frequently you change such prices (daily, weekly, monthly, etc.), you can perfectly cache and establish a convenient TTL, low or high. 

On the other hand, to cache static resources are really convenient, and the best practice is to set up high TTLs. Loading time will be faster. 


TTL can be your ally or your executor. Managing time could be a challenging game. TTLs are the chance for you to master how to move time in your favor! You can become the Chronos your domain needs for running smoothly!