A DNS zone is the portion of the DNS name tree for which a particular set of authoritative nameservers holds the data. It begins at a named point, called the zone apex, and includes the names beneath it except where authority is delegated to child zones. A zone with no delegated children covers the entire domain subtree beneath its apex.

For example, an operator may manage a zone named example.com that contains records for www.example.com and mail.example.com. If the operator delegates team.example.com, that name becomes the apex of a separate child zone. Records such as the address of app.team.example.com then belong in the child zone.

Domain Names and Zone Boundaries

A domain is a subtree of the DNS namespace rooted at a domain name. A zone is the part managed under one authority, excluding any delegated child zones. The example.com domain therefore still includes team.example.com and its descendants after delegation, even though their authoritative records are managed separately.

Calling a name a subdomain does not tell you whether it has its own zone. The name shop.example.com can have records in the example.com zone, or it can be the apex of a delegated shop.example.com zone. Creating a record with an extra label does not itself delegate authority.

Zone boundaries are not fixed at a particular number of labels. The root zone has the root name as its apex and contains delegations to top-level zones such as com. The com zone can delegate example.com, which can delegate team.example.com in turn. Each delegation assigns responsibility for a smaller part of the name tree.

The Zone Apex Marks the Start of Authority

The zone apex is the top name of a zone. It has exactly one SOA record and NS records identifying the zone's authoritative nameservers. In an example.com zone, the apex is example.com, not www.example.com. The SOA carries administrative fields such as the zone serial and timer values.

Authoritative nameservers answer using the zone data they publish. A recursive resolver instead obtains answers for clients, following delegations or using another resolver, and can cache the results. A cached response can temporarily differ from the current authoritative data after a record changes.

The same zone can be served by multiple authoritative nameservers. They serve the same portion of the namespace even when they have different hostnames or addresses. If servers intended to publish identical data return different values, check whether all of them received and published the update. A difference between servers does not by itself establish a new zone boundary.

Delegation Creates a Child Zone Boundary

Delegation places NS records at the child name in the parent zone. Suppose the example.com zone delegates team.example.com to a team's nameservers. The boundary between those zones is called a zone cut, and the child zone begins at team.example.com. The parent retains the delegation information, while the child publishes its own SOA, authoritative NS records, and application records.

A resolver looking for app.team.example.com can receive a referral from the parent directing it to the child nameservers. The referral puts the child's NS records in the response's Authority section. It does not supply an authoritative address answer for app.team.example.com from the parent zone.

The parent delegation and the child apex NS records should identify the same nameservers. Differences can occur during a provider change or through configuration errors, and some resolvers may reach servers that others do not. Public resolvers will not automatically use a child zone just because you create it at a DNS provider. The parent must publish the delegation, and the listed nameservers must be configured to serve the child.

Glue and DNSSEC at a Delegation

If the delegation points to ns1.team.example.com, a resolver needs that server's IP address before it can ask the server about the child zone. The parent can provide an A or AAAA address record for the nameserver to avoid this circular dependency. This address information is called glue and appears in the referral's Additional section. Glue is not authoritative address data from the parent zone.

The corresponding authoritative address record belongs in the zone that contains the nameserver's name. Glue and that authoritative address need to remain consistent when the nameserver's address changes. If the nameserver is in an independently reachable zone, its address can be resolved there without this dependency on the child being delegated.

DNSSEC uses digital signatures to authenticate DNS data and adds another type of record at a delegation. A DS record in the parent can link to a DNSKEY public key in the signed child zone. The DS record is authoritative data from the parent, even though its owner name is the child's apex. Check both the record type and the name to determine which zone supplies the authoritative data.

Zone Records and Zone Files

A zone can contain address records, mail routing records, aliases, and other application-specific data within its authority scope. Those records have different functions even when they share a name. For example, an address record at example.com can support a website while an MX record at that same name identifies a mail server.

A zone file is one possible text representation of zone data. In the master-file format, relative names are interpreted using a current origin. With $ORIGIN example.com., a record whose name is written as www applies to www.example.com. A name ending in a dot is already complete and does not have the origin appended.

The origin can change within a file, allowing records for a group of related names to be written more briefly. This changes how the text is interpreted, not the zone's delegation boundary. For example, setting the origin to team.example.com. inside the parent file does not create a separate team.example.com zone.

Managed DNS services may store and display records through a database or web interface instead of exposing a zone file. A saved file or control-panel entry affects DNS answers only when the authoritative service loads or publishes the change. File syntax, service configuration, and published DNS answers are separate things to check if an expected update is missing.

Identify the Zone before Editing a Record

For a missing or stale answer, first identify the exact fully qualified name and record type. Follow the parent delegation to the nameservers responsible for the relevant zone, then query the intended zone's SOA directly at those servers. An authoritative SOA answer for that apex confirms that the queried server is serving the zone.

Next, compare the requested record with the records published in that zone. Adding an ordinary host record below a delegation in the parent does not override the child's answer. Such data can remain stored in the parent but be hidden from ordinary lookups by the delegation. If the zone's configured data contains the change but the queried server does not return it, check publication and synchronization before treating the difference as a resolver cache issue.