1. List the account's zones and check whether the intended domain already has a managed zone.
2. Confirm the account has the relevant hosting, domain, addon or other DNS entitlement.
3. POST the full zone_name, optionally the owned registered-domain reference, a supported zone_type and permitted default_ttl.
4. Store the returned zone public ID. Inspect its package and provider binding evidence.
5. Follow any related task until provisioning is verified, then read the zone and records again.

A basic request has the shape:

{
  "zone_name": "example.com",
  "zone_type": "master",
  "default_ttl": 3600
}

Use your own authorised domain. A secondary or another mode requires the corresponding package and provider support.

No. A created local resource is not proof that every remote replica has finished or that the registrar delegates to this DNS service. Verify the provider records and authoritative answers, then prepare the correct nameserver change through the separate registrar workflow.

This route chooses an eligible package and binding through the supported service path. It is not a shortcut for assigning an arbitrary provider, bypassing limits or taking over another client's existing zone.

The zone detail response embeds bounded lists: up to 250 records, 50 bindings and 50 drift entries. Use the dedicated record or drift collection when you need a larger inventory. If creation or a provider response is uncertain, inspect the existing zone and original task before retrying with the same idempotency identity. Avoid creating duplicate zones to work around a missing binding.

• Track DNS jobs without mistaking a queued task for a published answer
• Build and validate a reviewable DNS changeset
• Build a DNS package for hosting products, addons and domain TLDs
• Add a domain registered elsewhere to your DNS Manager