A DNS verification reproduction & postmortem

Synopsis:

A client's .ca domain went dark right before a campaign launch. The cause wasn't a misconfigured record or an expired registration; it was a registrant verification email sent to an inbox we no longer controlled. The email's domain had lapsed, the link was never clicked, and the domain quietly fell out of DNS. We didn't know until the client called. Here's the full chain, why CIRA couldn't fix it, and what finally did.

The single fact that explains this entire incident: the registry and the registrar are different parties, and only one of them can touch your contact email.

• CIRA: the registry authority. Manages the .ca ccTLD database and sets policy. It does not sell domains and cannot edit a registrant record held at a registrar.
• Cloudflare: the registrar. Sells and manages the registration, and owns the registrant contact data. Runs .ca through a back-end partner, which matters later.
• Us / the client: the registrant. The legal holder.

The trap is in the data flow: contact changes are entered in the registrar's system first, then forwarded to the registry. There is no path that runs the other way.

The reproduction

And that's exactly where it bit us. The registrant email wasn't one we picked at registration, Cloudflare auto-populated it from an older account record we didn't know was still active. We'd switched our account contact to @acorninteractive.ca long ago, or thought we had. But at the moment the domain was registered, the system silently stamped the stale acornmade.com address onto the registrant field instead. From there the failure chain was short and entirely silent:

• The registrant contact on file used an email at acornmade.com.
• That domain had expired the inbox behind the address was dead.
• CIRA's registrant contact verification email landed there, unread.
• With no click on the link, the domain failed verification and was suspended and pulled from DNS.
• No bounce surfaced to us, so there was no signal anything was wrong — until the client phoned to say their site was down.

Diagnosis

We confirmed Cloudflare as the registrar of record and called CIRA directly. CIRA was helpful but had its hands tied by Cloudflare's configuration, exactly as the data-flow rule predicts. The root cause was now unambiguous: a verification email pointed at a lapsed domain's inbox, with no self-serve way to redirect it.

The escalation

1. We CC'd CIRA on the Cloudflare ticket so both sides shared a paper trail.
2. On the free plan, there was no live channel — and a weekend queue meant ~24–48 hours of silence.
3. We bought a Cloudflare Business plan ($300 CAD) purely to unlock chat support.
4. Chat understood the issue fast, but said registration/contact changes were a back-office (accounting) matter — the agent could escalate internally but not intervene directly on the record.

The fix

Roughly 24–48 hours after the escalation, Cloudflare updated the configuration on our registration so we could supply a resolvable registrant email (@acorninteractive.ca). With a live inbox in place:

1. the verification email was re-sent and actually received,
2. we completed verification, the suspension lifted, and
3. the domain resolved again — in time for the client's campaign.

Takeaways

A short outage with a long list of preventable causes:

• Never use a client- or project-scoped domain as a registrant contact. Use a stable, agency-owned, resolvable address.
• Audit registrant/admin contacts across every managed domain — especially after anything in your portfolio lapses.
• Verification failures are silent. Add external DNS/uptime monitoring so the client is never your alerting system.
• Know your registrar's support tiers before an outage forces the decision.
• Document the registry-vs-registrar boundary so the next person doesn't burn hours calling the party that can't help.

Special thanks to all of the wonderful people at CIRA and Cloudflare who hand held us through an unexpected bout of turbulence on our end. Five stars!