A zone is an area of DNS responsibility
The domain name system is arranged like a tree. A name such as www.example.com sits beneath example.com, which in turn sits beneath .com. A DNS zone is a portion of that tree whose DNS data is administered together by a set of authoritative name servers. Those servers provide answers for names in the zone using its records.
A domain and a zone often appear to match, but they describe different things. A domain is a name and everything beneath it in the DNS tree. A zone is the part of that space managed under one authority. For example, a zone for example.com might contain records for example.com, www.example.com and mail.example.com. It could also contain records for shop.example.com. If shop.example.com is delegated to other authoritative servers, however, it becomes the start of a separate zone. It remains within the example.com domain, but its records are no longer administered as part of the example.com zone.
Where a zone begins and ends
The top name in a zone is called the zone apex. In a zone for example.com, the apex is example.com itself. The zone normally has a Start of Authority (SOA) record and name server (NS) records at that name. The SOA record contains administrative and timing information used by DNS servers. The NS records identify the authoritative servers for the zone.
A zone extends downward from its apex until it reaches a delegation to another zone. Without a delegation, an administrator can generally place records for deeper names in the same zone. For instance, a record for status.shop.example.com could be held in the example.com zone if shop.example.com has not been delegated. Creating a subdomain does not, by itself, create a new zone: delegation is the boundary that changes who provides authoritative answers for that part of the tree.
How delegation hands off responsibility
Suppose the team managing example.com wants a separate team to manage shop.example.com. The parent zone can publish NS records at shop.example.com pointing to the servers that will answer for the child zone. The child zone then has its own apex, SOA record, authoritative NS records and records for its services. The parent retains responsibility for the delegation, while the child’s administrators maintain the data beneath it.
Sometimes the names of the child’s servers are themselves inside the delegated name, such as ns1.shop.example.com. In that case, the parent may also need to provide address information known as glue. Glue helps a resolver find those servers without first having to ask the servers it is trying to locate. It is supporting information for the delegation, not a substitute for maintaining the child zone’s own records.
A recursive resolver follows these boundaries when answering a user’s query. It may be directed from a parent zone to a child zone and then obtain the requested record from the child’s authoritative servers. The user usually sees only the resulting answer, not the administrative handoff.
What an administrator puts in a zone
A zone can contain records with different jobs. A and AAAA records associate names with IP addresses. An MX record identifies mail servers for a name. TXT records can carry text used for purposes such as email authentication, while CNAME records make one name an alias of another. The presence of a record depends on what a service needs; a zone does not need every record type.
Zone data is often edited through a DNS provider’s control panel rather than in a visible zone file. Regardless of the interface, the practical question is the same: which authoritative zone owns the name being changed? If shop.example.com is delegated, adding an address record for www.shop.example.com to the parent’s control panel will not update the child zone that answers for it. Checking the delegation first can save time when an edit appears to have no effect.
Use zone boundaries deliberately
Keeping names in one zone can make routine changes simpler because one administrator or team manages the records together. Delegating a subdomain can be useful when another team or service needs independent control over its DNS records. The trade-off is another set of authoritative servers and records to maintain. Both the parent’s delegation and the child’s zone need to remain consistent for names under the child to resolve reliably.
When troubleshooting, start with the full name that is failing and identify its nearest delegated ancestor. Then check the authoritative servers for that zone and the specific record you expect. If a delegated subdomain does not respond as intended, inspect both sides of the boundary: the NS records in the parent and the records served by the child. Thinking in zones turns a large DNS tree into smaller, clearly assigned areas of responsibility.
