Changing nameservers without downtime: a checklist

You can change nameservers without downtime if the new DNS provider already has a complete copy of your DNS records before you switch. During the changeover, some resolvers still ask the old nameservers and some ask the new ones, so both must give the same answers. The checklist below covers what to copy, what to check and how to verify the result, with special care for email.

What nameservers do

When someone types your domain into a browser, their resolver has to find out which IP address belongs to it. It asks the registry of your top-level domain (for example .com or .de) which servers are responsible for your domain. Those are your nameservers. The resolver then asks them for the actual records: where the website lives, where email goes, and so on.

So there are two layers, and it helps to keep them apart:

Changing nameservers moves the whole zone to a different provider in one step. Changing a single record only edits one entry inside the zone. If you want a refresher on how DNS lookups work in general, the MDN glossary entry on DNS is a good short introduction.

What happens when you change them

You update the nameserver entries at your registrar. The registrar passes the change to the registry, which usually takes minutes. After that, resolvers worldwide pick up the new delegation as their cached copy expires.

That caching is controlled by the TTL (time to live), a value in seconds that tells resolvers how long they may keep an answer, as defined in RFC 1034. The TTL on the delegation itself is set by the registry, not by you, and is often a day or two. That is why providers commonly say a nameserver change can take up to 48 hours to reach everyone, even though many visitors see it much sooner.

During that window, both sets of nameservers receive queries. Nothing breaks as long as they answer the same way. Downtime happens when the new zone is missing something, for example an MX record, and the visitors or mail servers who already use the new nameservers get no answer.

Before you switch: the checklist

1. Get a full copy of your current zone

Log in to your current DNS provider and export the zone file if it offers that. If not, copy every record by hand: type, name, value, priority and TTL. Don't rely on memory or on what the website needs. Subdomains you forgot about (a staging site, a customer portal, a mail autodiscover entry) are the most common cause of trouble.

2. Check email records twice

Email is the part that fails silently, so look for all of these:

• MX records, with their priorities
• SPF: a TXT record on the root domain starting with v=spf1
• DKIM: TXT or CNAME records under <selector>._domainkey
• DMARC: a TXT record at _dmarc
• Autodiscover/autoconfig CNAME or SRV records used by mail clients

DKIM is easy to miss because you cannot list selectors from outside. Check your email provider's admin panel, or open a message you sent and look for s= in the DKIM-Signature header. That value is the selector.

3. Collect verification records

TXT records for Google Search Console, Microsoft 365, payment providers, SSL validation and similar services often sit on the root domain or special subdomains. If they disappear, the services may stop working or ask you to verify again.

4. Look for DNSSEC

If DNSSEC is active, your registrar holds a DS record that matches keys at the old provider. Switching nameservers without handling it causes validating resolvers to reject your domain entirely. The simplest safe path is to remove the DS record at the registrar first, wait for it to expire, and only then switch. ICANN's DNSSEC overview explains how the chain of trust works.

5. Recreate the zone at the new provider

Add every record to the new provider's zone before you touch the nameservers. Compare old and new line by line.

6. Pick a quiet time

Choose a time with low traffic and when you can check the result for an hour or two afterwards. Avoid Friday evenings and days with a campaign going out.

Making the switch

1. Open the domain settings at your registrar (not at your web host, unless they are the same company).
2. Find the nameserver section and choose custom nameservers.
3. Replace the existing entries with the ones your new provider gives you. Remove all the old ones; mixing old and new nameservers leads to inconsistent answers.
4. Save. Some registrars ask for confirmation by email.
5. Keep your old DNS service active for at least a few days. Resolvers that still use the old delegation need it to answer until their cache expires.

After the switch: verify

Check what the world sees for your delegation:

dig NS example.com +short

Ask the new nameservers directly, so the answer doesn't depend on caching:

dig MX example.com @ns1.new-provider.example +short
dig TXT example.com @ns1.new-provider.example +short
dig A www.example.com @ns1.new-provider.example +short

Compare every result with your export. Then do the practical tests: load the website, send an email to the domain from an outside address, send one from the domain and check it doesn't land in spam, and log in to any service that relies on a TXT or CNAME record.

If something goes wrong

• Website unreachable for some visitors: compare A and AAAA records in both zones. A missing AAAA record is easy to overlook.
• Email bouncing or missing: check MX first, then SPF, DKIM and DMARC against the export.
• Domain not resolving at all: check DNSSEC. A leftover DS record is the usual suspect.
• Need to roll back: set the old nameservers at the registrar again. This is why you keep the old service running; the rollback propagates the same way as the change did.

The support article on DNS issues covers more cases in detail.

How fast.site helps

Onboarding with fast.site is a nameserver change, so this checklist applies directly. You add your domain in the dashboard, set the nameservers shown there at your registrar and verify. fast.site then checks propagation automatically in the background, so you don't have to keep running lookups yourself.

After the switch, fast.site manages DNS for the domain and supports A, AAAA, CNAME, MX, TXT and SRV records. That means your existing records, including MX and email authentication records, must be present in the fast.site DNS zone. Compare them against your export before you change anything at the registrar. The DNS docs and the getting started guide walk through the steps.

Your website stays on your current hosting. fast.site sits in front of it as described in what a CDN does, caches public pages at the edge and adds automatic Layer 7 DDoS detection, which is also relevant if you are moving because of an attack (see what to do during a DDoS attack). SSL certificates are issued and renewed automatically.

Once the domain is active, measure your site before and after. A free 7-day trial starts only after DNS, SSL and domain activation are ready.

FAQ

How long does a nameserver change take?

The registry usually processes it within minutes. Resolvers then pick it up as their cached delegation expires, which can take up to 48 hours. Many visitors see the new nameservers much sooner.

Will my email stop working when I change nameservers?

Not if the new zone contains the same MX, SPF, DKIM and DMARC records as the old one. Mail servers look up MX records like any other resolver. If those records are missing from the new zone, incoming mail can bounce or be delayed.

Is changing nameservers the same as transferring a domain?

No. A domain transfer moves the registration to a different registrar. A nameserver change only moves who answers DNS queries. The domain stays with your registrar, and you can change nameservers any time without a transfer.

Should I lower the TTL before changing nameservers?

It helps with records you plan to change, because resolvers refresh them sooner. It does not speed up the delegation itself, since that TTL is set by the registry. If both zones answer identically, the TTL doesn't cause downtime.

Can I change nameservers back if something breaks?

Yes. Set the old nameservers at your registrar again and the change propagates the same way. This only works smoothly if your old DNS service still holds the zone, so don't cancel it right after the switch.