Skip to main content

Limits and behaviour

1 MiB
Larger files are refused.
quota-enforced
Checked on both single-record creation and import, against your organization’s quota.
60–604800 seconds, default 3600
Omit it, or send 0, to get the default of one hour. Any other value below the 60-second minimum is refused — 0 is a sentinel meaning “use the default”, not the bottom of the range, so 30 is an error where 0 is not.On update that sentinel does not apply: 0 is refused there, because a PATCH that sends it is asking for a TTL of zero rather than declining to choose.The maximum is 604800 (7 days).
202, runs in the background
Deletes every record it owns, plus the zone’s DNSSEC key material and the DS at its parent — the zone row goes last, so nothing is ever left half-removed.The call answers 202, not 204: the teardown is accepted, not finished, and the zone still exists when it returns. Poll GET /v1/zones/{zone_id} until it 404s. That matters if you mean to re-create the same name — until the teardown completes, creating it again answers 409.

Troubleshooting

Check ownership.verified. A zone with no zone above it on the platform does not answer until ownership is proved — creating it is not claiming it. Set the zone’s own nameservers at your registrar and call verify-ownership; see proving ownership.
Two things do this.You used Basaltic’s bare nameserver names rather than the ones your zone lists. Only the labelled names verify a zone — compare what is at your registrar against the nameservers array character for character.The domain is delegated to two Basaltic zones at once. While that is true neither one is served, and the verify message says so. Remove the nameservers your zone does not list. Expect this midway through moving a domain between accounts.
The delete is still running. DELETE answers 202 and the teardown finishes in the background, dropping the zone row last — so for a few seconds the name is still taken. Poll GET /v1/zones/{zone_id} until it 404s, then create.
That pattern — works for non-validating resolvers, fails for validating ones — is the signature of a CNAME sharing a name with another record. The API refuses new ones, but a zone imported or migrated in unusual ways is worth checking. List the records at that name and make sure the CNAME is alone.
Almost always a missing or stale DS record at the registrar. Compare what the registrar publishes against dnssec.ds_records on the zone — a DS left over from a previous provider breaks validation exactly as thoroughly as none at all.
Working as intended — import merges and never deletes. An RRset absent from the file is left alone. Delete records explicitly through the record endpoints.