On the morning we launched this website, we moved our own DNS to a new provider. The site came up fine. What went down were three of the links we send to clients — proposals, contracts and booking — for ninety-two minutes, on the same day we were inviting people to come and look at the new site. The checklist we followed is the one we would have recommended to anybody. Here is the step it was missing.
1. The diff was clean because we compared the list against itself
Before handing the domain over we did the responsible thing: query every record against the old nameservers and the new ones, and confirm the answers match. Sixteen name-and-type pairs checked. Sixteen identical. Zero differences. On paper the new zone was a faithful copy and it was safe to throw the switch.
It was not a faithful copy. Eight records were missing outright, and we learned that after the switch rather than before it.
The flaw is easy to state and easy to miss: we had built the comparison list ourselves, by probing the record names we expected to find. Diffing that list against the new zone proves our guesses copied across correctly. It proves nothing whatsoever about records we never thought to guess. The clean result felt like verification. It was closer to a tautology.
The new provider's automated scan did better than our probe, and still did not find everything. Between the scan and two rounds of manual probing we reconstructed twenty-seven records. The zone held thirty-two.
2. The website was never the part at risk
It is worth being precise about what broke, because it is not what people picture when they hear that a DNS migration went wrong.
The website was fine. The apex and the www hostname were the two records everyone was watching, and they moved exactly as planned. What broke were the quiet subdomains hanging off the same zone: the host serving every tokenised proposal link we have ever sent, the host serving contract review and e-signature pages, and the host behind our booking links.
None of those appear on a homepage. None of them show up in a rank tracker. Every one of them is a link sitting in somebody's inbox right now, and a dead one reads as “this company is broken” at the exact moment a person was interested enough to click.
A client noticed while it was happening and replied to an old thread to say the links would not open. That is the good outcome. Most people who hit a dead proposal link do not write in to tell you. They simply do not reply, which is indistinguishable from ordinary silence.
3. The record no amount of guessing would have found
When the departing provider's own export of the zone finally arrived, it listed five more records that the scan and both rounds of probing had missed. One of them settles the argument permanently.
Our transactional email provider signs mail with a key published under a selector name that is a timestamp — a fourteen-digit string recording the moment the key was generated. There is no documentation you could read, no naming convention you could follow and no wordlist you could run that would produce it. It is unguessable by construction.
That record signs every automated email the business sends, including the form notifications from this website. Losing it would not have bounced anything. Our DMARC policy is set to monitor rather than reject, so unsigned mail still gets delivered. It would have surfaced weeks later as a slow, unattributable decline in deliverability — the kind of thing you notice in November and trace back to August only if you are lucky.
4. “This site can’t be reached” is a DNS error
Two things worth knowing if you ever have to field this.
When a hostname has no record at all, a browser does not show a 404 or a certificate warning. Chrome renders it as “This site can’t be reached.” That phrasing sounds like a connection problem, which makes it very easy to write off as the other person’s wifi. If a client reports those exact words about a link you host, check whether the hostname resolves before you check anything else.
And the fix does not take hold the moment you make it. A resolver that has already cached the “no such name” answer keeps serving it — in our case for up to thirty minutes after the record was restored, plus whatever the person’s own machine and browser were holding. “It’s fixed” and “the client can open it” are not the same moment. An all-clear that does not say so invites somebody to retry, fail again, and stop believing the next one.
The rule we run now
On any DNS migration, the departing provider’s own export of the zone is a hard gate before the nameserver change. Not a scan. Not a probe. Not a diff against a list you assembled yourself. Those three techniques, used together and carefully, still missed thirteen of thirty-two records here.
There is a tempting shortcut called a zone transfer — asking the nameserver to hand over the whole zone at once. Try it, by all means. Ours refused, and most will, which leaves exactly one complete source: the control panel of the provider you are leaving. Get the export first. If you cannot get the export, you do not yet know what you are moving.
We are publishing this one because the failure is unusually instructive, and because we would rather tell you about it plainly than have it come up some other way. The new website went live and looked good. Three links that mattered more were dark for an hour and a half.