> ## Documentation Index > Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt > Use this file to discover all available pages before exploring further. # Proving ownership > How a zone starts answering: the per-zone nameservers, moving a live domain, and moving one between accounts. ## 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](/dns/zone-files#importing-a-zone-file)), or ask us to read the records ourselves at create time: ```bash theme={null} POST /v1/zones { "name": "example.com", "import_existing_records": true } ``` That runs in the background — the zone is created immediately. Poll `GET /v1/zones/{zone_id}/record-import`: ```json theme={null} "record_import": { "state": "complete", "source": "query", "complete": false, "found": 14, "imported": 11, "notes": ["asked 261 names; a record whose name is not in the common list was not found and is not imported"] } ``` **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: ``` 028t5cy4tqkff.triton.dns.basaltic.cloud 028t5cy4tqkff.proteus.dns.basaltic.cloud ``` 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. ```bash theme={null} POST /v1/zones/{zone_id}/verify-ownership ``` Idempotent, so you can poll it. **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.