The short answer: the TTL tells every cache how long it may keep an answer, counted from the moment it asked. So at the moment you change a record, the wait is decided by the TTL that was already there. To make the switch short, you lower the TTL beforehand, wait for the whole old TTL to pass, make the change, and raise it again at the end. This article is for whoever controls the domain’s DNS zone and is about to move servers.
What will change, and what to lower beforehand
| Changing |
Records to lower first |
Watch out |
| The website server |
The A records (and AAAA, if there is one) for the domain and for www. |
If www is a CNAME, the CNAME has its own TTL: lower both. |
| The mail server |
The MX records, and the A record of the name the MX points to (for example mail.yourdomain). |
If the sending IP address changes, the SPF record (TXT) changes too: lower it at the same time. |
| An outside service |
That service’s CNAME or TXT. |
Rarely urgent; lower it only if the switch has to be quick. |
| The nameservers |
Not lowered in your panel: the delegation’s TTL belongs to the registry for the extension. |
A different technique is used, explained just below. |
What if the change is to the nameservers?
The delegation’s TTL is not yours, so you cannot lower it. The technique is to make both zones give the same answer: first build the full zone at the new provider and check it, as in moving your DNS zone to a new provider. Then, in the old zone, which is still the one answering, point the records at the new server, using the timeline above. Only then change the nameservers at the registrar. While the old delegation has not expired, some resolvers ask the old zone and others the new one, but both say the same thing and visitors notice nothing. This needs the old provider to keep answering until the end.
The timeline, step by step
| 1 |
Read the current TTL at the source. Ask one of the zone’s nameservers, for example dig @dns1.mozout.com A yourcompany.com +noall +answer if the zone is with us. The number in the second column is the full TTL, in seconds. Do the same for www and for the MX.
|
|
| 2 |
Lower the TTL without changing the value. In the zone editor, change only the TTL of the records in the table to a short value, a few minutes (TTL is written in seconds: 300 is five minutes). The address stays the old one.
|
|
| 3 |
Wait at least the whole old TTL, the number you read in step 1. Only then has every cache that stored the old version forgotten it and picked up the short-TTL version.
|
|
| 4 |
Prepare and test the new server before touching DNS, with the hosts file.
|
|
| 5 |
Make the change to the records’ values. Caches will now empty at the pace of the short TTL. Confirm at the source and at a public resolver, as in asking different resolvers.
|
|
| 6 |
Keep the old server running while visits and e-mails still reach it. Once everything is stable, raise the TTL back to its usual value.
|
|
|
Do not leave the TTL short for good. With a short TTL, resolvers go back to the source far more often, and new visitors wait for a lookup more often. And if the nameservers fail, caches forget the answer quickly and the site stops opening sooner. A long TTL is also a safety net.
|
|
Some resolvers ignore very short TTLs and apply a minimum of their own. A low TTL makes the switch short for most people, not instant for everyone. That is why step 6 matters: the old server stays on a little longer.
|
|
Planning a migration and want to build the timeline with us? Tell us the domain, where the zone is today and where it is going.
Open a support ticket
|
RECOMMENDED PRODUCT Web hosting with cPanel Domain and SSL included, daily backups and the panel you already know. from KSh858.00/mo (3-year plan, with coupon) See plans |
Angola
Brasil
Kenya
Moçambique
Nigeria
Portugal
South Africa
United Kingdom
United States
International
