What is a DNS zone?

DNS zones split up the authority over different segments of the DNS namespace—for instance, a domain and a subdomain—which gives administrators more precise control over DNS records, DNS name servers and other components. This partitioning can help streamline DNS management and orchestration and distribute workloads across name servers.

For example, the domain “example.com” can exist in the same zone as subdomains “blog.example.com” and “community.example.com.” If administrators need more granular control—maybe because of the number of devices connected to the community site and the volume of associated DNS records—they can partition the “community.example.com” subdomain into its own zone with its own authoritative name server.

A DNS zone specifies that a domain, or part of a domain, is managed by a specific administrator; however, a zone can encompass multiple subdomains and multiple zones can exist on the same.

DNS server. DNS zones do not imply physical separation but are used for control over different parts of the namespace.

Zones can help ease the administrative burden associated with a domain, distribute DNS query load and enhance the overall efficiency and scalability of DNS services. Effective zone management that uses security features such as DNSSEC and dynamic updates can strengthen DNS security and reduce security threats like DNS spoofing and hijacking attacks.

Some background knowledge on the domain name system, and how it operates, is important to understanding DNS zones.

The DNS is a hierarchical, decentralized component of the internet standard protocol responsible for converting human-friendly domain names into the internet protocol (IP) addresses computers use to identify each other on the network.¹

Often called the “phonebook for the internet,” a more modern analogy is that DNS manages domain names in much the same way as smartphones manage contacts. Phones save contact numbers in searchable contact lists and eliminate the need for users to memorize individual phone numbers. Likewise, the DNS enables users to connect to websites by using domain names instead of complex IP addresses.

When a user enters a domain name into a browser, the query (often called a DNS request or DNS lookup) begins. A recursive resolver—the middleman between the client device and authoritative servers—then queries a series of servers to find the information it needs to connect the user to the wanted website. Each of these servers is responsible for a segment of the domain namespace.

The query process begins with the root name server. Root name servers sit atop the DNS hierarchy and are responsible for managing the root zone. These servers answer queries for records stored within the root zone and refer requests to the appropriate top-level domain (TLD) name server.

TLD name servers direct queries to the authoritative name servers for the specific domains within their TLD. For example, the TLD name server for ".com" directs domains ending in ".com", the TLD name server for ".gov" directs domains ending in ".gov", and so on.

The domain name server (sometimes referred to as the second-level domain name server) holds the zone file with the IP address for the full domain name, such as “ibm.com.” This zone file might also hold information for a subdomain (such as blog.ibm.com) or that information might be partitioned to its own zone.

Each of these servers stores DNS records with information about the domain that the recursive resolver needs to continue, and ultimately resolve, its query.

A DNS zone file is a plain text file stored on DNS servers that contains all the records for the domains within that zone.

Each line of a zone file specifies a resource record (a single piece of information about the nature of, typically organized by data type). Resource records ensure that when a user initiates a query, the DNS can quickly direct users to the correct server.

DNS zone files start with two mandatory records: the start of authority (SOA record)—which specifies the primary authoritative name server for the DNS zone—and the global time to live (TTL)—which indicates how records should be stored in the local DNS cache.

A zone file can contain several other record types, including:

• A records, which map to IPv4 addresses, and AAAA records, which map to IPv6 addresses.
  
  
• Mail exchanger records (MX records), which specify an SMTP email server for a domain.
  
  
• Canonical name records (CNAME records), which redirect hostnames from an alias to another domain (the “canonical domain”).
  
  
• Name server records (NS records), which indicate that a DNS server is attached to a specific authoritative name server.
  
  
• Pointer records (PTR records), which specify a reverse DNS lookup.
  
  
• Text records (TXT records), which indicate the sender policy framework record for email authentication.

The primary DNS zone stores the primary zone file with all the DNS records for that zone. It is a read/write copy, and zone updates are made to the primary zone and then copied in secondary zones. There can only be one primary zone on one DNS server at a time.

A secondary zone is a read-only copy of the primary zone, used to create a redundancy and implement load balancing for DNS queries.

DNS requests are typically distributed across the primary and secondary servers. If the primary server is down, the secondary servers can take on all or part of the load by using zone transfers—a transaction that enables primary and secondary servers to exchange zones. Secondary zones also check in with the primary servers to ensure that replicas are up to date.

The forward lookup zone translates domain names into IP addresses. When a DNS resolver receives a query for a human-readable domain name, it consults A or AAAA mapping records in the forward lookup zone to find the corresponding IP address.

As a counterpoint to forward lookup zones, reverse lookup zones map IP addresses back to domain names by using PTR records (pointer records).

This process can be useful for deploying services that require domain verification or for logging purposes when teams need to understand the domain associated with an IP address (such as troubleshooting and spam filtering.) Queries in reverse DNS lookup zones use the in-addr.arpa or ip6.arpa domains.

Stub zones contain only the records that the system needs to identify the authoritative name servers for a zone. They serve as a pointer, reducing dependence on recursive servers for querying upper-level zones to locate the authoritative server. The proximity of stub zones to authoritative servers helps reduce DNS query traffic and shorten resolution times.

DNS zone transfers maintain optimal system functionality, especially in environments where redundancy and high availability are priorities.

A full zone transfer copies the entire contents of a zone file from the primary DNS server to secondary servers, creating an exact replica of the zone. Full zone transfers are commonly used during initial configuration of secondary servers or when secondary servers need to be re-synced after lengthy downtime. 

Incremental zone transfers only comprise changes to the zone since the last transfer. Because they require less bandwidth and processing power to maintain syncing processes, incremental zone transfers can be useful in dynamic zones that undergo frequent changes.