We now run DNS for zsoftly.ca on the same nameservers we offer customers. Getting there took one registry requirement, one change we did not ask for, and a few hours where our own mail was closer to breaking than I would like.
The blocker
A customer told us they could not delegate their .ca domain to us. Their registrar returned:
Object does not exist. Reason: Create the host on the Registry system
before you assign it to a domain.CIRA, the .ca registry, requires that .ca-based nameservers exist as registered host objects
before any domain can point at them. Our nameservers answered correctly and had been serving other
domains for months, but they had never been registered with CIRA as hosts. That is not something you
can do yourself. The registrar has to do it.
So no .ca customer could delegate to us. DNS hosting on ZCP is free, the way it is with the large
providers, so this was not lost revenue. It was worse than that. It was a Canadian cloud that could
not host a Canadian domain.
What we asked for, and what happened
Only a registrar can create those host records, so we went to ours, GoDaddy.
We spoke to more than three technical support representatives on the DNS support line. None of them could describe the difference between a nameserver host record and a domain’s nameserver setting. Each call produced a ticket number and a promise to call back. On the callbacks, the next agent did not know what we were asking for either, and the ticket number did not carry the context forward.
So we moved to email and chat, where the request is written down and cannot be misheard. We stated the exact operation: register these two names as host objects at the registry. We stated the prohibition just as plainly: do not change the nameservers on zsoftly.ca, it is hosted elsewhere and must stay there.
The host records were created. The domain’s delegation was also changed to point at our own nameservers.
Those are different operations. One adds an entry at the registry so other domains can reference your nameservers. The other decides who answers DNS for your domain. We had named both, in writing, and said which one to leave alone. It was still the wrong change, and it was live.
Why that was nearly an outage
Our nameservers did not host zsoftly.ca. They had no reason to. Asked for it, they answered REFUSED.
Meanwhile the registry was telling the world those were the right servers to ask. Nothing broke immediately, because resolvers had the previous answers cached. As those caches expired, three of the four major public resolvers stopped resolving zsoftly.ca. No website. No inbound mail. The nameserver records carried a 24 hour TTL, so every resolver that picked up the broken delegation would hold it for a day.
We caught it by checking the registry directly rather than trusting that a change described as routine had been routine.
How we handled it
Two things, in parallel.
We reverted the delegation ourselves. The domain was in our account, so this did not need a support queue. That fix was correct but not instant: the registry accepts a change immediately and republishes the zone on its own schedule.
So we closed the gap from the other side. The delegation said our nameservers were authoritative for zsoftly.ca, so we made that true. We built the zone on our own platform and loaded every record. Within minutes the servers answered instead of refusing, and resolution came back everywhere.
That second step is the one worth keeping. When a delegation points somewhere wrong, you can chase the delegation, or you can make the destination correct. The second is usually faster, and it is entirely in your hands.
What we found on our own platform
Loading our own zone under time pressure taught us more about our DNS product than a quarter of planning would have.
TXT records had to be quoted before the API accepted them, and the error said only that the operation failed. A record name and type held one value, so the second mail server replaced the first rather than joining it. Neither is acceptable for a domain that sends mail, and both are now filed as defects with reproductions attached.
None of that is comfortable to publish. It is the honest result of using your own product for something that matters, which is the only test that finds this class of problem.
Where we landed
zsoftly.ca now resolves from our nameservers. Mail routes through all three of its mail servers,
with SPF, DMARC and every DKIM key in place. The .ca host records are registered, so customers can
delegate their .ca domains to us, and one already has.
DNS hosting stays free on ZCP. Zone signing with DNSSEC and other advanced handling are available on request through a support ticket from your account.
We kept the previous DNS host configured and untouched. If we need to move back, it is one change at the registrar to a zone that is still correct. Rollback you have tested beats confidence you have not.
What we would tell someone else
Ask a provider for a change in writing, in terms of the exact operation you want, and say plainly what must not change. We did, and it still happened, but it made the conversation afterwards short.
Check the result at the source. A registry or a nameserver will tell you the truth about your domain. A confirmation email tells you what someone intended.
Lock your domain, and check the lock afterwards. Ours was removed to make the change and not put back. We only noticed because we looked.
And run your own infrastructure on your own platform. It is the fastest way to find the things your customers would have found first.
Do it without the hard part
Most of this article is about the day DNS went wrong. The ordinary case should be boring, and it can be: keep the whole zone in one file, review changes like code, and apply it with a script.
That is how we rebuilt zsoftly.ca under pressure, and it is written up as a tutorial: Manage a DNS zone as a file in version control. The script and the file layout are the same ones we used, with our values taken out.
If you would rather not think about any of it, host the zone on ZCP and let us carry it.