What Is a DNS Zone?

A DNS zone is a portion of the DNS namespace that is managed by a specific organization or administrator. It contains the DNS records for a domain and optionally some or all of its subdomains. Zones are the fundamental unit of DNS administration, and understanding them is key to understanding how DNS delegation, replication, and management work.

The terms "zone" and "domain" are often used interchangeably, but they refer to different things. A domain is a node in the DNS hierarchy (like example.com). A zone is the administrative boundary around a set of DNS records. A single domain might be split across multiple zones, and a single zone might contain records for a domain and several of its subdomains. For a broader understanding of DNS, see DNS Resolution: How It Works.

Zones vs Domains

Consider the domain example.com with these subdomains: www.example.com, mail.example.com, blog.example.com, and staging.example.com.

If all DNS records for these are managed together by the same nameserver, they all exist in a single zone: the example.com zone.

But if staging.example.com is delegated to a different set of nameservers (managed by a development team with their own DNS provider), then you have two zones:

1. The example.com zone, containing records for example.com, www, mail, and blog, plus NS delegation records for staging.
2. The staging.example.com zone, containing records for staging.example.com and anything under it.

The domain example.com still includes staging.example.com in its hierarchy, but the zone boundary separates the administrative responsibility.

The Zone File

A zone file is the text file (or database entry in modern systems) that contains all the DNS records for a zone. Traditional DNS servers like BIND use plain text zone files. Managed DNS providers store zone data in databases but the concept is the same.

A simplified zone file for example.com:

$ORIGIN example.com.
$TTL 3600

; SOA record (required, exactly one per zone)
@    IN    SOA    ns1.dnsprovider.com. admin.example.com. (
              2024061001    ; serial
              3600          ; refresh
              900           ; retry
              1209600       ; expire
              300           ; minimum TTL
)

; NS records (required, at least two)
@    IN    NS     ns1.dnsprovider.com.
@    IN    NS     ns2.dnsprovider.com.

; A records
@    IN    A      93.184.216.34
www  IN    A      93.184.216.34

; CNAME records
blog IN    CNAME  example.com.cdn.provider.com.

; MX records
@    IN    MX     10 mail1.example.com.
@    IN    MX     20 mail2.example.com.

; A records for mail servers
mail1 IN   A      93.184.216.40
mail2 IN   A      93.184.216.41

; TXT records
@    IN    TXT    "v=spf1 include:_spf.google.com ~all"

; Subdomain delegation
staging IN NS     ns1.devteam.com.
staging IN NS     ns2.devteam.com.

Required Records

Every zone must have:

• One SOA record at the zone apex. The SOA (Start of Authority) contains the primary nameserver, administrative contact, serial number, and timing parameters that control zone replication. See SOA Record Explained.
• At least two NS records at the zone apex, identifying the authoritative nameservers for the zone.

The $ORIGIN Directive

The $ORIGIN directive sets the default domain suffix for relative names in the zone file. With $ORIGIN example.com., a record for www is interpreted as www.example.com.. Names that end with a dot (.) are absolute and are not affected by $ORIGIN.

The $TTL Directive

The $TTL directive sets the default TTL for records that do not specify their own. In the example above, all records default to 3600 seconds (one hour) unless they override it.

Zone Delegation

Zone delegation is the mechanism that makes DNS distributed. Instead of one organization managing DNS records for the entire internet, each zone is managed independently by whoever is responsible for that portion of the namespace.

Delegation works through NS records. When a zone contains NS records for a subdomain, those records delegate authority for that subdomain to different nameservers. The parent zone no longer contains any other records for the delegated subdomain.

; In the example.com zone:
staging.example.com.    IN    NS    ns1.devteam.com.
staging.example.com.    IN    NS    ns2.devteam.com.

After this delegation, queries for app.staging.example.com are answered by ns1.devteam.com and ns2.devteam.com, not by the nameservers for example.com.

The entire DNS hierarchy works this way:

1. The root zone delegates .com to Verisign's nameservers.
2. The .com zone delegates example.com to your nameservers.
3. Your example.com zone can delegate staging.example.com to other nameservers.

Each delegation creates a new zone with its own administrative authority.

Zone Types

Primary (Master) Zone

A primary zone is the editable copy of the zone. DNS changes are made here. The primary nameserver for a zone holds the primary zone data and is the source for replication to secondary nameservers.

Secondary (Slave) Zone

A secondary zone is a read-only copy of a primary zone, maintained through zone transfers (AXFR or IXFR). Secondary zones provide redundancy and load distribution. If the primary nameserver goes down, secondaries continue serving the zone.

Forward Zone

A forward zone configures a DNS server to forward queries for a specific domain to a designated set of nameservers instead of following the normal recursive resolution path. This is a resolver configuration, not an authoritative zone.

Stub Zone

A stub zone contains only the NS records and glue records for a delegated zone. It is used by DNS servers to maintain a current list of nameservers for a zone without holding the full zone data. This is an optimization that reduces the need for full zone transfers.

Reverse Zone

A reverse zone maps IP addresses to domain names using PTR records. Reverse zones use the in-addr.arpa (IPv4) or ip6.arpa (IPv6) namespace. They are structured by IP address blocks and managed by whoever controls the IP address space (typically your hosting provider or ISP). See DNS PTR Record: Reverse Lookups Explained.

Zone Transfers

Zone transfers are the mechanism for replicating zone data from primary to secondary nameservers. Two protocols are used:

AXFR (Full Zone Transfer): The entire zone is transferred. Simple but inefficient for large zones with small changes.

IXFR (Incremental Zone Transfer): Only the changes since the secondary's last update are transferred. More efficient for large zones.

The SOA record's serial number triggers transfers. When the primary's serial number is higher than the secondary's, the secondary knows the zone has been updated and initiates a transfer.

For the complete picture, see DNS Replication: How It Works and How to Verify.

Zone Security

Zone Transfer Restrictions

By default, anyone who can query your nameserver can request a zone transfer, which reveals every record in your zone. This is a security concern because it exposes your complete DNS infrastructure, including internal hostnames and IP addresses.

Restrict zone transfers to your secondary nameservers' IP addresses only:

; BIND configuration
zone "example.com" {
    type master;
    allow-transfer { 192.0.2.1; 198.51.100.1; };
};

DNSSEC

DNSSEC (DNS Security Extensions) adds cryptographic signatures to zone records. Resolvers can verify that the records they receive came from the authoritative nameserver and were not modified in transit. DNSSEC is configured at the zone level, and each zone has its own signing keys.

See What Is DNSSEC? for details.

Zone Management Best Practices

Keep your SOA serial number consistent. Use the YYYYMMDDNN format (e.g., 2024061001) and increment it with every change. Some automated systems use Unix timestamps or sequential integers, which also work.

Set appropriate SOA timing values. Refresh of 3600 (1 hour), retry of 900 (15 minutes), expire of 1209600 (2 weeks), and minimum of 300 (5 minutes for negative caching) are reasonable defaults for most zones.

Document your zone structure. Keep a record of which subdomains are delegated, which nameservers serve each zone, and who is responsible for each zone. This documentation is invaluable during troubleshooting and migrations.

Monitor your zones. Track record changes, nameserver availability, and consistency between primary and secondary nameservers. Unauthorized zone changes can indicate a security compromise.

Test changes before applying. Use named-checkzone (BIND) or equivalent tools to validate zone file syntax before loading changes. A syntax error in a zone file can take the entire zone offline.

named-checkzone example.com /etc/bind/zones/example.com.zone

Viewing a Zone's Contents

If you have access to the nameserver, you can view the zone file directly. If you do not, you can try a zone transfer (AXFR) if the server allows it:

dig AXFR example.com @ns1.dnsprovider.com

Most public DNS providers block zone transfers. In that case, you can query individual record types:

dig ANY example.com @ns1.dnsprovider.com

Note that the ANY query type has been deprecated by some resolvers and nameservers (RFC 8482) and may not return all records.

For checking specific records, see How to Check DNS Records.

References

1. RFC 1034, "Domain Names - Concepts and Facilities," November 1987. https://datatracker.ietf.org/doc/html/rfc1034
2. RFC 1035, "Domain Names - Implementation and Specification," November 1987. https://datatracker.ietf.org/doc/html/rfc1035
3. RFC 8482, "Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY," January 2019. https://datatracker.ietf.org/doc/html/rfc8482
4. Cloudflare Learning Center, "What is a DNS zone?" https://www.cloudflare.com/learning/dns/glossary/dns-zone/