Import a zone file
Load an RFC 1035 master file — a BIND zone file, the format every DNS provider exports — into an existing zone.
Merges, never replaces. An RRset in the file replaces the RRset at the same name and type wholesale; an RRset the file does not mention is left exactly as it is. So an import cannot delete a record, and importing the same file twice is a no-op rather than an error — which is what makes it safe to retry.
All or nothing. The whole file is validated before any record is
written: every record has to pass the same type, name, TTL and rdata
checks createRecord applies, the same CNAME-coexistence rule, and the
same per-zone and per-org record quota. One bad record refuses the file
and the zone is untouched.
What is skipped rather than imported. The SOA and the apex NS set are
the platform’s: the zone is served by our nameservers, and the apex NS is
what the parent delegates to. The DNSSEC records (RRSIG, DNSKEY,
DS, NSEC, NSEC3, NSEC3PARAM, CDS, CDNSKEY) are generated by
our signer from keys your file cannot know. Records the file places
outside this zone are skipped too. All of them come back in skipped
with a reason — a file exported from a signed zone carries every one, so
refusing the file over them would make export/import unusable.
The file may be sent as JSON (zone_file) or as the raw request body
under any other content type, so curl --data-binary @db.example.com
works directly. Maximum 1 MiB.
On success the zone’s SOA serial advances once for the whole import and the change propagates to the authoritative nameservers.
Authorizations
BASALTIC-HMAC-SHA256 request signing for service-account (access-key) auth.
An AWS-SigV4-style scheme: an HMAC-SHA256 over a canonical request, keyed by a
signing key derived from your secret access key. The basaltic CLI does this
for you; the steps below are for a non-CLI client.
Headers you send
Authorization(this scheme) — format below.X-Date: request time in UTC, compact ISO-8601 basic:YYYYMMDDTHHMMSSZ(e.g.20240115T103000Z). Must be within 5 minutes of server time.X-Nonce: random per-request value (e.g. 16+ bytes of hex). Required — it is what makes each signature unique so the server can reject replays.X-Datealone is not enough (one-second resolution;UNSIGNED-PAYLOADnever enters the canonical request).X-Content-Sha256(optional): lowercase-hex SHA-256 of the request body, to bind the exact bytes to the signature — the server re-hashes and rejects a mismatch. Omit it, and put the literalUNSIGNED-PAYLOADin the body-hash slot, for an empty body or a streaming upload that shouldn't be buffered.
Authorization header format
<date>:YYYYMMDD(the day part of X-Date).<region>: target region code (e.g.sa-saopaulo-1), orglobalfor the region-agnostic (IAM) endpoints.<service>:basaltic.SignedHeaders: the covered header names, lowercased and sorted, joined by;— at minimumhost;x-date;x-nonce(all three required).Signature: lowercase hex from step 4.- Note the
,(comma + space) between the three Authorization parameters.
Step 1 — canonical request
Join these six lines with \n (LF):
canonical-path: the URL-escaped request path (e.g./v1/compute/instances).canonical-query: each query key and value URL-encoded, sorted by key then value, joined by&; empty string when there is no query.canonical-headers: for each signed header,name:value(name lowercased, value trimmed), sorted by name, each followed by a trailing\n.signed-headers: the same names, lowercased, sorted, joined by;.body-hash: lowercase-hex SHA-256 of the body, or the literalUNSIGNED-PAYLOAD.
Step 2 — string to sign
Join with \n:
The second line is the credential date at midnight — NOT the X-Date value — and the third is the credential scope without the access-key id.
Step 3 — derive the signing key (HMAC chain over your secret)
Step 4 — signature
Example (POST with a JSON body)
Request validity
- Valid for 5 minutes from the X-Date timestamp.
- The signature must cover at least
host,x-date, andx-nonce. - Mutating requests (POST/PUT/PATCH/DELETE) that present a signed nonce are
anti-replay guarded for the drift window; omitting
X-Nonceis rejected.
Rate limits
There is no global request budget: a limit applies only where an operation
documents a 429 response, and each such endpoint counts its own fixed
window. Everything else is bounded by quota, not by request rate.
Per-endpoint request limits
A few endpoints are limited in front of the handler, counted per caller —
the authenticated principal when the request carries credentials, the
client IP otherwise. On this API surface that is the public region
catalogue, GET /v1/regions: it guards no secret, and the budget is there
because the catalogue is unauthenticated and database-backed.
An operation that is limited says so by documenting a 429. These
responses — 429 and 2xx — carry the budget, so a client can pace
itself instead of discovering the ceiling by hitting it:
X-RateLimit-Limit— requests allowed per window on this endpoint. Authoritative: read it rather than hard-coding a number.X-RateLimit-Remaining— requests left in the window (0 on a 429).X-RateLimit-Reset— seconds until the window resets. A duration, not a timestamp, so it needs no clock agreement.Retry-After— on a 429 only; seconds to wait. Never zero.
Over the limit the response is 429 with error code RATE_LIMITED. Honor
Retry-After — retrying sooner is refused and extends the window, since
the refused attempt is itself counted.
Service-level limits
Some resources meter the work itself rather than the request, and are
documented on the operation. They return 429 with their own error code
and no rate-limit headers, because the budget is not a per-endpoint window:
sending email is capped per (account, identity) per second
(EMAIL_RATE_LIMIT), and charge attempts are capped per invoice
(INVOICE_PAYMENT_ATTEMPTS_EXHAUSTED).
Headers
Optional client-generated key that makes a create replay-safe. Retrying a request with the same key returns the original outcome verbatim instead of creating a duplicate resource. Reusing a key with a different request body is rejected (422); a request whose key is still being processed returns 409. Records are honored for 24 hours. Use a UUID or similarly unique token.
255Path Parameters
DNS Zone ID
Body
The zone file, as text. $ORIGIN, $TTL, $GENERATE, relative names
and parenthesised multi-line records are all honoured; $INCLUDE is
refused, because the path it names would be read on our filesystem
rather than yours.
"$ORIGIN example.com.\n$TTL 3600\nwww IN A 203.0.113.10\n@ IN MX 10 mail.example.com.\ndkim IN TXT \"v=DKIM1; k=rsa; p=MIIBIjANBgkqh\"\n"
Response
The file was imported. Read skipped before concluding the zone
matches the file.
What the import did. records_created plus records_replaced is every
RRset taken from the file; anything in skipped is still in the file but
not in the zone.