Changing Nameservers Without Site Downtime; A Practical Guide

The site is up on the old host, the new host is ready, and you're standing in the domain panel with two empty boxes in front of Nameserver 1 and Nameserver 2. If you save right now, chances are a few hours later you'll be facing a "site won't open" message or the new host's default page. The problem isn't the nameserver; it's the order in which you do things.

Before changing nameservers, copy the records

A nameserver means announcing to the registry that "from this moment, the DNS answers for this domain come from such-and-such servers." The moment this announcement is registered, all the records that were in the previous DNS are set aside from the internet's point of view. If you haven't written down the company's MX record somewhere, emails will silently get lost and no one will notice until tomorrow.

So the first step is to take an export. On Linux:

dig +noall +answer example.ir A
dig +noall +answer example.ir MX
dig +noall +answer example.ir TXT
dig +noall +answer www.example.ir CNAME
dig +noall +answer _dmarc.example.ir TXT

Save the output to a file, not in a chat. Don't underestimate TXT records: domain verification in Google Workspace, the SPF record, and _dmarc are all there, and rebuilding them from memory is hard work. If the current DNS is on a management panel, also take a screenshot of the Zone File page. To see what's currently published, checking DNS records is the fastest way.

Records that are almost always forgotten

• MX and email-related TXT records (SPF, DKIM, DMARC)
• Work subdomains: mail, ftp, vpn, staging
• The CAA record if you had restricted SSL issuance
• Verification records for external services like SMS panels or payment gateways

If you have dynamic or countless subdomains, instead of listing each one individually you can use wildcard records and managing dynamic subdomains in DNS and after the switch, cover them all with a single record.

Lower the TTL, but not on the same day

Every DNS record has a TTL number; that is, how many seconds resolvers are allowed to cache the answer. The common value is 3600 or 86400 seconds. If you change the nameserver with an eighty-six-thousand-second TTL, for a full day some users will see the old site and some will see the new site. This is the worst situation, because debugging it becomes nearly impossible.

What I do is this: at least 48 hours before the switch, I reduce the TTL of all important records to 300 seconds. I wait for the previous cache to expire, then I change the nameserver. After I'm sure everything is correct, I return the TTL to its previous value.

Let me mention the cost too: a low TTL means your number of DNS queries multiplies. On a high-traffic domain with weak DNS, this means more delay in resolve and more load on the nameserver. For a week it's fine; forever, no.

Choose the propagation window realistically

"DNS propagation" isn't a magical process; it just means we wait for caches to expire. With a three-hundred-second TTL, practically ten to thirty minutes later the new record is seen everywhere. But there are two exceptions: some ISPs ignore the TTL and keep their own cache for several hours, and local resolvers on the user's system may not change something for days. I've written about the details of this behavior in What is DNS propagation and why does it take time? A complete guide to TTL and caching.

Set the window during low-traffic hours. For an Iranian site, between two and five in the morning is more sensible than Friday afternoon. If you have a store and take orders at night, bypass this rule and instead work mid-week during business hours so that if something breaks, there's someone to answer.

The correct order of steps

1. Take a complete export of the current Zone and save it.
2. On the new DNS, create all the records in advance. Don't change the nameserver yet.
3. Point the main domain's A record to the new server's IP and make sure the web server responds.
4. Reduce the TTL to 300 and wait 48 hours.
5. Change the nameserver in the registrar panel.
6. Use dig from several points to check that the new record has propagated.
7. Obtain or transfer SSL, then return the TTL.

Take step three seriously. If you haven't tested the new IP in advance, after the switch you'll just see a web server error page and won't know whether the problem is DNS or configuration. To be sure about this step, the guide Connecting a domain to a VPS; a complete guide from A record to SSL covers the exact order from the A record to certificate issuance.

This is where they make mistakes

The most common mistake I've seen is this: the nameserver is changed, the site doesn't come up on the new host, and the site admin immediately reverts the nameserver to its previous state. The result? Two propagations, two waits, and users who now see a mix of two different caches. The sign is that an hour after reverting, some users still see the new site and some see the old site.

The real cause is usually that the A record wasn't created on the new DNS, or the new web server doesn't have a VirtualHost for the main domain and only responds to the IP. Before any reverting, check this:

dig @ns1.newdns.ir example.ir A +short
curl -I -H "Host: example.ir" http://NEW_IP/

If the first command returns the correct IP and the second command returns code 200, the problem isn't DNS and reverting the nameserver will only make things worse. If you get a SERVFAIL or NXDOMAIN error, the problem is in the new Zone. I've laid out the order of checking symptoms step by step in A practical DNS troubleshooting guide: symptoms and the order of checking records.

Nameserver or A record?

You don't always have to change the nameserver. If you just want the site to go to another server and you like the current DNS, it's enough to change the A record. This is faster, you don't lose the Zone, and email isn't touched.

My choice in most cases is to change the A record. I only change the nameserver when the current DNS panel has limitations, or I want to gather all records under a single panel. If your domain is .ir, be mindful of the IRNIC identifier and registrar restrictions; A complete guide to registering and managing an ir domain with an IRNIC identifier explains these differences.

A practical note about SSL

Install the SSL certificate on the new server before the switch, not after it. If you use Let's Encrypt, issuing the certificate requires the domain to resolve to the new server; so the correct order is: change the record, wait for it to propagate, then get the certificate. If your site is hosted on Linux shared hosting, this step is usually done from the panel with one click and there's no need to manually tinker with the web server configuration.

And if the domain is on the verge of expiring, renew it first. Changing the nameserver on a domain that expires two days later only doubles the trouble. See the steps and the rescue window in Domain renewal; a complete guide to expiration steps and domain rescue.

Frequently asked questions

How long does a nameserver change take to take effect?

In the most optimistic case, between 30 minutes and 2 hours, provided you've reduced the TTL to 300 seconds in advance. If you haven't touched the TTL and it's at 86400 seconds, you'll have to wait up to 24 hours.

The important point is that the time to take effect at the registry and the time to propagate in caches are two different things. The registry may register it in a few minutes, but resolvers won't change anything until their own cache expires.

Does changing the nameserver cause site downtime?

If you've created the records on the new DNS in advance and lowered the TTL, you won't have noticeable downtime. Downtime happens when the new DNS is empty or the A record was entered incorrectly.

In practice, what the user sees is a DNS_PROBE_FINISHED_NXDOMAIN error in the browser or the host's default page. Both are signs that the new Zone isn't complete.

After changing the nameserver, what happens to emails?

If you haven't copied the MX and TXT records to the new DNS, incoming emails will bounce. This error appears in the sending server's log as "no MX record found" and is often discovered several hours after the switch.

Before the switch, save the output with dig MX example.ir and after the switch repeat the same command against the new nameserver. If the output isn't the same, stop right there.

Can I revert the nameserver to its previous state?

Yes, but only do this when you're sure the problem is with the new DNS. Reverting the nameserver creates another full propagation and the situation stays inconsistent for several hours.

Before reverting, check with dig @ns1.newdns.ir example.ir A +short whether the new Zone responds correctly or not. If the answer is correct, the problem is elsewhere and reverting the nameserver is just a waste of time.

The summary of what you should do today: take the Zone export, bring the TTL down to 300, and create the records on the new DNS. Leave the switch for 48 hours later.