DNS zone

What is a DNS zone?

A DNS zone is a distinct portion of the DNS namespace that is managed by a specific organization or administrator. A zone contains DNS records for one or more domains and is served by authoritative nameservers. While a domain is a name in the DNS tree, a zone is an administrative boundary defining which nameservers are responsible for answering queries.

Domain vs zone

Understanding the distinction is crucial:

Domain

A domain is a name in the DNS hierarchy:

example.com (domain)
  └── www.example.com (subdomain)
  └── blog.example.com (subdomain)
  └── api.example.com (subdomain)

Zone

A zone is administrative control over records:

example.com zone contains:
  - example.com
  - www.example.com
  - blog.example.com
  - api.example.com

Managed by: ns1.example.com, ns2.example.com

example.com zone contains:
  - example.com
  - www.example.com
  - Delegation: api.example.com → different nameservers

api.example.com zone (separate) contains:
  - api.example.com
  - v1.api.example.com
  - v2.api.example.com

Managed by: ns1.apihost.com, ns2.apihost.com

Zone components

Zone file

A text file containing all DNS records for a zone:

; example.com zone file
$TTL 3600
@   IN  SOA ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            7200        ; Refresh
            3600        ; Retry
            1209600     ; Expire
            3600        ; Minimum TTL
        )

; Nameserver records
@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.

; A records
@       IN  A       203.0.113.50
www     IN  A       203.0.113.50
blog    IN  A       203.0.113.51

; MX records
@       IN  MX  10  mail.example.com.
mail    IN  A       203.0.113.52

; CNAME records
ftp     IN  CNAME   www.example.com.

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

SOA record (Start of Authority)

Every zone must have exactly one SOA record:

example.com.  IN  SOA  ns1.example.com. admin.example.com. (
                       2024010101  ; Serial
                       7200        ; Refresh
                       3600        ; Retry
                       1209600     ; Expire
                       3600        ; Minimum TTL
                   )

NS records (nameservers)

Specify which servers are authoritative for the zone:

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

These tell the world which servers to query for records in this zone.

Zone types

Primary zone (master)

The authoritative source where zone records are edited:

ns1.example.com (primary)
  → Zone file edited here
  → Changes made directly
  → Notifies secondaries of updates

Secondary zone (slave)

Read-only copies that replicate from primary:

ns2.example.com (secondary)
  → Retrieves zone data from primary
  → Cannot be edited directly
  → Automatically syncs based on SOA refresh interval

1. Secondary checks SOA serial number
2. If primary serial is higher → request full zone transfer
3. Primary sends entire zone
4. Secondary updates its copy

1. Secondary requests only changes since last serial
2. Primary sends diff
3. More efficient for large zones with small changes

Forward zone

Maps domain names to IP addresses (most common):

example.com → 203.0.113.50
www.example.com → 203.0.113.50

Reverse zone

Maps IP addresses to domain names (PTR records):

50.113.0.203.in-addr.arpa → example.com

Used for:

• Email server verification
• Logging and security
• Troubleshooting

Zone delegation

Delegation creates separate zones for subdomains:

Parent zone (example.com)

; example.com zone
@           IN  A       203.0.113.50
www         IN  A       203.0.113.50

; Delegate api.example.com to different nameservers
api         IN  NS      ns1.apihost.com.
api         IN  NS      ns2.apihost.com.

; Glue records (if needed)
ns1.api     IN  A       198.51.100.1
ns2.api     IN  A       198.51.100.2

Delegated zone (api.example.com)

Completely separate zone file on different nameservers:

; api.example.com zone (on ns1.apihost.com)
@           IN  A       198.51.100.10
v1          IN  A       198.51.100.11
v2          IN  A       198.51.100.12

• Organizational: Different teams manage different zones
• Technical: Use different DNS providers (e.g., API on AWS, website on Cloudflare)
• Performance: Distribute DNS load
• Security: Isolate sensitive services

Zone management

Serial number management

Serial numbers track zone versions (typically YYYYMMDDnn format):

2024010101  ; January 1, 2024, version 01
2024010102  ; January 1, 2024, version 02
2024010201  ; January 2, 2024, version 01

Zone transfer security

zone "example.com" {
    type master;
    file "/var/named/example.com.zone";
    allow-transfer { 203.0.113.52; 203.0.113.53; };  // Secondary IPs only
    notify yes;
};

key "transfer-key" {
    algorithm hmac-sha256;
    secret "base64-encoded-key";
};

allow-transfer { key transfer-key; };

Checking zone configuration

Query SOA record

dig example.com SOA

; ANSWER SECTION:
example.com.  3600  IN  SOA ns1.example.com. admin.example.com. (
                             2024010101 7200 3600 1209600 3600 )

Query NS records

dig example.com NS

; ANSWER SECTION:
example.com.  86400  IN  NS  ns1.example.com.
example.com.  86400  IN  NS  ns2.example.com.

Request zone transfer (AXFR)

dig @ns1.example.com example.com AXFR

# If allowed, returns entire zone
# If denied, returns transfer failed

Most public nameservers deny AXFR to prevent information disclosure.

Common zone configurations

Simple website

example.com zone:
  @     A      203.0.113.50
  www   A      203.0.113.50
  @     MX 10  mail.example.com
  mail  A      203.0.113.51
  @     TXT    "v=spf1 mx -all"

Multi-service zone

example.com zone:
  @       A       203.0.113.50
  www     A       203.0.113.50
  blog    CNAME   hosting.wordpress.com.
  shop    CNAME   shops.myshopify.com.
  cdn     CNAME   d111111abcdef8.cloudfront.net.
  @       MX 10   aspmx.l.google.com.

Delegated subdomains

example.com zone:
  @       A   203.0.113.50
  www     A   203.0.113.50

  ; Delegate api to AWS Route 53
  api     NS  ns-123.awsdns-01.com.
  api     NS  ns-456.awsdns-02.net.

  ; Delegate cdn to Cloudflare
  cdn     NS  ns1.cloudflare.com.
  cdn     NS  ns2.cloudflare.com.

Zone file best practices

1. Always increment serial: After every change, or secondaries won't update

2. Use date-based serials: Format YYYYMMDDnn for clarity

3. Restrict zone transfers: Allow only authorized secondaries

4. Use multiple nameservers: At least 2, preferably on different networks

5. Set appropriate TTLs: Balance caching benefits vs update speed

6. Test before applying: Validate zone file syntax before loading

7. Monitor zone transfers: Ensure secondaries are syncing

8. Document delegations: Note which zones are delegated and where

9. Backup zone files: Regular backups prevent data loss

10. Use version control: Track zone file changes over time

Advanced zone features

DNSSEC (Zone Signing)

Cryptographically sign zone records:

example.com.  IN  A       203.0.113.50
example.com.  IN  RRSIG   A 8 2 3600 (
                                signature-data-here )

Protects against cache poisoning and tampering.

Dynamic DNS (DDNS)

Allow programmatic zone updates:

# Update A record dynamically
nsupdate -k Kupdate.key <<EOF
server ns1.example.com
update delete www.example.com A
update add www.example.com 300 A 203.0.113.51
send
EOF

Useful for:

• Home IP address updates
• Auto-scaling infrastructure
• Service discovery

Zone views (split horizon DNS)

Serve different zone data based on client IP:

Internal clients: example.com → 10.0.0.50 (internal)
External clients: example.com → 203.0.113.50 (public)

• Internal vs external website versions
• Private network resources
• Geo-based responses

Troubleshooting zone issues

Zone transfer failures

# Check if primary allows transfers
dig @ns1.example.com example.com AXFR

# Check secondary logs for errors
tail -f /var/log/named.log

• Verify allow-transfer settings
• Check network connectivity between servers
• Ensure serial number increased

Serial number not incrementing

Delegation not working

# Verify delegation
dig example.com NS
dig api.example.com NS

# Should show different nameservers for delegated subdomain

• Verify NS records in parent zone
• Check glue records if nameservers are within subdomain
• Confirm child zone is configured

DNS zones are the foundation of distributed DNS management. Understanding zone structure, delegation, and management enables you to architect DNS effectively for organizations of any size.