Skip to main content

​
Moving a live domain

The delegation is what proves the zone is yours, which means the moment you point your registrar here is the moment we start answering for it. An empty zone answers with nothing — the site and the mail go down as resolvers pick up the change. So populate it first. Either upload a zone file exported from your current provider (see Importing a zone file), or ask us to read the records ourselves at create time:
That runs in the background — the zone is created immediately. Poll GET /v1/zones/{zone_id}/record-import:
Read complete before you switch your old provider off.source: axfr is a zone transfer: the whole zone, exactly, and complete is true. source: query means we asked for a list of common names, which finds what it thought to ask for and cannot know what it missed. Most providers refuse zone transfers, so query is the usual outcome and complete: false is normal, not a failure.Compare the imported records against your old provider before you decommission it. notes says what we could not establish.
Once you have read the outcome and checked the records against your old provider, DELETE /v1/zones/{zone_id}/record-import puts it away. That discards only the note about where the records came from — the records themselves stay exactly as they are. The console shows the outcome, including the warning above, until you dismiss it. The call answers 204 whether or not there was an outcome to discard. Records you have already created are never overwritten — yours win. Records this platform manages itself (the SOA, the DNSSEC chain, the zone’s nameservers) are never imported, and notes says how many were skipped. A failed import is never a failed zone: the zone exists and works, and you can fill it in by hand or from a zone file.

​
Proving ownership

The delegation is the proof. There is no record to publish. Your zone’s nameservers are not the same as anybody else’s. Each carries a label unique to that zone:
Set those at your registrar, then confirm:
The zone page shows a This zone is not resolving yet card with the nameservers and a Confirm delegation button. It stays until the delegation is in place; press it again whenever you have changed something at your registrar.
Use the names your zone lists, and nothing else. Basaltic’s bare nameserver names — the ones without a label — will not verify your zone. They are reserved for the platform’s own zones.This is the point of the label. Anyone can point a domain at a nameserver we publish, so a delegation naming a shared name shows only that somebody did so at some point — possibly a previous owner who never updated their registrar. A delegation naming your zone’s label can only have been set for your zone, by whoever holds the domain now.
A zone created underneath a zone you already own needs none of this: it inherits its parent’s proof and is verified on creation. Calling verify on one succeeds with nothing to do.

​
Other nameservers alongside ours

Another provider’s nameservers may sit beside yours. We ignore them, and the zone still verifies.
Serving a domain from two providers at once does not work well while the zone is signed, and every zone here is. Our DS record at the registrar covers only the answers we sign, so a validating resolver that happens to ask the other provider gets a signature it cannot verify and fails the lookup — roughly half your queries, unpredictably. Talk to support before setting this up.
What does not work is delegating to two Basaltic zones at the same time. While a domain names your zone’s nameservers and another zone’s, neither is served, and verify tells you so. That is the state to expect midway through moving a domain between accounts — the fix is to remove the ones your zone does not list.

​
Moving a domain between accounts

Several accounts can hold a zone for the same domain. Only one is served: the one the registrar’s delegation actually points at. So handing a domain over is a registrar change and nothing else. The receiving account creates the zone — it is accepted, not refused as a duplicate — and gets its own nameservers. When the registrar points at those and the old account’s names come out, the new zone verifies and the old one stops answering, and its owner is emailed that it happened.
The proof is a lease, not a deed. It is re-confirmed periodically for as long as the zone is served, so a domain that lapses or changes hands stops being served from here.

​
When re-confirmation starts failing

A zone whose periodic re-proof is failing grows an ownership.recheck_deadline — the instant it stops answering unless the check passes again. Absent means healthy. Reaching that date takes sustained failure, not one bad afternoon: every pass re-checks a failing zone, so a transient resolver problem clears itself. Your organization’s owner is emailed when the deadline is set, and again if the zone does stop resolving — a zone is never taken off the air before that message has gone out. To clear it deliberately, point the domain’s delegation back at the zone’s own nameservers and call verify-ownership again. That is the one case where an already-verified zone can answer 400, because there the call runs the check for real.