How long should lowering the DNS TTL before a move actually take?

At Hostna, we manage the infrastructure that handles thousands of DNS zone updates, and the most frequent cause of migration delay is a misunderstanding of the Time to Live (TTL) mechanism. To answer the question directly: you must lower your TTL at least as many seconds before the move as the current TTL value. If your record currently has a TTL of 86400, you must wait at least 24 hours after changing it to a lower value before you can safely update the IP address and expect rapid propagation.

The DNS TTL is a directive sent by your authoritative nameserver to recursive resolvers—such as those operated by ISPs or public providers—telling them how many seconds they are permitted to cache a specific record. If you attempt to move a site while the TTL is still set to a high value, some visitors will see the old server while others see the new one, leading to split-brain scenarios and data inconsistency.

The Fundamental Rule of DNS Cache Expiration

When you modify a DNS record, you are only changing the instructions for the next time a resolver asks for that record. It does not “push” the change to the world. Instead, the world “pulls” the change when their local cache expires. If a resolver cached your A record ten minutes ago with a TTL of 86400, it will not check your nameservers again for another 86200 seconds. This is why the timing of the TTL reduction is the most critical step in moving your domain registration or switching servers.

To verify your current TTL, you should use a tool like dig. On a Linux or macOS terminal, you can check the TTL of your domain by running:

dig +nocmd +noall +answer example.com

The output will show a number in the second column. That number represents the remaining seconds the record has in your local or the queried resolver’s cache. If you query your authoritative nameserver directly, it will show the full TTL you have configured in the control panel.

Understanding TTL Inheritance and the SOA Record

A common failure mode in DNS management is ignoring the Start of Authority (SOA) record. Even if you set your individual A record TTL to 300 seconds, some recursive resolvers may look at the SOA record’s MINIMUM field or the REFRESH and RETRY intervals. The SOA record defines the global parameters for the entire zone. If the SOA MINIMUM value is set to 3600, some resolvers might apply this as a floor for all records in the zone, regardless of the individual record settings.

The SOA record contains several critical fields that affect how long a change takes to propagate. These include the REFRESH timer (how often secondary nameservers check the primary for changes), the RETRY timer (how long they wait if a check fails), and the EXPIRE timer (how long they keep the data if the primary is unreachable). You can inspect your SOA record using this command:

dig SOA example.com

If you see a high value in the MINIMUM field, typically the last number in the SOA string, you must account for this when planning your migration window. Many managed hosting solutions default to a one-hour or four-hour minimum, which can catch administrators off guard during a time-sensitive move.

Calculating the Migration Window and Grace Period

To calculate the exact time you need to wait, use the formula: Wait Time = Current TTL + Buffer. The buffer is necessary because recursive resolvers do not all sync their clocks perfectly, and some may have slightly different caching implementations. A sensible buffer is 10 to 20 percent of the TTL value.

If you are planning to move a site to virtual server environments, you should begin this process several days in advance if your TTL is currently set to a very high value like 172800 (48 hours). Attempting to force a change faster than the TTL allows is technically impossible through standard DNS protocols.

Staging the TTL Reduction for High-Traffic Sites

For high-traffic sites, a sudden drop from a 24-hour TTL to a 60-second TTL can cause a massive spike in queries to your authoritative nameservers. This happens because every single resolver worldwide will now be asking for your record every minute instead of once a day. On our own platform, we recommend a staged approach to avoid overwhelming the DNS infrastructure.

Step 1: Lower the TTL from 86400 to 3600. Wait 24 hours.
Step 2: Lower the TTL from 3600 to 300. Wait 1 hour.
Step 3: Perform the migration by updating the A or AAAA records.
Step 4: Once the move is verified, raise the TTL back to a higher value to reduce DNS query overhead and improve performance for visitors.

This staging ensures that the transition is smooth and that any issues with the new server can be reverted quickly. If your TTL is 300 seconds, a revert will also take approximately 5 minutes to propagate to most users. If you keep the TTL at 86400, a mistake in the migration could leave your site unreachable for a full day.

Verifying Record Expiration Across Global Resolvers

Before you commit to the IP change, you must verify that the new, lower TTL has been picked up by major public resolvers. You can do this by querying specific servers directly. For example, to check what a common public resolver at 8.8.8.8 sees, use:

dig @8.8.8.8 example.com

Look at the TTL value returned. If it is still reflecting the old high value, the wait period is not yet over. You should check multiple resolvers in different geographic regions to ensure that the “old” records have flushed out of the global ecosystem. This is especially important when using Linux instance management tools that might rely on local caching daemons like nscd or systemd-resolved, which could have their own internal TTL overrides.

According to the Internet Corporation for Assigned Names and Numbers, DNS stability is a shared responsibility between the registrant and the resolver operators. Following the TTL rules strictly is the only way to maintain that stability during a move.

Handling Non-Compliant Recursive Resolvers and ISPs

Even with perfect TTL management, you may encounter “sticky” caches. Some regional ISPs or corporate firewalls are configured to ignore low TTL values to save bandwidth. They might enforce a minimum cache time of 24 hours regardless of what your authoritative server says. This is why you should always keep the old server running for at least 48 hours after a migration, even if you set your TTL to 300 seconds.

You can monitor the traffic on the old server’s access logs to see when it drops to zero. If you are using a standard web server, you can use tail and awk to watch real-time requests:

tail -f /var/log/apache2/access.log | awk '{print $1}'

When the stream of IP addresses hitting the old server stops, you can be confident that propagation is complete. If you are using securing a new domain or a fresh IP, this is less of a concern, but for existing sites, this tail-log method is the final verification step. For more information on the technical specifications of caching, you can refer to the Wikipedia article on Time to live, which explains the historical context of these headers.

If you find that propagation is taking longer than the TTL should allow, check for DNSSEC issues. A change in the A record without a corresponding update to the RRSIG record can cause validation failures in resolvers that enforce DNSSEC. Within the Hostna dashboard, we automate much of the signing process, but manual moves between different providers require careful coordination of the DS records at the registrar level.

If your migration is still not showing up after the calculated wait time, the first thing to check is whether you updated the correct zone. It is common for users to have multiple sets of nameservers configured at the registrar, while they are only updating one. Use online DNS diagnostic tools to confirm which nameservers are currently authoritative for your domain before assuming the TTL is the culprit.

This article was drafted with AI assistance from Hostna’s own research pipeline and published without individual review. Tell us if anything here is wrong.