Zones, the apex, and subdomains

A zone is the part of the DNS namespace managed together by one authority. A zone for example.com can contain records for the apex and names below it.

The zone apex is example.com itself. DNS dashboards often represent it with @.

A name below the apex is not automatically a separate zone. www.example.com and api.example.com are usually ordinary records inside the example.com zone.

A zone becomes an administrative boundary. Its authoritative servers publish the records in that zone, beginning with required SOA and NS data. The domain name hierarchy and the zone boundaries can therefore differ.

For example, a company can delegate team.example.com to another DNS provider by publishing NS records for that child name. After delegation:

• the parent example.com zone says which servers know about team.example.com
• the child team.example.com zone publishes its own records
• api.example.com can still remain in the parent zone

Dashboard record names are often relative to the current zone. Entering www in the example.com zone creates www.example.com. Entering @ creates data at example.com. Check the provider preview before saving because some interfaces expect a complete name instead.

Use DNS evidence to see whether a child is delegated:

dig NS team.example.com
dig +trace team.example.com

An NS answer obtained from a recursive cache is useful, while a trace shows where the parent sends the lookup.

Your action is to draw one zone containing an apex, two ordinary subdomains, and one delegated child zone. Mark which provider must be changed for each record.