Moved a small site to a new host last month, changed the nameservers because the new host told me to, and took the client's email down for most of a day. I now understand that I did that to myself and I still do not have a rule I trust for next time. Three sites to move in the next month and I would like to not repeat it. Where do you put the zone and why?
Concretely, the records that carry email are MX plus the TXT records for SPF and DMARC, and usually a DKIM record on a selector subdomain. If you rebuild a zone from scratch and only copy the MX because that is the one everyone knows, mail flows but starts landing in spam a week later and nobody connects the two events. Copy all of them, then send a test message to something that shows you the authentication results before you consider the move finished.
Add a step to your migration checklist: before you change anything, run a lookup for the A, AAAA, MX, TXT, CNAME and NS records and paste the output into the ticket. It takes two minutes and it means the rollback is copy and paste rather than archaeology.
One thing to know before you consolidate everything at an at-cost registrar, because it is the sort of detail that only bites later: domains registered through Cloudflare Registrar have to use Cloudflare nameservers, and their own documentation says you cannot switch to another DNS provider's nameservers while the domain is registered there. That is completely fine if you were going to use their DNS anyway, and it is a real problem for a client whose IT department runs their own DNS and wants the zone on their infrastructure. Decide that before the transfer, not after.
This is the correct caveat and it comes up constantly. For my own things it is irrelevant. For client work where somebody else may inherit the setup, I keep the registrar and the DNS separable on principle.
Disagreeing slightly with keep DNS at the registrar. I keep DNS wherever I make the most changes, which is the CDN in front of the site, because that is where I am already logged in during an incident and where the proxying features live. The registrar is a place I visit once a year. The important part of the rule is that it is a deliberate choice and it is written down in the client's handover doc, not which company wins.
Numbers for the mechanics. Drop the TTL on the records you are going to change to 300 seconds at least a day before the move, and importantly do it before the old TTL has expired, which means planning further ahead than feels necessary. Make the change, verify, then put the TTLs back up. My eight hour outage was caused by a 24 hour TTL on records I changed at 9am, so the fix propagated at the speed of yesterday's decisions.
@clickertrainbee · 3mo ago · 3 replies
The mental model that fixes this: the registrar is who you rent the name from, the nameservers say which company answers questions about the name, and the records inside the zone point at whoever runs each individual service. Those three are completely independent and can be three different companies.
When you change nameservers you are not moving the website, you are replacing the entire answer sheet. The new host's answer sheet has an A record for the site and nothing for mail, so mail stops.
My rule: pick one DNS provider deliberately, keep every zone there regardless of who hosts what, and never let a host talk you into moving nameservers as part of an onboarding wizard. Export the zone before you touch anything.
Reply
Report
@null_pointer_ok · 3mo ago
Replacing the answer sheet rather than moving the site is the sentence I needed a month ago.
Reply
Report
@muslin_mira · 3mo ago
The export before you touch anything step is the one to institutionalise. Save the zone file into the client folder. It has saved me twice when a host wiped records during a migration.
Reply
Report