What DNS propagation is and why it takes time

What Is DNS Propagation and Why Should You Take It Seriously?

When you change a record such as A or MX in your domain's DNS, the change is not applied instantly across the internet. The time interval between the moment the change is registered on the authoritative server and the moment all users worldwide receive the new response is called DNS propagation. This process can take anywhere from a few minutes to 72 hours, and understanding it is critical for any website administrator planning a server migration, hosting change, or email relocation.

The main issue is that DNS is a distributed system with millions of caches around the world. Each resolver, such as Google Public DNS or a user's ISP service, keeps responses for a specific period to reduce traffic load. This duration is determined by the TTL (Time To Live) value in the DNS record. If you don't understand this concept properly, after a migration, some users may see you on the old server while others see the new one — and that means a poor user experience and loss of trust.

DNS Structure and the Role of TTL in Propagation

To understand DNS propagation, you first need to know that DNS consists of multiple layers. When a user enters example.com in their browser, their request first goes to a resolver (such as 8.8.8.8 or the ISP's DNS). If the resolver doesn't have the answer in its cache, it contacts the root server and then the TLD server (e.g., .com) to find the address of the domain's authoritative server. Finally, the response is received from the authoritative server and returned to the user.

The TTL value in each DNS record determines how long each resolver is allowed to keep the response in its cache. This value is defined in seconds. For example:

example.com.  3600  IN  A  185.10.10.10

In this example, the TTL is 3600 seconds (one hour). This means resolvers will show the address 185.10.10.10 for this domain to users for up to one hour, even if you change the record.

Low TTL vs. High TTL

Choosing the TTL value is a strategic decision:

• Low TTL (300 to 900 seconds): Faster propagation of changes, but more load on the authoritative server because more requests reach it.
• High TTL (86400 seconds or 24 hours): Reduced server load and faster responses for users, but if you mistakenly change a record, the error will persist across the internet for up to 24 hours.

Most typical domains use a default TTL of 3600 seconds. However, for critical records like MX (mail server), a higher TTL is usually considered to maintain email service stability.

Why Does DNS Propagation Sometimes Take Up to 72 Hours?

Many people think TTL is the only factor determining propagation time. But the reality is more complex. Even if you set TTL to 60 seconds, some resolvers and legacy systems don't respect this value. The main reasons for delay include:

1. Rogue resolvers: Some small ISPs or government organizations have resolvers that ignore TTL and cache responses for several days.
2. Browser and OS cache: Browsers and operating systems also keep DNS responses in their memory. Windows caches DNS for 3600 seconds by default.
3. Legacy authoritative servers: If your domain is on an old DNS server with outdated software, it may behave unexpectedly during propagation.
4. SOA record and Refresh: The SOA record includes Refresh and Retry values used for Zone Transfer between DNS servers. If you have multiple authoritative servers, these values also affect propagation time.

Important note: DNS propagation time is not the same for all users. For each user, propagation time equals the remaining TTL in their resolver's cache. So a user who cached the response 5 minutes ago will see the old response for another 55 minutes, while another user who just made a request will receive the new response.

Lowering TTL Before Migration: The Correct Method

If you plan to migrate to a new server or change hosting, you need to plan ahead. The standard method is as follows:

Step 1: Lower TTL at Least 48 Hours Before Migration

At least 48 hours (preferably 72 hours) before the migration time, lower the TTL of all records that will change to a low value such as 300 seconds (5 minutes). This causes resolvers worldwide to gradually discard old responses, and after 48 hours, almost all resolvers will cache the response with a low TTL.

example.com.  300  IN  A  185.10.10.10
www.example.com.  300  IN  A  185.10.10.10

Step 2: Perform the Migration

After 48 hours have passed, make the record changes. Now, because the TTL is low, it will take at most 5 minutes for all resolvers to receive the new response. In practice, most users will see the new response in less than 10 minutes.

Step 3: Increase TTL After Confirmation

24 to 48 hours after the migration, once you're sure everything is working correctly, restore the TTL to its normal value (e.g., 3600 or 86400). This reduces server load and improves response speed.

Tools for Checking DNS Propagation

To see how propagation is progressing in different parts of the world, use online tools:

• dnschecker.org: Checks records from over 200 locations worldwide.
• whatsmydns.net: Shows propagation status for various record types.
• dig and nslookup: Command-line tools for direct checking.

To check from the Linux command line:

dig example.com A +noall +answer
dig example.com A @8.8.8.8

The second command specifically queries Google DNS and shows whether this resolver has cached the new response or not.

Common DNS Propagation Mistakes

In years of technical support work, we've seen the most common user mistakes in this area:

Mistake 1: Changing TTL at the Same Time as Migration

Some people lower the TTL exactly at the moment of migration. This is useless because resolvers still have the old response cached with a high TTL (e.g., 24 hours) and won't get the new response for the next 24 hours. TTL reduction must be done at least 48 hours in advance.

Mistake 2: Forgetting Email Records

During migration, many people only change the A record and forget the MX record. If your mail server is also moving, be sure to set the MX and SPF records with a low TTL as well. Otherwise, your emails will be sent to the old server for a long time.

Mistake 3: Checking from Only One Location

Checking propagation only from your own system is not enough. Your resolver might return the new response, but other users' ISP resolvers might still have the old response cached. Always use multi-location tools.

Advanced Tips for Hassle-Free Migration

For more complex migrations, consider these tips:

• Test before changing: If you have access to the new server, edit your system's hosts file before changing DNS so the domain points to the new IP and verify the server works correctly.
• Use separate TTLs for different records: You can keep critical records like MX with a higher TTL and only lower the A and AAAA records.
• Manage browser cache: Recommend your users clear their browser cache or use incognito mode. This helps them see the new version faster.

If you use a DNS provider with a distributed infrastructure, propagation is usually faster. Professional DNS services like those ServerNet offers in its hosting packages support both IPv4 and IPv6 servers and allow precise TTL management.

Summary

DNS propagation is a natural and unavoidable process that you can manage with a proper understanding of TTL and cache. The golden rule: If you have a migration ahead, lower the TTL at least 48 hours in advance, perform the migration, and after confirming stability, restore the TTL to normal. With this method, you reduce propagation time from several days to a few minutes and provide an uninterrupted user experience for your visitors. Remember that patience and planning are the keys to success in any migration — and DNS is no exception.