Preparing nameservers for Cloudflare

What moving nameservers does

When you move your domain's authoritative nameservers to Cloudflare, the new zone starts answering DNS. Both the old and the new nameserver sets may be delegated for a while because TTL defaults and cascading resolvers hold the old answer.

Do this only after you added the DNS records to the Cloudflare zone, because Cloudflare serves them from the moment delegation switches. Empty or partial zones create a window where the domain resolves nothing.

Before you start

1. Export the current DNS from your registrar or old provider. You need every A, AAAA, CNAME, MX, TXT, SRV and the like, exactly as they were.
2. Copy them into the Cloudflare zone and check proxied status. Keep exact values: an MX without the mail host, or a TXT with the truncated value, breaks mail.
3. Lower TTL to 300 (5 minutes) on the records you will cut over, at least 24 hours before the switch, so the edge does not store the old answer too long.
4. Freeze DNS edits during the window. Do not add a record to the old provider after you lower TTL, then expect the change to arrive later, split-brain will bite.

The night of the swap

1. Open the registrar's nameserver page and replace the old nameservers with the two (or more) Cloudflare nameservers Cloudflare assigned to the zone, for example:

anya.ns.cloudflare.com
jay.ns.cloudflare.com

1. Save. The registrar waits. Often a confirmation email or a . end-state is returned.
2. Confirm the domain in the dashboard even before propagation completes. Cloudflare shows "active" once it answers the domain, although global resolvers still take minutes to catch up.

| Step | Who | What you get |

| Registrar | You now | New delegation submitted |

| Cloudflare | Dashboard | Zone shows the assigned NS |

| Worldwide | Everyone else | Old cache answers until TTL |

Verify the zone is serving

1. After the switch, run a local query against the new nameservers directly:

nslookup -type=ns example.com anya.ns.cloudflare.com
nslookup www.example.com anya.ns.cloudflare.com

1. Compare answers for a few records across the old and new. For a domain that uses email, mail must point at the exact same MX that ran before the move.
2. Probe the mail servers: nslookup -type=mx example.com. Push tests after the switch to confirm mail flows and deliverability rather than only the MX lookup.

Common mistakes

• Lowered TTL, then forgot to raise it back after GO-live: the zone spends its days on long TTL, which is fine but wasteful for change frequency.
• Moving a domain that hosts mail without copying SPF/DKIM: mail fails deliverability even though nothing visibly breaks.
• Thinking an orange cloud record works the moment you add it: proxy only starts after delegation completes + the zone is active.

After the move

• Raise TTL back to a normal value (e.g. 3600) once the old TTL fully expired.
• Keep the old provider documented, and purge any leftover old NS entries you removed.
• Re-test email and the web from at least two networks. The check DNS propagation tools guide shows how to watch the global answer settle.