DNS zones

DNS zones and records

Thalassa Cloud DNS zones hold the RRsets that answer queries for a delegated domain. This page covers zone and record management from first delegation through import, export, and publishing behaviour.

Getting started

1. Create a zone

Create a zone for the domain you want to host, for example example.com.

The zone name must be a valid lowercase FQDN without a trailing dot (sub.example.co.uk is valid).

2. Delegate at your registrar

Point the domain’s NS records at your registrar (or parent zone) to Thalassa’s authoritative nameservers for your region.

If you have not added custom NS records inside the zone, the platform injects the configured regional nameservers automatically when publishing. Check the zone export or console zone details for the exact hostnames to use at your registrar (for example ns1.eu-nl-1.thalassa.cloud).

Delegation can take from a few minutes up to 48 hours depending on TTLs and your registrar.

3. Add records

Add the records your services need — apex and www A/AAAA records, MX for mail, TXT for SPF/DKIM/verification, CNAME aliases, and so on.

Each zone allows one record per name and type combination. To change a record’s type, delete it and create a new one.

4. Verify propagation

After saving changes, allow roughly 25–40 seconds before expecting updated answers from authoritative nameservers. Public resolver caches may take longer depending on TTL.

Supported record types

Type	Purpose	Value format
A	IPv4 address	One or more IPv4 addresses, e.g. `192.0.2.1`
AAAA	IPv6 address	One or more IPv6 addresses, e.g. `2001:db8::1`
CNAME	Alias to another hostname	Exactly one hostname, e.g. `cdn.example.com`
NS	Delegation / nameserver	Hostnames, e.g. `ns1.example.com`
MX	Mail exchanger	`"<priority> <host>"`, e.g. `10 mail.example.com`
TXT	Arbitrary text (SPF, DKIM, verification)	Plain text, up to 4096 characters per value; multiple values allowed
CAA	Certificate authority restriction	`"<flags> <tag> <value>"` — tag is `issue`, `issuewild`, or `iodef`
SRV	Service location	`"<priority> <weight> <port> <target>"`, e.g. `10 5 5060 sip.example.com`

Record name rules

Name	Resolves to
`@`	Zone apex (`example.com`)
`*`	Wildcard (`*.example.com`)
`www`	`www.example.com`
`_acme-challenge`	`_acme-challenge.example.com`
`_sip._tcp`	`_sip._tcp.example.com`

Names are stored lowercase. Labels may contain letters, digits, -, and _. Maximum 63 characters per label, 253 characters total.

TTL

Time-to-live defaults to 3600 seconds (one hour) when not specified. Allowed range: 1–86400 seconds.

After create, a record’s name and type are fixed. Only TTL and values can be updated.

Import and export

Zones support BIND-format zone files for migration and backup.

Export

Download the current zone as a standard BIND zone file. The export reflects records stored in the platform (SOA and injected NS lines follow the publish format).

Import

Upload a BIND zone file to upsert records:

Merge (default) — records in the file are created or updated; existing records not in the file are left unchanged.
Replace — set replaceExisting: true to delete any records in the zone that are not in the imported file.

Import notes:

Supported types in zone files: A, AAAA, CNAME, NS, MX, TXT, CAA, SRV
SOA, PTR, DS, and other types are skipped (counted in the import response)
$ORIGIN must match the zone domain when present
Multiple lines for the same name and type are merged into one RRset

How publishing works

You create or update a record in the console or API
        │
        ▼
Platform stores the change and renders a complete RFC 1035 zone file
        │
        ▼
Zone file is published to authoritative DNS in each enabled cloud region
        │
        ▼
Regional nameservers begin serving the updated zone (~25–40 seconds)

SOA and default NS records are added automatically when your zone does not define its own NS records. You do not manage SOA serial numbers manually.

DNSSEC

Zones can optionally be signed with DNSSEC. Signing uses a regional KMS asymmetric key; DS records for parent-zone delegation are returned in the DNSSEC status API.

When DNSSEC is enabled, signed answers are published only after a matching DS record is visible at the parent delegation point. Until then the zone continues to be served unsigned.

See DNSSEC for enabling signing, DS delegation at your registrar, and KMS key integration.

DNSSEC requires both the dns and kms feature gates on your organisation.

Deleting a zone

Deleting a zone permanently removes all records in that zone, then removes the zone itself. This cannot be undone. Confirm carefully before deleting production domains.

The zone is also removed from regional authoritative nameservers on the next sync.

Limits and behaviour

Topic	Detail
Zone rename	Not supported — create a new zone and migrate records
Duplicate records	One record per `(zone, name, type)` — duplicates return a conflict error
Unsupported types	`PTR`, `SOA` (tenant-managed), `DS` (via DNSSEC status instead), and others are not available as tenant records
Multi-region	Zones are published to every enabled regional DNS endpoint
Access control	See Access control — record operations require permissions on both zone and record
API	See API reference — base path `/v1/dns`