Lowering your TTLs before you move

A TTL (Time To Live) is a number of seconds attached to every DNS record. It tells the recursive resolvers that the world's ISPs and networks run how long they may keep a cached copy of that record before coming back to ask your authoritative nameservers again. Lower the TTL on the records you are about to change, do it far enough in advance, and a move that would have left stale visitors hitting the old server for a day instead resolves to the new one within about five minutes.

This guide picks up from a move you have already decided on: you know which Hostworld product the site is going to, and the destination is built and working. If you have arrived here from a search, that is the only thing assumed.

Before you start

Three things need to be true before lowering TTLs is worth doing.

• You know where your DNS is actually answered from. This is the step people skip and then wonder why nothing changed. If your domain's nameservers currently point at Hostworld, your zone is edited in cPanel's Zone Editor. If they point at your registrar, or at a third party DNS service, that is where the authoritative records live and cPanel edits will have no effect at all. Before a move, the authoritative DNS is usually not Hostworld yet.
• You have the time. Lowering a TTL does not speed up the change you are making right now. Resolvers that already cached the record under the old, long TTL will honour that old timer until it runs out. The lower value only takes effect for the next lookup after that. So the lead time has to be longer than the TTL you are replacing.
• You know which records are moving. TTL is per record, not per domain. The ones that matter at cutover are the A record for the bare domain, any AAAA record, the CNAME or A record for www, and the MX records if mail is moving too. MX is the one people forget, and forgetting it is how you lose email.

One warning about cPanel specifically: the Zone Editor has no undo. You can reset a zone to its defaults, but you cannot step back a single bad edit. Copy the current zone contents into a text file before you touch anything.

Step 1: Read the TTLs you currently have

You cannot pick a lead time until you know what you are up against. On Linux or macOS, dig is already installed. Run:

dig +nocmd +noall +answer +ttlunits example.com A

+noall switches off every output section, +answer turns the answer section back on (it must come after +noall or it is filtered out again), and +ttlunits prints the TTL as seconds, minutes, hours or days instead of a raw number.

Repeat for each record you intend to change:

dig +nocmd +noall +answer +ttlunits www.example.com
dig +nocmd +noall +answer +ttlunits example.com MX

There is a catch. Asking your local resolver gives you the remaining cache time, not the configured value. Query the domain's authoritative nameserver directly to see the real setting:

dig +nocmd +noall +answer @ns1.example.com www.example.com

Substitute the nameserver your domain actually uses. If you run the same query twice and the number goes down, you are looking at a cached answer, not the authoritative one.

On Windows, dig is not installed by default. If you are on a Windows desktop, run these from a Linux or macOS machine, or from a Linux VPS, rather than trying to read TTLs out of nslookup.

Step 2: Work out how far in advance to lower them

The rule most sources converge on is at least twice the current TTL, and ideally 24 to 48 hours. The reasoning is straightforward: every resolver in the world that has your record cached needs its existing timer to expire before it will see the new, lower value. Twice the current TTL is the margin that covers a resolver which cached one second before you made the edit.

In practice, plan for 24 to 48 hours and stop doing arithmetic. Lowering the TTL an hour before cutover is the single most common cause of an unexpectedly long propagation window, because it achieves nothing at all.

Step 3: Choose a value

Use 300 seconds. Five minutes is the consensus target: short enough that the cutover window is measured in minutes, long enough that you are not hammering your authoritative nameservers. Some sources allow a floor of 60 seconds, which is fine for a short, carefully watched cutover, but 300 is the sensible default and there is very little practical difference.

The cost of a low TTL is real but modest: more queries hitting your authoritative nameservers, and a slightly slower average lookup for visitors because fewer answers come from cache. For most sites this is negligible for a day or two.

Some people prefer a staged ladder rather than a single drop, for example 86400 a week out, 3600 three days out, then 300 a day or two out. Sources disagree on the exact rungs. They do not disagree on the destination, which is 300 seconds, 24 to 48 hours before you cut over. If your current TTL is already 3600 or lower, skip the ladder entirely.

Step 4: Lower the TTLs where your DNS actually lives

Go to whichever system is authoritative today, which before a move to Hostworld is usually your old host or your registrar, and set the TTL to 300 on every record you plan to change.

If the domain is already on Hostworld nameservers and you are moving between our own services (a shared hosting account to a VPS, for example), the zone is edited in cPanel: cPanel then the Domains section, Zone Editor, Manage next to the domain, Edit on the record, change the TTL, Save Record. Reseller customers with WHM access have a bulk option under DNS Functions then Set Zone TTL, which applies one value to a whole zone in a single action. For the click by click version on a shared account, see our how to articles for cPanel.

Lower the TTL across the whole record set rather than picking off one record. This is not tidiness. RFC 2181 requires that all records of the same type and name share a single TTL, and cPanel enforces it. Edit one TXT record out of three and you get a Zone Editor error along the lines of "Zone is invalid: Line NN: TTL set to prior TTL (900)", or Error ID t85tzu in WHM. The fix is to bring the outlier into line with its siblings and save again.

Step 5: Confirm the low TTL is actually in circulation

Do not take the control panel's word for it. Check what public resolvers are handing out:

dig @1.1.1.1 +nocmd +noall +answer +ttlunits example.com A
dig @8.8.8.8 +nocmd +noall +answer +ttlunits example.com A

You are looking for a number at or below 300. If a resolver is still reporting a value in the thousands, its old cache has not expired yet and you are not ready. Wait it out.

Step 6: Cut over, then watch

With the TTL at 300 across the board, change the records to point at Hostworld and the world follows within about five minutes. Two caveats to be honest about.

First, not every resolver obeys TTLs perfectly. Mainstream guidance is that a small percentage of visitors will see stale data for longer than the TTL implies, usually because of an ISP resolver with its own fixed cache interval. At least one UK host puts it far more strongly and says lower values almost certainly will not be honoured. That is a minority view, and our experience is closer to the mainstream one, but the practical response is the same either way: leave the old server running for at least a few hours, and ideally 24 to 48, after the cutover. It costs you nothing but a bit of overlap.

Second, if mail is moving, keep both mail servers accepting messages during the transition, or forward from the old one, and monitor both inboxes for 48 hours. During the overlap some sending servers will deliver to the old MX and some to the new. Verify the new mailbox works before you touch the MX record, not after.

The case where low TTLs will not save you: nameserver changes

This is the part that catches people out on a move to Hostworld, because most customers are not editing an A record. They are changing the domain's nameservers at their registrar to:

• ns1.serverworld.uk
• ns2.serverworld.uk
• ns3.serverworld.uk
• ns4.serverworld.uk

The delegation that says "this domain's nameservers are those four" does not live in your zone. It lives in the parent zone run by the TLD registry, and it carries its own TTL, commonly 172800 seconds, which is 48 hours. That TTL is not yours to change. You can set every record in your zone to 300 and the registry delegation will still be cached for up to two days.

The consequence is a split world. Until the delegation ages out, some resolvers ask the old nameservers and some ask ours, and visitors see whichever set answers them. So:

• Build the zone on our nameservers completely before you switch the delegation. Every A, CNAME, MX and TXT record should already be in place, so that whichever set of nameservers a resolver reaches, it gets a working answer.
• Keep the old nameservers and the old server live for the full 48 hours. If the two sets of nameservers disagree, half your visitors are on the wrong one.
• Low TTLs on the records themselves still help. They shorten the tail once a resolver does re-query. They just do not shorten the registry window.

If the domain is registered through Hostworld, the nameservers are not changed in cPanel at all. They are changed in the client area at portal.hostworld.uk, which is WHMCS. Find the domain under your domains list and open its management page: the nameserver fields are there, and WHMCS fetches the current values live from the registrar each time the page loads rather than showing a stored copy. There are five fields. Enter our four and leave the fifth blank. Whether you also see a DNS editor in the portal depends on whether the DNS Management addon is enabled on that domain, so do not assume it is there.

When you do not need any of this

If your records are already at 3600 or below, the honest answer is that lowering further buys you minutes, not hours, and you can skip straight to the cutover. If you are moving nothing but a single subdomain nobody has visited yet, there is nothing cached to expire. And if you are changing nameservers on a brand new domain that has never resolved, the whole exercise is moot.

One more thing worth knowing: nothing about TTL handling has changed recently. The mechanics trace back to long standing RFCs, and readers who assume DNS has been modernised into something faster will be disappointed.

Step 7: Put the TTLs back afterwards

Once the site and mail have been stable for a day or so, raise the TTLs back to a normal production value. Between 3600 and 86400 is the usual range for stable records; cPanel's own default is 14400, which is four hours and a perfectly reasonable place to land. Leaving everything at 300 permanently means every resolver re-queries your nameservers twenty times an hour for no benefit.

There is one more timer to know about. The SOA record carries a minimum field which controls negative caching: how long a resolver remembers that a name does not exist, typically 300 to 900 seconds. This is why a record you have just created still looks missing to the one person who checked a minute too early. They taught their resolver the name did not exist, and it will believe that for a few minutes regardless of what you do.

What next

With low TTLs in circulation and the destination built, the next step in the playbook is pointing the domain at Hostworld's nameservers at your registrar. Our domain guides cover doing that registrar by registrar, and the values you will need are ns1 through ns4.serverworld.uk. If you want more background on how the pieces fit together first, start with our DNS guides.

If something is not behaving, the escalation thresholds are clear. If the delegation at the TLD registry still has not updated after 48 hours, or the domain returns SERVFAIL or NXDOMAIN when you query our nameservers directly, that is not propagation and waiting longer will not fix it. Open a support ticket with the output of your dig commands and we will look at the zone from our side.