Subzones

A subzone groups entries under a shared name inside a managed zone. If you maintain many names under dev.example.com, customer-a.example.com or internal.example.com, you get a page of their own instead of one long list where everything sits side by side.

What a subzone is — and is not

What actually happens: the entry www in subzone dev is the record set www.dev of zone example.com. At the provider there is an ordinary entry www.dev.example.com — DNS as usual, just sorted differently.

in subzone `dev`	in the zone	at the provider
`@` A	`dev` A	`dev.example.com`
`www` A	`www.dev` A	`www.dev.example.com`

So a subzone has an apex of its own: @ there means the subzone’s own name. That is correct DNS — a name may carry records and have children at the same time.

Because nothing is delegated, subzones work with every supported provider, including those whose API cannot create zones at all.

Creating one

Two ways, same result:

Zone overview → Create subzone — pick the parent zone, type a name. The dialog shows the resulting full name live.
Inside a zone (or subzone) → Create subzone — the new one is placed below the open one.

The name is one name part, without a dot. For deeper levels create the parent subzone first and the next one below it — otherwise the tree would have a hole. Up to two subzone levels are possible — three levels in total counting the zone: sub2.sub1.example.com still works, one step deeper does not.

Existing entries do not move. If www.dev already exists when dev is created, that entry now appears in the subzone instead of the zone list. It is not changed, and nothing is written at the provider — only the view is reorganised.

In the overview

Subzones sit indented below their zone. The control on the left collapses a zone and hides its subzones; that state survives page changes.

The Entries column shows a zone’s total number of record sets — what stands at the provider, subzone entries included. The dimmed numbers of the subzones below it are a breakdown of that, not a second total.

Inside the zone

If a zone has subzones, they are the first rows of the record table. Their entries are not visible at first — one click expands them, indented and with their own propagation light. Editing takes you into the subzone.

A name owned by a subzone cannot be created at zone level: the input is rejected and offers a jump into the responsible subzone. Import and drift adoption are exempt — rejecting there would do harm, so the entry lands in the subzone.

The subzone page

Built like the zone page, with a breadcrumb back to the zone. Names are relative to the subzone: www means www.dev.example.com.

Available: create and edit record sets, apply templates, check propagation and create further subzones.

Not available, because it belongs to the zone: nameservers (apex NS), DNSSEC, provider migration, removing from management, zone-file export/import, drift and the history. A note at the foot of the page says so.

Sync groups and templates

A subzone can be a member of a sync group, just like a zone. In the member picker it sits indented below its zone. The group’s sets then land under their mapped name — a set www reaches www.dev.example.com.

The same goes for templates: they can be stamped onto a subzone.

Entries a group maintains are marked in the subzone just as they are in the zone: the row carries the ⟲ reference to the group and takes you there. Such an entry is edited in the group, not in the subzone — otherwise the next enforcement run overwrites it.

In the inventory

The inventory knows about subzones: in the overview they sit indented below their zone, and a search hit names the subzone as its location rather than the zone — with the name relative to it. The click goes into the subzone accordingly.

Deleting

When deleting a subzone a checkbox decides what happens to the entries:

Default — keep: only the namespace disappears. The entries reappear under their full name in the zone list; nothing happens at the provider.
Delete entries too: every entry of the subzone is removed — in the desired state and at the provider. The dialog names the count.

A subzone with nested subzones only falls together with them. If the zone is removed from management its subzones go with it; the entries at the provider stay untouched.

Limits

No permissions of their own. A grant applies to the zone and covers its subzones. Handing out a single subzone to a team is not possible.
No own DNSSEC, no own SOA, no own provider account.
No renaming. Deleting with “keep entries” and creating anew gives practically the same result.
Subzones do not count against any plan limit — they are not zones.