How to Take Over DNS for a Domain You Just Bought

To take over DNS for a domain you bought, you change the set of authoritative name servers listed at the registrar, then recreate every record the old zone served in a zone file you control. The registrar delegation is the only thing that actually moves control; everything else is copying data before the old zone goes dark.

The temptation is to point the name servers at your new provider and move on. That works for a parked domain with one A record. It fails badly for a domain with mail, because mail routing depends on MX records and on TXT records that carry sender policy, and both live in the zone you are about to abandon. If you cut the delegation before you copy those records, mail to the domain starts bouncing and mail sent from the domain starts failing authentication checks. The fix is to do the copy first, verify it, and only then change the delegation.

Read the existing zone before you take over DNS

Start by finding out what the domain currently publishes. The delegation itself lives at the parent, so ask a public resolver rather than the domain's own name servers, and ask for the NS record type:

$ dig +short NS example.com @1.1.1.1
ns1.oldprovider.net.
ns2.oldprovider.net.

Those names are your source. Query one of them directly for the full zone. A zone transfer is the clean way to do this, and it either works or it does not:

$ dig AXFR example.com @ns1.oldprovider.net
; <<>> DiG 9.x <<>> AXFR example.com @ns1.oldprovider.net
example.com.        3600 IN SOA ns1.oldprovider.net. hostmaster.example.com. (
                                2024010101 7200 3600 1209600 3600 )
example.com.        3600 IN NS  ns1.oldprovider.net.
example.com.        3600 IN NS  ns2.oldprovider.net.
example.com.        3600 IN A   203.0.113.10
example.com.        3600 IN MX  10 mail.example.com.
example.com.        3600 IN TXT "v=spf1 include:_spf.oldprovider.net ~all"
www.example.com.    3600 IN CNAME example.com.
mail.example.com.   3600 IN A   203.0.113.11

Most providers refuse AXFR from arbitrary clients, and that is normal. If you get a refusal, you fall back to enumerating names. You cannot list a zone without a transfer, so you have to collect candidate names from other sources. Certificate transparency logs are the best of them, since every name that ever had a TLS certificate appears there. Search the logs for the domain, then query each name you find against the old name servers for the record types that matter: A, AAAA, CNAME, MX, TXT, SRV and CAA.

Do not skip TXT. A zone can hold several records at that name, and each one matters for a different reason: the SPF policy, the DKIM public key, a domain verification token, and sometimes a DMARC policy published at _dmarc. Query the name with dig TXT and read every string in the answer section. DKIM keys in particular are long and easy to truncate by accident when copying by hand.

Also check for a wildcard. If the old zone has a record at *.example.com, every name you never thought to enumerate resolves through it, and omitting the wildcard in your new zone silently breaks all of them.

Rebuild the zone and lower the TTLs first

Create the zone at your new provider and enter the records you collected. Keep the same owner names, the same record types and the same values. The one field you should deliberately change is the TTL, and you should change it early.

TTL is how long resolvers may cache an answer. If your records sit at a high TTL when you switch delegations, caches around the internet will keep serving the old addresses for that long after you move. So a day or more before the cutover, drop the TTL on the records you care about to something short, on the order of a few minutes. Do this in the old zone, not the new one, because it is the old zone that resolvers are still reading.

The delegation itself is cached separately. The parent zone publishes the NS records with its own TTL, and you cannot lower that one yourself; the registrar controls it. That is why the cutover is never instant, and why you should expect the change to propagate unevenly rather than all at once.

While you are building the new zone, check that the name servers you intend to use actually answer for it before you commit. Set your resolver to one of them and query the zone apex:

$ dig +short SOA example.com @ns1.newprovider.net
ns1.newprovider.net. hostmaster.example.com. 1 7200 3600 1209600 3600

A response here means the zone exists and is being served. No response, or a SERVFAIL, means the zone is not loaded yet and changing the delegation now would take the domain offline.

Change the delegation and verify the take over

Now go to the registrar and replace the old name server entries with the new ones. Most registrars accept the change immediately and push it to the registry, but the registry may impose its own delay, and some registrars require the new name servers to be in bailiwick before they will accept them. If the registrar rejects the change, that is usually why.

After the change, resolution will be inconsistent for a while as caches expire. Query the parent rather than a recursive resolver to see what is actually published, since a recursive resolver may still be holding the old answer:

$ dig +short NS example.com @a.gtld-servers.net
ns1.newprovider.net.
ns2.newprovider.net.

Once the parent shows the new names, walk through the records you copied and confirm each one resolves. Check the apex, check www, check the mail host, check every MX target, and check the TXT records by exact string. For mail specifically, send a test message in and out before you consider the job done, because a missing DKIM key or a malformed SPF record will not show up in a dig output but will show up as a delivery failure.

Leave the old zone in place if you can. It costs nothing to keep and gives you a fallback if something you missed turns out to matter. Do not delete it until the domain has run cleanly on the new name servers through at least one full mail cycle and one certificate renewal, since an automated renewal that uses a DNS challenge will fail if the validation record is not in the live zone.

The practical next step is to document what you found. Write down every record you copied, the TTLs, and the date of the delegation change, and keep that note with the domain. The next person to touch this zone, which may be you in a year, will not remember which names existed or why, and the old zone will not be around to ask.