DNS Zones Explained: Zone vs Domain, Delegation, SOA

A DNS zone is a portion of the DNS namespace that is managed by a specific set of authoritative name servers. It is defined by the zone file, which contains the resource records for that portion. The most common confusion is between a zone and a domain. A domain is a node in the DNS tree, such as example.com. A zone is a contiguous part of that tree that is delegated to a set of name servers. A zone can cover a single domain, a domain and its subdomains, or even a subdomain alone if delegation is configured. For instance, the domain example.com might be split into two zones: one for example.com itself, and another for sub.example.com, with the latter delegated to different name servers. The zone is the administrative unit: it defines the boundary of authority. The name servers that are authoritative for a zone are listed in the zone’s SOA record and NS records.

The SOA Record and Zone Transfers

The Start of Authority (SOA) record is the first record in a zone file. It contains the primary name server for the zone, the email address of the administrator, a serial number, and timers for refresh, retry, expire, and negative caching. The serial number is critical: it is used by secondary name servers to determine when to request a zone transfer. When the serial number on the primary increases, secondaries know the zone has changed. A zone transfer is the process by which a secondary name server obtains a copy of the zone from the primary. There are two types: AXFR (full transfer) and IXFR (incremental transfer). AXFR transfers the entire zone, while IXFR transfers only the changes since the last version. Zone transfers are essential for redundancy: they ensure that all authoritative name servers for a zone have identical data. Without them, changes made on the primary would not propagate to secondaries, causing inconsistent responses.

Delegation and How It Works

Delegation is the mechanism by which authority for a subdomain is assigned to a different set of name servers. In the parent zone, a set of NS records points to the name servers that are authoritative for the child zone. For example, if sub.example.com is delegated to ns1.sub.example.com and ns2.sub.example.com, the example.com zone contains NS records for sub.example.com that list those servers. Additionally, glue records (A or AAAA records) for those name servers must be present in the parent zone if the name servers are within the delegated subdomain. This is necessary to avoid a circular dependency: a resolver querying for sub.example.com needs to know the IP address of ns1.sub.example.com, but that address is in the child zone, which is authoritative for it. Glue records break the loop. Delegation is what allows the DNS to be distributed: no single server holds the entire namespace.

Forward and Reverse Zones

Forward zones map names to IP addresses. They are the typical zones people think of, such as example.com containing A and AAAA records. Reverse zones map IP addresses to names using the in-addr.arpa domain for IPv4 and ip6.arpa for IPv6. For example, the reverse zone for the network 192.0.2.0/24 is 2.0.192.in-addr.arpa. Reverse zones are used for reverse DNS lookups, which are often required for mail servers to verify the sending host’s identity, and for logging and troubleshooting. The structure of a reverse zone is different: the records are PTR records that map the reversed IP address to a hostname. Reverse zones are often delegated differently than forward zones, sometimes to the ISP or hosting provider, because the organization may not own the IP address block.

Zone vs. Domain: The Distinction

What People Get Wrong About DNS Zones

A common misunderstanding is that a domain and a zone are the same thing. This leads to confusion when a subdomain is delegated: people expect the parent zone to contain records for the subdomain, but it only contains NS records pointing elsewhere. Another mistake is thinking that zone transfers are automatic and immediate. In reality, they depend on the SOA timers and the serial number. If the serial number is not incremented, secondaries will not pick up changes. Also, some believe that reverse zones are managed by the same authority as forward zones, but often they are not, especially for IP blocks owned by ISPs. These are natural mistakes because the DNS hierarchy is often visualized as a tree, and a zone is a contiguous slice of that tree, but the administrative boundaries do not always align with the domain boundaries.

How to Inspect Zones

To see the SOA record and NS records for a zone, use nslookup or dig. For example:

nslookup -type=SOA example.com

This outputs the SOA record, including the serial number and timers. To see the NS records:

nslookup -type=NS example.com

To check if a zone transfer is allowed (which is a security risk if it is), use dig:

dig AXFR example.com @ns1.example.com

If this returns the zone data, the server allows zone transfers to anyone. This is usually misconfigured; zone transfers should be restricted to authorized secondaries.

Conclusion

Understanding zones is fundamental to managing DNS. The key is to remember that a zone is an administrative boundary, not a naming boundary. Delegation, SOA records, and zone transfers are the mechanisms that make the distributed DNS work. Forward and reverse zones serve different purposes and are often managed by different entities. With this knowledge, you can predict how changes propagate and why certain records are where they are.