DNS Zones and Delegation

Complete guide to DNS zones, zone delegation, zone files, and hierarchical DNS architecture for domain management

A DNS zone is a contiguous portion of the DNS namespace managed by a specific organization or administrator. Zones define administrative boundaries in the DNS hierarchy, allowing different entities to control different parts of a domain. Zone delegation transfers authority for a subdomain to different nameservers, enabling distributed management of the global DNS system across thousands of organizations.

DNS zones contain resource records (A, AAAA, MX, CNAME, TXT, NS, SOA) that define how domain names resolve to IP addresses and services. The zone starts at a specific domain (zone apex) and includes all subdomains beneath it unless explicitly delegated elsewhere. For example, the example.com zone includes example.com and www.example.com, api.example.com, but sub.example.com can be delegated to a separate zone with its own nameservers.

Zone delegation enables scalable, distributed DNS management. The root zone delegates .com to Verisign’s nameservers. The .com zone delegates example.com to the organization’s nameservers. That organization can delegate sub.example.com to a different team’s nameservers. Each delegation point transfers authority and responsibility, preventing any single organization from managing the entire DNS namespace.

Last updated: 2026-04-22

How DNS Zones Work

A DNS zone represents a portion of the DNS namespace under single administrative control. The zone administrator maintains the zone file containing resource records for all names within that zone. When a DNS query arrives for a name in the zone, the authoritative nameserver responds from its zone file.

Zones start at the zone apex (also called zone origin) and include all descendant names unless delegation occurs. The zone apex has the same name as the zone itself. A zone file for example.com defines records for example.com (apex), www.example.com, api.example.com, and any other subdomains not delegated elsewhere.

The Start of Authority (SOA) record identifies the zone and contains metadata: primary nameserver, responsible person email, serial number (for zone transfers), refresh/retry/expire timers for secondary servers, and minimum TTL for negative caching. Every zone must have exactly one SOA record at the apex.

NS records specify authoritative nameservers for the zone. These nameservers hold the zone file and answer queries authoritatively. A zone typically has multiple NS records (minimum two) for redundancy. Each NS record points to a nameserver hostname, which must have A or AAAA records (glue records if within the same zone).

Zone Delegation

Zone delegation transfers authority for a subdomain to a different set of nameservers. Delegation creates a new administrative boundary: the parent zone no longer controls records in the delegated subdomain, only points to the delegated nameservers.

Delegation requires NS records in the parent zone pointing to the child zone’s nameservers. For example, delegating sub.example.com requires adding NS records for sub.example.com in the example.com zone file:

sub.example.com.    IN    NS    ns1.sub.example.com.
sub.example.com.    IN    NS    ns2.sub.example.com.

Glue records provide IP addresses for nameservers within the delegated zone. Since ns1.sub.example.com is within the delegated subdomain, resolvers can’t resolve it without creating a circular dependency. Glue records break this loop:

ns1.sub.example.com.    IN    A    192.0.2.1
ns2.sub.example.com.    IN    A    192.0.2.2

Without glue records, resolvers would need to query sub.example.com nameservers to resolve ns1.sub.example.com, but they need ns1.sub.example.com’s IP to query the nameservers—a circular dependency. Glue records stored in the parent zone resolve this.

Types of DNS Zones

Primary (Master) Zone

The original, authoritative source for the zone data. Zone file edited directly on primary server. Changes made here propagate to secondary servers via zone transfers. Single primary server per zone (traditional model). Modern DNS systems may use API-based changes without distinct primary/secondary roles.

Secondary (Slave) Zone

Copy of the zone transferred from the primary server. Read-only copy: changes must be made on primary. Periodic zone transfers keep secondary synchronized with primary. Provides redundancy and load distribution. Multiple secondary servers common for high availability.

Forward Zone

Standard zone containing name-to-address mappings. A records map names to IPv4 addresses. AAAA records map names to IPv6 addresses. Most common zone type for resolving domain names.

Reverse Zone

Maps IP addresses back to domain names. PTR records provide reverse DNS lookups. Required for email server reputation, network troubleshooting, security logging. Named using special domain: in-addr.arpa for IPv4, ip6.arpa for IPv6.

Stub Zone

Contains only essential records from another zone: SOA, NS, and glue A/AAAA records. Used to maintain updated list of authoritative servers for a zone. Reduces cross-domain DNS query latency. Useful for organizations with multiple internal domains.

Zone File Structure

Zone files are text files containing resource records in master file format. Each line typically contains one resource record:

$ORIGIN example.com.
$TTL 86400


@    IN    SOA    ns1.example.com.    admin.example.com. (
                2026042201  ; Serial
                3600        ; Refresh
                1800        ; Retry
                604800      ; Expire
                86400       ; Minimum TTL
                )


@           IN    NS      ns1.example.com.
@           IN    NS      ns2.example.com.
@           IN    A       192.0.2.10
@           IN    MX      10 mail.example.com.
www         IN    A       192.0.2.11
api         IN    A       192.0.2.12
ns1         IN    A       192.0.2.53
ns2         IN    A       192.0.2.54

The $ORIGIN directive sets the zone name. The @ symbol represents the zone apex. Resource record format: name [TTL] [class] type value. The SOA record spans multiple lines with parentheses. Serial number increments on each change to trigger zone transfers.

DNS Zone vs DNS Domain

A DNS domain is a node in the DNS namespace tree. Domains are hierarchical: www.example.com is a domain (subdomain of example.com), which is a subdomain of com, which is a subdomain of the root (.).

A DNS zone is an administrative boundary. A zone can span an entire domain or be split into multiple zones through delegation. One zone can manage example.com and all its subdomains, or example.com can delegate engineering.example.com and marketing.example.com to separate zones.

Key difference: domain refers to namespace hierarchy, zone refers to administrative control. Multiple zones can exist within a single domain through delegation. A single zone can control multiple related domains in some configurations (though typically one zone per domain).

When to Delegate a Zone

Delegate a zone when:

  • Different team or organization manages the subdomain
  • Subdomain requires independent DNS infrastructure
  • Geographic distribution demands local DNS control
  • Security isolation needed between zones
  • Scaling DNS management across large organizations
  • Specific compliance or regulatory requirements for subdomain

Do not delegate when:

  • Single team manages entire domain hierarchy
  • Simplicity outweighs delegation complexity
  • Subdomain doesn’t require independent infrastructure
  • Risk of misconfiguration from distributed management

Signals You Need Zone Delegation

  • Large organization with multiple departments requiring DNS autonomy
  • Acquired company maintaining separate IT infrastructure
  • Cloud-native application deploying independent services
  • Geographic offices requiring local DNS control
  • Security zones requiring isolated DNS management
  • Partner or customer subdomains managed externally

Metrics and Measurement

Zone Health Metrics:

  • Zone transfer success rate: Percentage of successful AXFR/IXFR transfers (target: 100%)
  • Zone transfer latency: Time to propagate changes to secondary servers (target: <5 minutes)
  • Serial number synchronization: All nameservers serving same zone version (target: 100%)
  • SOA query response time: Time to retrieve SOA record (target: <50ms)

Delegation Health Metrics:

  • Glue record accuracy: Parent zone glue matches child zone nameserver IPs (target: 100%)
  • Lame delegation rate: Queries to nameservers not authoritative for delegated zone (target: 0%)
  • Delegation consistency: All parent NS records match child zone NS records (target: 100%)
  • Delegation depth: Levels of delegation from root (monitor for excessive depth)

According to APNIC DNS measurements (2024), approximately 3% of DNS delegations suffer from lame delegation (nameservers not responding authoritatively). Glue record mismatches cause 2% of delegation failures. Proper delegation maintenance reduces these errors.

Real-World Use Cases

Enterprise DNS Architecture

  • Corporate zone company.com managed by IT
  • Delegated zone engineering.company.com managed by engineering team
  • Delegated zone marketing.company.com managed by marketing team
  • Each team controls their DNS records independently
  • Corporate IT maintains oversight and policy

Cloud Platform DNS

  • Cloud provider zone cloudprovider.com
  • Customer delegated zone customer123.cloudprovider.com
  • Customer manages DNS through cloud console or API
  • Delegation automates provisioning of new customer zones
  • Scalable multi-tenant DNS architecture

Multi-CDN Deployments

  • Primary zone example.com delegates cdn.example.com
  • CDN provider manages cdn.example.com zone
  • Dynamic traffic routing based on geography, load, availability
  • Customer retains control of main domain
  • CDN handles complex routing logic in delegated zone

Reverse DNS Zones

  • ISP manages in-addr.arpa zone delegation
  • Customer delegated reverse zone for assigned IP blocks
  • Customer configures PTR records for mail server reputation
  • ISP delegates 0-255.2.0.192.in-addr.arpa to customer nameservers
  • Essential for email deliverability and network debugging

Geographic DNS Distribution

  • Global zone global.example.com at headquarters
  • Regional delegation us.example.com, eu.example.com, asia.example.com
  • Regional teams manage local DNS infrastructure
  • Reduces latency for regional DNS queries
  • Local compliance and data sovereignty

Common Mistakes and Fixes

Mistake: Missing glue records for in-zone nameserver delegation Fix: Always include A/AAAA glue records in parent zone when delegating to nameservers within the delegated subdomain. Without glue records, resolvers encounter circular dependency and cannot resolve the delegation. Validate delegation with DNS checking tools (dnsviz.net, Zonemaster) to catch glue issues.

Mistake: NS record mismatch between parent and child zone Fix: Ensure NS records in parent zone delegation match NS records in child zone apex. Mismatches cause resolution delays and failures. When updating nameservers, update child zone first, then parent delegation, then remove old nameservers after TTL expires. Use automation to keep zones synchronized.

Mistake: Lame delegation (nameserver not authoritative for zone) Fix: Verify all nameservers listed in NS records are configured to serve the zone authoritatively. Remove nameservers from NS records if they don’t serve the zone. Monitor for lame delegation responses (AA flag not set in responses). Regular audits prevent lame delegation accumulation.

Mistake: Incorrect SOA serial number management Fix: Increment SOA serial number on every zone change. Use YYYYMMDDNN format for clarity. Secondary servers use serial to determine if zone transfer needed. Failure to increment serial prevents zone updates from propagating. Automation reduces serial number errors.

Mistake: Excessive delegation depth Fix: Avoid deep delegation chains: sub.sub.sub.sub.example.com requires multiple DNS queries, increasing latency and failure points. Flatten DNS hierarchy where possible. Monitor delegation depth and consolidate zones if query latency degrades.

Mistake: Not implementing DNSSEC for zone signing Fix: Sign zones with DNSSEC to prevent DNS spoofing attacks. DS records in parent zone establish chain of trust to child zone. DNSSEC validation ensures DNS responses authenticity. Enable DNSSEC on both zone apex and delegated subdomains.

Frequently Asked Questions

What is the difference between a zone and a domain? A domain is a node in the DNS namespace (e.g., example.com, www.example.com). A zone is an administrative boundary for managing DNS records. One zone can manage an entire domain and all subdomains, or zones can be split through delegation. Domain refers to namespace, zone refers to administration.

How many nameservers should a zone have? Minimum two nameservers for redundancy. Best practice: 3-5 nameservers across different geographic locations and networks. Too few nameservers create single points of failure. Too many nameservers increase management overhead and zone transfer complexity without proportional reliability benefit.

What is glue record and when do I need it? Glue records are A/AAAA records for nameservers within a delegated zone, stored in the parent zone. Required when delegating to nameservers whose hostnames are within the delegated subdomain. Without glue, resolvers encounter circular dependency: need nameserver IP to resolve nameserver hostname, but need to query that nameserver.

How do zone transfers work? Zone transfers replicate zone data from primary to secondary servers. AXFR (full zone transfer) copies entire zone. IXFR (incremental zone transfer) copies only changes since last transfer. Secondary servers initiate transfers based on SOA refresh timer or when notified by primary. Zone transfers use TCP on port 53.

Can I delegate a zone without managing the parent zone? No. Delegation requires NS records in the parent zone. If you control sub.example.com but not example.com, you must coordinate with the parent zone administrator to create delegation NS records. Without parent delegation, your zone is not discoverable through normal DNS resolution.

How long does zone delegation take to propagate? Delegation propagation depends on TTL values on NS records in parent zone and caching behavior of resolvers. Typical NS TTL: 24-48 hours. Lower TTL before delegation changes reduces propagation time. After updating parent zone, wait for old TTL to expire before expecting global visibility.

What happens if delegated nameservers are unavailable? If all delegated nameservers for a zone are unavailable, queries for names in that zone fail. Resolvers return SERVFAIL or timeout. Multiple nameservers across different networks and locations provide redundancy. Monitor nameserver availability and respond quickly to outages.

How This Applies in Practice

Zone delegation enables scalable, distributed DNS management essential for the global internet. Understanding zones and delegation helps architects design DNS infrastructure, troubleshoot resolution failures, and maintain reliable DNS services.

Zone Management Best Practices:

  • Maintain minimum 2-3 nameservers per zone for redundancy
  • Implement DNSSEC signing for zone integrity
  • Use automation for zone file management and serial increments
  • Monitor zone transfer success and synchronization
  • Validate delegation configuration with DNS checking tools

Delegation Implementation:

  • Coordinate with parent zone administrator for delegation setup
  • Configure glue records for in-zone nameservers
  • Ensure NS record consistency between parent and child zones
  • Test delegation before cutting over production traffic
  • Monitor delegated zone health independently

Troubleshooting Zone Issues:

  • Check SOA serial number synchronization across nameservers
  • Verify NS records and glue record accuracy
  • Test resolution from multiple locations and resolvers
  • Use DNSSEC validation tools to check chain of trust
  • Monitor zone transfer logs for errors

DNS Zones on Azion

Azion provides DNS management through Intelligent DNS:

  • Authoritative DNS hosting for your zones
  • Anycast DNS network for global performance and redundancy
  • DNSSEC support for zone signing and validation
  • Real-time DNS analytics and query logging
  • API-driven zone management for automation
  • Integration with Azion Edge Applications for intelligent routing

Azion’s DNS infrastructure handles zone delegation, propagation, and query resolution across a global anycast network, ensuring high availability and low latency for DNS queries worldwide.

Learn more about Intelligent DNS and DNS Propagation.

Sources

Related Content

Community