Switching DNS with no downtime

You avoid downtime by making the switch in the right order: build the new zone at Hostworld first, lower the TTLs on the records that will change at least a day before you touch anything, then move the delegation last and leave the old service running for several days afterwards. DNS has no push mechanism. Resolvers keep serving the answer they already have until its TTL expires, so a cutover is really a period of overlap where both sides must work.

Done in that order, most of the change is invisible. Done in the usual order (change the nameservers, then start building the zone), you get a site that works for some people and not others, and mail that quietly lands somewhere you are no longer reading.

Before you start

This picks up from a Hostworld hosting account that is already live, with your site copied across and tested before the domain points at it. If you have landed here from a search and have not done that yet, do it first. Switching DNS to an empty account is just a slower way to take your site down.

You will need:

• Login access to wherever the domain is registered. If the domain is registered with us, that is the client area at portal.hostworld.uk. If it is registered elsewhere, you need the account holder's login for that registrar, not just cPanel access at your old host.
• A complete list of the current DNS records for the domain. Not a rough idea. A list.
• cPanel access to your Hostworld hosting, for the Zone Editor and for creating mailboxes.
• An hour of quiet time, ideally an evening or a weekend, when email volume is low.

Three things commonly go wrong, and all three are avoidable:

• DNSSEC. If the domain is signed and you move nameservers without dealing with the DS record, validating resolvers stop resolving the domain entirely. Not slowly. Immediately, and only for some people, which makes it hard to diagnose. Read Step 3 before anything else.
• Mailboxes that do not exist yet. If mail starts arriving at Hostworld before you have created the mailboxes in cPanel, it is rejected. Those messages are gone.
• Records that were never copied. Anything you forget (SPF, DKIM, a subdomain, the A record the MX hostname depends on) breaks the moment the delegation moves, and not before.

Step 1: Write down the zone you have now

Before you change anything, get a full export or screenshot of the current DNS records: every A and AAAA record, every CNAME, every MX with its priority, every TXT record (SPF, DKIM, domain verification strings, anything else), any SRV or CAA records, and the current SOA. Note the TTL on each one.

Pay particular attention to the mail chain. If your MX record points to a hostname inside your own domain, such as mail.example.co.uk, then that hostname needs an A record in the new zone too. A zone where the MX line was copied but the address record behind it was not will look correct in a DNS checker and still bounce mail, because senders can resolve the name but not the server.

Deleting a record in cPanel's Zone Editor cannot be undone, so this list is also your safety net if you remove the wrong thing later.

Step 2: Lower the TTLs, days before the change

This is the step that people get wrong, and it is wrong in a way that cannot be fixed on the day.

A TTL tells resolvers how long they may cache an answer. If a record has a 24 hour TTL and you drop it to 300 seconds at the same moment you change the record's value, that does nothing for any resolver that already cached the old value. Those resolvers are still working from the old 24 hour copy and will keep serving it for up to another day.

So lower the TTL at least one full old-TTL period before the change. If the current TTL is four hours, lower it at least four hours ahead. If it is 24 hours, lower it a full day ahead, and 48 hours ahead is safer. Drop the records that will change to 300 seconds and leave them there.

cPanel's default TTL is 14400 seconds, four hours. That is a sensible steady-state value and a poor cutover value, so if your old host also runs cPanel, expect to find 14400 on most records.

One thing you cannot control: the TTL on the delegation itself. The NS records that tell the world which nameservers are authoritative for your domain live in the TLD's zone, not yours, and the registry sets that TTL. For many TLDs it is 172800 seconds, two days. That is why a nameserver change is slower than a record change, and why the old "24 to 48 hours" figure has not entirely died even though registries now push registrar changes into the TLD zone within minutes. The record TTL is yours. The delegation TTL is not. Plan for both sides to be answering for up to two days.

Step 3: Check DNSSEC before you do anything else

DNSSEC signs your zone, and a DS record at the registry links your domain to the specific signing key. If the zone moves to different nameservers and the DS record still points at the old key, validating resolvers cannot build a chain of trust and return SERVFAIL. The domain does not resolve at all for anyone using a validating resolver, while it carries on working perfectly for everyone else. That split is why people spend hours blaming the web server.

Log in to your registrar and look for DNSSEC or DS records on the domain. Then:

• If DNSSEC is off, there is nothing to do here. Most domains are in this position.
• If DNSSEC is on, do not move the nameservers yet. Either remove the DS record at the registrar and wait for it to age out of caches before switching (the usual guidance is to wait at least 1.5 times the DS record's TTL before removing DNSKEY records at the old provider, so 36 hours for a 24 hour TTL), or, if the new nameservers also sign the zone, get the new DS record published in the parent zone first and remove the old one after the switch.

Whether ns1 to ns4.serverworld.uk sign zones for your particular product is something you should confirm with us rather than assume either way. Open a support ticket with the domain name and ask before you schedule the change. It is a five minute question that prevents a full outage.

Step 4: Build the zone at Hostworld first

The new zone should be complete and correct before a single resolver is told to look at it. Nothing you do here affects the live site, because the delegation has not moved yet, so this step is free.

In cPanel, go to the Domains section and open Zone Editor, find the domain and click Manage. Add the records from your Step 1 list that are not already there: TXT records for SPF and DKIM, any verification strings, subdomain A records and CNAMEs, and the MX records with the correct priorities. Set the TTL to 300 on anything you may need to correct quickly during the cutover.

Two cPanel specifics matter here.

First, create every mailbox and alias before the change, not after. Mail that arrives for an address cPanel does not know about is rejected.

Second, email routing is a separate setting from the MX record. In the Email section of cPanel, open Email Routing and set Local Mail Exchanger if mail is hosted on this server, or Remote Mail Exchanger if your MX points somewhere else, such as a hosted mail provider. Get this wrong and the server delivers the domain's mail to itself and ignores your MX records entirely, which produces the maddening symptom of correct-looking DNS and no inbound mail.

While you are in Zone Editor, leave the Reset Zone control alone. It replaces your custom records with the default set, and mid-migration that is the worst possible moment to lose them.

Step 5: Clear the registrar's blockers

Before you attempt the change, check two things at the registrar: whether the domain is registrar-locked, and whether the registrar requires the WHOIS admin contact to confirm a nameserver change by email. Some TLDs do. If a confirmation email goes to an old address nobody reads, the change silently never applies and you spend the evening wondering why the delegation has not moved.

Step 6: Change the nameservers to all four of ours

Our nameservers are:

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

The domain is serverworld.uk, not hostworld.uk. That is correct and it is a common typo.

Enter all four. Never mix old and new nameservers as a gradual migration. If the delegation lists two of ours and two of your old host's, resolvers pick between nameservers serving different zone files and return inconsistent answers. It is not a safe halfway house, it is a broken zone.

If the domain is registered with Hostworld, make the change in the client area at portal.hostworld.uk, on the domain's own page. WHMCS submits the change to the registrar in the background rather than only storing it locally, and requests the current values from the registrar when the page loads, so what you see should reflect what is actually filed. You can enter up to five nameservers there; we supply four, so leave the fifth field blank. That is expected and not an error. Note the time you submitted it.

If the domain is registered elsewhere, find the nameserver or DNS settings on the domain at that registrar and replace the existing entries with our four. The wording varies by registrar: "custom nameservers", "use my own nameservers", "change nameservers". The values are the same wherever you are.

The click-by-click version for our own client area lives in our how-to articles, which cover the exact screens rather than the reasoning.

Step 7: Verify properly, not with one checker

A single public propagation checker only tells you what that checker sees. Check the delegation at the TLD, then check what our nameservers are actually serving.

To ask our nameserver directly what it holds for your domain, bypassing every cache in between:

dig @ns1.serverworld.uk example.co.uk A
dig @ns1.serverworld.uk example.co.uk MX
dig @ns1.serverworld.uk example.co.uk TXT

Repeat against ns2, ns3 and ns4. All four should agree. If one disagrees, stop and open a support ticket rather than waiting it out.

Then test from a few different resolvers to see what the outside world is getting, and test mail for real by sending a message from an external address and confirming it lands in the new mailbox.

If the site works everywhere except your own machine, that is usually a local cache:

• Windows: ipconfig /flushdns
• macOS: sudo dscacheutil -flushcache

Linux varies by distribution and by which resolver is running, so check the command for yours rather than pasting one at random.

Be aware that some ISPs ignore TTLs and refresh their caches every two or three days regardless of what you set. There is no fix for that at your end, which is the whole reason for the next step.

Step 8: Leave the old side running, then tidy up

Keep the old nameservers answering and the old mailboxes reachable for at least 72 hours after the change, and a week or two for mail if you can. Resolvers still holding the old delegation will keep using it, and anything that lands on the old side during that window is recoverable only if the old side still exists.

Once traffic has stopped arriving at the old host and inbound mail is appearing reliably in cPanel, raise your TTLs back to something sensible. 300 seconds is a cutover value, not a permanent one: very low TTLs push far more queries at the nameservers for no benefit. Somewhere between 3600 and 14400 suits most stable records.

Only then cancel the old hosting.

When you do not need any of this

If you are changing a single record, an A record or a TXT verification string, and the nameservers are already ours, you do not need the full sequence. Lower that record's TTL ahead of time, change it, put the TTL back. The elaborate version above exists because moving the delegation moves everything at once.

What next

The next step in this sequence is verifying and tuning your email records after the move: confirming SPF, DKIM and DMARC are correct on the new zone so that mail sent from your domain still authenticates. A nameserver move is where SPF records most often get dropped, and the symptom (mail going to spam, rather than bouncing) takes days to notice.

Our DNS guides cover records individually if you need to check one, and our email guides cover deliverability once the domain is settled on our nameservers. If anything in the cutover does not look right, open a support ticket with the domain name and what you are seeing, and it will be logged against your account.