Module 6 · 6.3

English

Nederlands English Deutsch Français Dansk Español Svenska Italiano Português Română Български Hrvatski Norsk Lietuvių Slovenščina

DNS during a transfer

Module 6: Time, cache and transferring · Reading time: 10 minutes

Learning objective: After this lesson you'll be able to plan a move of your website, your email or your DNS management so that visitors notice nothing and you don't miss any mail.

Key concepts: types of transfer, order of steps, lowering the TTL in advance, preparing records, backing up the zone, testing before the switch (hosts file, preview address), email during the switch, registry checks beforehand, DNSSEC and the DS record

Four types of transfer

"I'm transferring my domain" can mean four different things. It helps enormously to first work out which one you mean, because each type affects different records.

What's moving	What changes in the DNS
Your website to a different server	The A and AAAA records of `@` and `www` (and any subdomains)
Your email to a different mail provider	The MX records, the SPF record, DKIM records, possibly `autodiscover`
Your DNS management to a different provider	The nameservers at the registry; all records need to move to the new provider
Your domain registration to a different registrar	In principle nothing in the DNS, but the nameservers are often changed at the same time

Often several of these happen at once, for example if you're moving everything from one provider to another. In that case, the pitfalls of all four apply.

The golden order

The most important principle: first get everything ready in the new place, then switch. The switch itself is a small action, a few records or the nameservers. Anything that can be done before the switch, you do before the switch.

A few days in advance

Back up your current zone. Export the records, take a screenshot or write them down. Without an overview of what was there, you won't know afterwards what's missing. Many panels have a button for a DNS backup.
Make an inventory. Go through every line and note what it's for: website, mail, verification with Google or Microsoft, a newsletter service, a subdomain for a webshop. It's precisely those extra records (TXT for verification, CNAME for DKIM from a newsletter service) that are often forgotten during transfers.
Set up the new environment. The website is on the new server, the mailboxes exist with the new mail provider.
Test before the switch. You can view a website on a new server without changing the DNS: with a line in your hosts file, or with a test address or preview address that the new provider gives you. Don't forget to remove that hosts line afterwards.

At least one old TTL period in advance

Lower the TTL of the records you're going to change to 300 seconds (lesson 6.1). If the TTL was 3600, do this at least an hour beforehand; a day to be safe. If it was 86400, do it at least a day beforehand.

Note: you can't lower the TTL of the NS records at the registry yourself (lesson 6.2). With a nameserver switch, you always have that waiting time.

The switch

Change the records (for a website or email transfer), or change the nameservers at your registrar (for a transfer of DNS management).
Check immediately at the authoritative nameserver that the new values are there (dig A example.com @ns1.newhost.example).

Afterwards

Check everything: the website via http and https, the certificate, a test email back and forth, and an online check of MX, SPF, DKIM and DMARC.
Set the TTL back to 3600 once everything works.
Only cancel the old service once no more mail or visits have come in at the old place for a few days. If you cancel too soon, your site or mail could disappear, or in the worst case your domain could become free for anyone to register.

A transfer of DNS management

If you're moving your DNS to a different provider (different nameservers), there's one extra rule: the zone must be complete with the new provider before you change the nameservers. From the moment of the switch, the new provider gives all the answers. Whatever is missing there no longer exists.

Take this list as a minimum:

@          A      192.0.2.10
@          AAAA   2001:db8::10
www        A      192.0.2.10        (or a CNAME)
mail       A      192.0.2.25        (if your MX points to mail.example.com)
@          MX     10 mail.example.com.
@          TXT    "v=spf1 ... ~all"
x._domainkey  TXT "v=DKIM1; k=rsa; p=..."   (the selector differs per provider)
_dmarc     TXT    "v=DMARC1; p=quarantine"

Plus all subdomains, verification records and records from external services.

Some registries check the new nameservers before accepting the change. DENIC (the registry of .de), for example, checks whether the new nameservers already answer for the domain. If the zone isn't there yet, the change is refused. This is another reason to set up the zone first.

Example from practice

A domain was linked to a website builder by pointing the nameservers to that platform. The platform itself set up an MX record pointing to mail.example.com and an SPF record, but no A record for mail.example.com. The result: sending worked, receiving didn't. Every mail server trying to deliver mail found no address for the name from the MX record. A single A record at the platform fixed it. Lesson: if you move the nameservers, every record that another record points to has to move with it.

Email during the switch

During the transition period, some mail still arrives at the old place: senders with an old answer in their cache deliver there. That's normal and not a problem, as long as you check both mailboxes.

Set up the new mailbox in your mail program in advance, using the server name given by the new provider (not mail.example.com, because that name points to different places during the switch).
Leave the old mailbox in your mail program too, until nothing more has come in for a few days.
Copy old mail with a migration tool from the new provider or with an IMAP copy tool.
Don't forget the SPF record when moving email: the new provider needs to be added, and as long as the old one is still sending (for example your website's contact form), it needs to stay in too.

DNSSEC during a transfer

If your domain uses DNSSEC (lesson 8.1), there's a DS record at the registry: a fingerprint of the key your current DNS provider uses to sign the zone. If you move your DNS management, the new provider signs with a different key. If the old DS stays at the registry, the fingerprint no longer matches. Validating resolvers (and there are many) then return SERVFAIL: your entire domain becomes unreachable for them, website and mail alike.

The safe approach:

Have the DS removed at the registry (DNSSEC off) and wait until the TTL of the DS has expired.
Switch the nameservers.
Turn on DNSSEC at the new provider and have the new DS placed at the registry.

There's also a method for transferring without interrupting DNSSEC (temporarily running the keys of both providers side by side), but it requires cooperation from both providers and isn't supported everywhere. If something does go wrong during a transfer and your domain is suddenly unreachable while the records look correct, check DNSSEC first.

In practice: what it looks like in a panel

In the example panel My WebOké, you back up the whole zone on the DNS tab with one button, and restore it with one click if something goes wrong. A transfer of the domain itself starts there in the Transfer Centre, and the Domain / Email health card shows after the switch whether the nameservers, A record, certificate, MX, SPF, DMARC and DNSSEC are correct. Other providers often offer a zone export (sometimes as a zone file you can import with the new provider) and a similar check; if your panel doesn't have that, take a screenshot of the record list.

Summary

First work out what's moving: website, mail, DNS management or registration.
Backup, inventory, setting up and testing the new environment all happen before the switch.
Lower the TTL at least one old TTL in advance, and set it back afterwards.
For a transfer of DNS management, the zone must be complete with the new provider before the nameserver switch; don't forget records like the mail server's A record.
With DNSSEC: remove the old DS first, then switch, then place the new DS.
Check both mailboxes during the switch and only cancel the old service once everything works.

Quiz

Exercise

Exercise Z6.3: Transfer inventory. Make a transfer inventory of your own domain (or, if you don't have a domain, of sidn.nl, the website of SIDN, the registry of .nl in the Netherlands). Look up and fill in: the nameservers, the A and AAAA records of @ and www, the MX records, the SPF record, the DMARC record and whether there's a DS record. The program compares each value with what the DNS currently returns.

Exercise O6.3: Setting it up yourself in your practice zone. Your practice zone <code>.dnspractice.eu contains a small "existing" website: www.<code>.dnspractice.eu points to 192.0.2.10 (A) and 2001:db8::10 (AAAA), with TTL 300. The practice zone's mail is at mail.<code>.dnspractice.eu (192.0.2.25) with an MX record (priority 10). Re-enact a website transfer:

Lower the TTL of the www.<code>.dnspractice.eu records to 60.
Point www.<code>.dnspractice.eu to the new server 198.51.100.10 and remove the AAAA record: the new server doesn't have IPv6.
Set the TTL of www.<code>.dnspractice.eu back to 300.
Leave the mail records untouched.

The practice zone uses short TTLs (between 30 and 300 seconds), so you don't have to wait; on your real domain you'd use, for example, 3600 as the standard and 300 during the transfer.

Exercise O6.3

You'll do this exercise in your own practice zone: a real DNS zone on WebOké's nameservers, just for you. Sign up with your email address. You'll get a login link by email and then come back to this lesson. We only use your address for the course.

Cookies at WebOké

Cookie settings

Necessary

Marketing