DNS migration timeline showing nameserver change steps with TTL countdown, record verification and zero-downtime cutover sequence
# developer tools# website monitoring

How to Change Nameservers Without Downtime

Changing nameservers is the riskiest DNS operation most website owners perform. Done incorrectly, it results in your domain going dark — website down, email bouncing, subdomains unreachable — for hours or days until DNS propagates everywhere.

Done correctly, the transition is seamless. Here's the exact sequence.


Why Nameserver Changes Cause Downtime

The danger is the gap between when you change your nameservers at the registrar and when the rest of the internet stops asking your old nameserver. During that gap, some resolvers are getting answers from your old nameserver and some from the new one.

If your new nameserver doesn't have all the same DNS records as the old one, queries that hit the new nameserver return NXDOMAIN (domain not found) or wrong results — even though your old records are still working fine for everyone else.

The root cause of most nameserver migration downtime: records missing at the new nameserver.


Step 1: Audit All Existing DNS Records Before Touching Anything

# Export your current DNS zone — do this BEFORE making changes
dig yourdomain.com ANY +short
dig yourdomain.com A +short
dig yourdomain.com MX +short
dig yourdomain.com TXT +short
dig yourdomain.com CNAME +short
dig www.yourdomain.com CNAME +short
dig mail.yourdomain.com A +short

# More thorough — query against your current authoritative NS
CURRENT_NS=$(dig yourdomain.com NS +short | head -1)
dig yourdomain.com ANY @$CURRENT_NS

List every record. Include subdomains you use for email (mail., smtp.), services (app., api., status.), third-party verification TXT records (Google Search Console, domain ownership verifications), and SPF/DKIM/DMARC records.

Email-related records are the most commonly missed. A site going down for a few hours is bad; email bouncing for 48 hours is a serious business problem.


Step 2: Recreate All Records at the New Nameserver

Log into your new DNS provider and create every record from your audit. Verify each one:

# Verify records exist at the new nameserver BEFORE switching
NEW_NS="ns1.yournewdnsprovider.com"

dig yourdomain.com A @$NEW_NS +short
dig yourdomain.com MX @$NEW_NS +short
dig yourdomain.com TXT @$NEW_NS +short
dig www.yourdomain.com CNAME @$NEW_NS +short

Every record should return the same result as your current nameserver. Don't proceed until they do.


Step 3: Lower TTLs on Your Current Nameserver

Before switching, reduce the TTL on all records at your current nameserver to 300 seconds (5 minutes):

# Verify current TTL
dig yourdomain.com A +ttl
# The number after the name in the answer section is the TTL

Wait for the current TTL to expire. If your TTL was 86400 (24 hours), you need to wait 24 hours after lowering it before the new low TTL is seen everywhere.

This step shortens the propagation window. After the nameserver switch, changes will spread within 5 minutes rather than 24+ hours.


Step 4: Make the Nameserver Change at Your Registrar

Log into your domain registrar and update the nameserver settings to point to your new DNS provider. The change takes effect immediately at the registrar; propagation to the rest of the internet follows.


Step 5: Monitor Propagation From Multiple Locations

# Check what different resolvers are seeing
for ns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
    echo -n "$ns: "
    dig yourdomain.com NS @$ns +short
done

You're looking for all resolvers to return your new nameservers. During propagation, you'll see a mix of old and new — this is normal. See DNS propagation taking too long? What to check first if things haven't updated after the TTL has expired.


Step 6: Restore TTLs

Once propagation is complete and you've confirmed everything is working correctly, raise TTLs back to a sensible value (3600–86400 seconds depending on how frequently records change).


Checklist: Records Commonly Missed

  • Root A record (yourdomain.com → IP)
  • www CNAME or A record
  • MX records for email routing
  • SPF TXT record (v=spf1 ...)
  • DKIM TXT records (often mail._domainkey.yourdomain.com)
  • DMARC TXT record (_dmarc.yourdomain.com)
  • Any service subdomains (api., app., status., mail.)
  • Third-party verification TXT records (Google, Microsoft, Stripe)
  • CAA records if you have them (see CAA records explained)
  • DNSSEC DS record at the registrar if DNSSEC is enabled (must be updated when changing nameservers)

If Something Goes Wrong

If you've changed nameservers and something is broken, the fastest fix is usually to go back to the old nameserver while you sort out what's missing:

  1. Switch nameservers back to the old provider at the registrar
  2. Identify which records are missing at the new provider
  3. Add the missing records
  4. Re-run step 5 to verify all records exist at the new NS
  5. Switch nameservers again

Monitoring After Migration

Domain Monitor monitors your DNS records continuously. After a nameserver migration, DNS record monitoring confirms that all records are propagating correctly and alerts you immediately if any record unexpectedly reverts or changes. Create a free account.


Also in This Series

More posts

What Is a Subdomain Takeover and How to Prevent It

A subdomain takeover lets an attacker claim your subdomain by exploiting dangling DNS records. Learn how it happens, real-world examples, and how DNS monitoring detects it.

Read more
What Is Mean Time to Detect (MTTD)?

Mean time to detect (MTTD) measures how long it takes to discover an incident after it starts. Reducing MTTD is one of the highest-leverage improvements in reliability engineering.

Read more
What Is Black Box Monitoring?

Black box monitoring tests your systems from the outside, the way users experience them — without access to internal code or infrastructure. Learn how it works and when to use it.

Read more

Subscribe to our PRO plan.

Looking to monitor your website and domains? Join our platform and start today.