How to Move DNS Between Registrars Without Breaking Your Site

You can transfer domain DNS without downtime by separating two things people usually lump together: the registrar, which controls the delegation records at the parent zone, and the authoritative nameservers, which answer queries for your zone. If you move the zone to a new provider first, verify it, and only then change the delegation, queries never have to hit a server that does not yet have your records. The rest of this article is about the mechanics of doing that safely.

What actually changes when you transfer domain DNS

Your domain has a parent zone, run by the registry for the TLD, and that zone holds only a few things: the set of nameservers listed for your domain, plus glue records if those nameservers live inside the domain itself. Everything else, meaning every A, AAAA, CNAME, MX and TXT record, lives in the child zone served by your authoritative nameservers. Changing registrar changes who can edit the parent records. Changing DNS provider changes who serves the child zone. They are independent operations, and you can do them in either order, but the safe order is child first, parent second.

When you move the child zone, the new provider needs an exact copy of the records. Query the old servers and save the output before you touch anything:

dig +noall +answer example.com AXFR @ns1.oldprovider.example
example.com.  3600  IN  SOA   ns1.oldprovider.example. hostmaster.example.com. ...
example.com.  3600  IN  NS    ns1.oldprovider.example.
example.com.  3600  IN  NS    ns2.oldprovider.example.
www.example.com. 300 IN A    192.0.2.10
example.com.  300   IN  MX   10 mail.example.com.

Many authoritative servers refuse zone transfers from arbitrary clients, and that is normal. If the transfer is refused, fall back to querying each record type individually, or export the zone from the old provider's control panel if it offers one. The goal is a complete inventory, because any record you forget to copy will simply stop resolving the moment the delegation moves.

The TTL problem and how to drain it

Nothing in DNS happens instantly, and the thing that governs how slowly it happens is the time to live on each record. Caches around the internet, including your own resolver and your visitors' resolvers, will keep serving a record until its TTL expires. That is why the sequence matters more than the speed of any individual step.

Lower the TTL on the records you are about to change well before you change them. A common approach is to drop the TTL to a short value, wait at least one old TTL period so caches pick up the new short value, and only then make the change. The same applies to the NS records and to the delegation itself. If your zone currently uses a long TTL, changing it and immediately changing the records behind it means some resolvers will hold stale answers for the full old duration.

Check what is actually cached rather than assuming:

dig +short NS example.com @8.8.8.8
dig +short NS example.com @1.1.1.1
dig example.com SOA +noall +answer

Querying two or three public resolvers tells you whether the change has propagated to the parts of the internet your users actually traverse. A single resolver telling you the new answer is not proof that everyone sees it.

Cutting over without a gap

Stand up the zone at the new provider while the old one is still authoritative. Populate every record, then test the new servers directly by querying them by name, bypassing the delegation entirely. If the answers match what the old servers return, the zone is ready. If they do not, you have found the problem while it is still invisible to the public.

Then change the delegation at the registrar. This is the parent zone edit, and it is the moment that decides which servers the world asks. Because both the old and new servers already hold correct data, the cutover is a change of pointer rather than a change of content. Some resolvers will still be pointed at the old servers for the remainder of the old NS TTL, and that is fine, because those servers still answer correctly. Leave the old zone running and unchanged until the old TTL has fully elapsed, then decommission it.

Email deserves separate attention because it is the part most likely to break quietly. The MX records must exist at the new provider before the delegation moves, and any related TXT records for sender policy must come along too. Mail servers retry, so a brief inconsistency is usually survivable, but a missing MX record at cutover means messages bounce or queue. Verify with a direct query against the new nameservers before you commit.

If the registrar transfer is the goal

Moving the registration itself between registrars involves an authorization code from the losing registrar and a confirmation step, and the winning registrar will ask you to set nameservers as part of the process. Set them to the servers that already hold your correct zone. Do not let the transfer default to the new registrar's own nameservers unless you have deliberately built the zone there first, because that default is exactly how sites go dark during a transfer. Also confirm the domain is unlocked and that the registrant contact email is one you can actually receive mail at, since the approval messages go there.

A quick way to confirm the delegation is what you think it is, after the fact:

dig +trace example.com | grep -A2 "example.com. IN NS"
example.com. 172800 IN NS ns1.newprovider.example.
example.com. 172800 IN NS ns2.newprovider.example.

dig +trace walks from the root down, so it shows you the delegation as the parent zone currently publishes it, not as your local cache remembers it.

What to do next

Before you change anything, export the full zone and save it somewhere you control, drop your TTLs and wait out the old values, build and test the zone at the new provider by querying its nameservers directly, and only then touch the delegation at the registrar. Keep the old servers answering until the old TTL has expired, and check your mail records specifically rather than assuming they came along with everything else. If you do those things in that order, the worst case is a slow propagation, not an outage.