Lowering DNS TTL before a site migration: why it matters and how to do it

Moving a website to a new host looks like a matter of copying files and a database. In practice the delicate moment is switching the DNS record to the new IP address. You change the record, yet thousands of resolvers keep remembering the old answer and keep sending part of your visitors to the old server. How long that split lasts is decided by the TTL, so it has to be managed in advance.

What TTL actually controls

TTL (Time To Live) is a number of seconds attached to every DNS record. When an ISP resolver or an office router receives an answer about your domain, it caches it for that long without asking again. With a TTL of 86400 on the A record, an answer may stay unchanged for a whole day. On normal days that is good: fewer queries, faster page loads, less load on the DNS server.

The catch is that TTL acts before a change, not after it. A resolver stores the answer with the TTL that was valid when it fetched it. If you lower the TTL to 300 today, an answer cached yesterday for 86400 seconds will still live out its full period. That is why the TTL must be lowered at least one old-TTL period before the migration.

Checking the current value

Query the authoritative server directly, because intermediate resolvers show a countdown of the remaining time:

dig NS example.uz +short
dig @ns1.example.uz example.uz A +noall +answer
dig @ns1.example.uz example.uz SOA +noall +answer

The second column is the TTL. Check www, mail and other subdomains as well, since they often carry their own values. The last SOA field defines how long "name does not exist" answers are cached, which matters if you add new subdomains during the move.

A step-by-step plan

Take a Tashkent clothing store on example.uz with a TTL of 86400 and a migration planned for Saturday morning:

1. On Thursday morning, at least 24 hours ahead, lower the TTL of the A and www records to 300 while keeping the old IP.
2. On Friday, confirm on the authoritative server and a couple of public resolvers that the TTL is 300 or less.
3. On Saturday, copy files and the database and test the site on the new IP.
4. Switch the A record. Within about five minutes most visitors reach the new server.
5. After a day or two of stable operation, raise the TTL back to 3600 or higher.

The real benefit is a fast rollback. If something breaks on the new server, you point the record back and recover within minutes instead of showing the error to some customers for a full day.

Testing the new server before DNS changes

You can preview the new server from your own machine only, while everyone else still sees the old site:

# /etc/hosts or C:\Windows\System32\drivers\etc\hosts
203.0.113.25  example.uz www.example.uz

curl -I --resolve example.uz:443:203.0.113.25 https://example.uz/

Check the cart, checkout, contact form and admin panel this way, then remove the hosts entry so it does not confuse you later.

Common mistakes

The most frequent mistake is lowering the TTL in the same minute as changing the IP, which achieves almost nothing. Another is updating the bare domain and forgetting www, so orders end up split between two databases. If the MX record moves too, lower its TTL early and keep the old mailbox for a few days, because some messages may still arrive there. Finally, do not leave a low TTL forever; it adds unnecessary queries.

Changing nameservers is different

This plan works fully when records stay on the same DNS server and only their values change. If you move the domain to different nameservers, the NS records live in the .uz registry and you cannot control their TTL. Copy every record to the new DNS server beforehand and keep the old one running through the transition. In the sayt.uz cabinet you can set the TTL when editing a record, so make it a habit to change it a day before any planned move.

Which value fits when

Avoid values below 60 seconds, since some resolvers ignore very small TTLs and apply their own minimum. Five minutes is fast enough and behaves consistently everywhere.