DNS zones and records

Table of Contents

Understanding DNS Zones

In the parent DNS chapter you’ve already seen what DNS does and why it matters. Here we focus on how DNS data is organized and expressed: zones and records.

A zone is the part of the DNS namespace that a specific DNS server is authoritative for and is configured to manage. It is not always identical to a domain:

A domain is a tree branch in the global DNS hierarchy (e.g. example.com).
A zone is an administrative boundary with its own zone file and authoritative servers (e.g. example.com plus some or all of its subdomains).

Common patterns:

Primary (master) zone:
The zone where changes are made. Stored in a zone file (or a database) on the primary server.
Secondary (slave) zone:
A read-only copy of a primary zone, synchronized via zone transfers (AXFR/IXFR).
Forward zone:
Maps hostnames to IPs (e.g. example.com → 93.184.216.34).
Reverse zone:
Maps IPs to hostnames (e.g. 34.216.184.93.in-addr.arpa → www.example.com).
Delegated zone:
A parent zone delegates responsibility for a subdomain (e.g. sub.example.com) to another set of name servers.

Zone Files Basics

On traditional nameservers such as BIND, a zone is implemented as a zone file: a text file containing resource records (RRs).

Typical characteristics:

One file per zone (e.g. /var/named/example.com.zone).
Uses:

TTL directives
A SOA record (mandatory, one per zone)
Multiple DNS resource records (A, AAAA, NS, MX, etc.)

Core syntax elements:

Origin:
Set with $ORIGIN (default domain for unqualified names).
TTL:
Can be set globally with $TTL or per record.
Relative vs absolute names:

www → www.example.com. (if origin is example.com.)
www.example.com. → fully qualified (note the final dot).

Example (BIND-style forward zone file):

$TTL 3600          ; default TTL 1 hour
$ORIGIN example.com.
@   IN SOA ns1.example.com. admin.example.com. (
        2025121201 ; serial
        3600       ; refresh (1 hour)
        900        ; retry (15 minutes)
        1209600    ; expire (14 days)
        300        ; minimum/negative TTL (5 minutes)
)
    IN NS  ns1.example.com.
    IN NS  ns2.example.com.
ns1 IN A   203.0.113.10
ns2 IN A   203.0.113.11
www IN A   203.0.113.20
api IN A   203.0.113.21
mail IN A  203.0.113.30
    IN MX  10 mail.example.com.

Key Resource Records

A resource record (RR) is a single row in the zone file describing some piece of DNS information.

General record format:

<name> <TTL> <class> <type> <RDATA>

name: the owner name (e.g. www, @, mail.example.com.).
TTL: time to live (optional here if global default applies).
class: almost always IN for Internet.
type: the record type (A, NS, MX, etc.).
RDATA: type-specific data (e.g. IP, hostname, preference value).

Below are the most important record types for server administration.

SOA (Start of Authority)

Every zone must have exactly one SOA record. It defines the zone’s primary server and zone metadata.

Example:

@ IN SOA ns1.example.com. admin.example.com. (
      2025121201 ; serial
      3600       ; refresh
      900        ; retry
      1209600    ; expire
      300        ; minimum/negative TTL
)

Fields:

Primary nameserver (ns1.example.com.):
The primary (master) for this zone.
Responsible person (admin.example.com.):
Email address with @ replaced by a dot; admin@example.com.
Serial (2025121201):
Zone version number. Secondary servers compare this value when deciding whether to fetch updates.

Common pattern: YYYYMMDDNN (date + two-digit counter).
Every zone change should increment the serial.

Refresh:
How often secondaries check the primary for updates.
Retry:
How long secondaries wait before retrying after a failed refresh.
Expire:
Maximum time secondaries serve data without contacting the primary; after this, data is considered invalid.
Minimum/negative TTL:
Time that negative responses (NXDOMAIN) may be cached by resolvers.

NS (Name Server) Records

NS records define which servers are authoritative for a zone.

Example:

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

Meaning:

example.com is served by ns1.example.com and ns2.example.com.
These names normally have corresponding A/AAAA records somewhere (often in the same zone or its parent).

Delegation is also done with NS records in the parent zone:

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

Then, a separate zone is created for sub.example.com.

A and AAAA Records

These map hostnames to IP addresses.

A: name → IPv4
AAAA: name → IPv6

Examples:

www  IN A    203.0.113.20
api  IN A    203.0.113.21
www  IN AAAA 2001:db8:1234::20
api  IN AAAA 2001:db8:1234::21

Notes:

A name can have both A and AAAA records (dual-stack host).
A name can have multiple A or AAAA records (for simple load distribution).

CNAME (Canonical Name) Records

CNAME creates an alias from one name to another hostname.

Example:

www       IN CNAME web01.example.com.
files     IN CNAME storage.example.net.

Rules and caveats:

A name with a CNAME must not have any other record types (A, MX, TXT, etc.).
Resolution follows the CNAME to the “canonical” name, then resolves that.
CNAMEs can chain, but that increases lookup time and complexity; avoid long chains.

Typical uses:

Human-friendly alias: www → web01.
Service alias: db-read → whichever actual DB node currently serves reads (managed externally).

MX (Mail Exchanger) Records

MX records specify mail servers for a domain.

Example:

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

Each MX record has a preference (lower = higher priority).
Mail transfer agents usually try the lowest number first (10), then fall back to 20 if needed.
MX hostnames must resolve via A/AAAA records; never point MXs directly to an IP or CNAME.

TXT Records

TXT records store arbitrary text. Common uses:

SPF (Sender Policy Framework)
DKIM and DMARC pointers
Domain verification for various services

Examples:

@   IN TXT "v=spf1 ip4:203.0.113.0/24 -all"
_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

TXT records are also used for service ownership verification (e.g. DNS-01 challenges, SaaS verification tokens).

SRV Records

SRV records specify the location (host and port) of specific services in a structured way.

Format:

_service._proto.name. TTL IN SRV priority weight port target

Example (for an internal SIP service):

_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sip1.example.com.
_sip._tcp.example.com. 3600 IN SRV 20 20 5060 sip2.example.com.

Fields:

service: e.g. _sip, _ldap, _xmpp-server.
proto: _tcp or _udp.
priority: lower is tried first.
weight: relative load-balancing between same-priority records.
port: TCP/UDP port of the service.
target: hostname running the service (must have A/AAAA).

Many modern services (VoIP, some directory services) rely on SRV for auto-discovery.

PTR Records (Reverse DNS)

PTR records implement reverse lookups: IP → hostname. They live in reverse zones (in-addr.arpa for IPv4, ip6.arpa for IPv6).

Example (IPv4):

IP: 203.0.113.20
Reverse name: 20.113.0.203.in-addr.arpa.

Zone fragment:

$ORIGIN 113.0.203.in-addr.arpa.
20 IN PTR www.example.com.

Example (IPv6):

IP: 2001:db8:1234::20
Reverse name: 0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa.

Managing reverse zones is often done by the IP owner (ISP or hosting provider). As a server admin, you may have to request PTR changes if you don’t control the reverse zone yourself.

Use cases:

Email servers: many receivers check that the PTR hostname is valid and often that it matches, or at least is consistent with, the hostname used by the SMTP server.
Diagnostics and logging: mapping IPs to hostnames for readability.

CAA Records

CAA (Certification Authority Authorization) controls which certificate authorities (CAs) may issue TLS certificates for your domain.

Example:

@ IN CAA 0 issue "letsencrypt.org"
@ IN CAA 0 issuewild "letsencrypt.org"
@ IN CAA 0 iodef "mailto:security@example.com"

Fields:

Flag (often 0).
Tag: issue, issuewild, iodef, etc.
Value: usually the CA domain or a contact method.

This provides an additional layer of protection against unauthorized certificate issuance.

Wildcard Records

Wildcard records apply to names that do not have explicit records.

Example:

*.example.com. IN A 203.0.113.50

Behavior:

foo.example.com → 203.0.113.50 (match).
bar.example.com → 203.0.113.50.
www.example.com → uses www record if it exists; wildcard is only used if no more specific record exists.

Caveats:

Wildcards do not match deeper labels when a more specific node exists in the hierarchy.
Combining wildcards with other record types (especially MX and SRV) requires careful planning to avoid unintended behavior.

Forward vs Reverse Zones in Practice

Forward Zones

Forward zone covers a domain name and its subdomains, mapping them to IPs and other info.

Typical contents:

SOA, NS records.
A, AAAA, MX, TXT, CNAME, SRV, CAA.

Example of a simple forward zone summary:

example.com:

@ → zone metadata and possibly base A/AAAA.
www → web frontend.
mail → mail server and associated MX.
_sip._tcp → SIP service (SRV).

Reverse Zones

Reverse zones are usually defined per network block.

IPv4:
A /24 might get its own zone: 113.0.203.in-addr.arpa.
IPv6:
Reverse zones are more complex due to nibble-based delegations, often handled by your provider.

Contents:

SOA, NS records.
PTR for each IP you control.

Administrative Best Practices

Serial management:
Always increment the SOA serial when editing a zone. Consider date-based format to avoid mistakes.
TTL strategy:

Use higher TTLs (e.g. 1–24 hours) for stable records.
Temporarily use lower TTLs (e.g. 300 seconds) before planned changes (e.g. server migration), then raise again.

Redundancy:

At least two NS records, pointing to different servers/networks.

Consistency:

Ensure MX targets, NS records, and SRV targets have valid A/AAAA records.
Keep forward and reverse records aligned for important hosts (especially mail servers).

Minimize CNAME misuse:

Avoid CNAME at the zone apex (example.com.) in traditional setups.
Do not point MX to a CNAME.

Use testing tools:

dig, host, or nslookup to verify records.
Online DNS validators for checking delegation, DNSSEC (if used), and general correctness.

This chapter’s focus has been the structure and semantics of zones and records. How to configure them in specific DNS server software (such as BIND) is covered in the dedicated “Setting up BIND” and “DNS troubleshooting” chapters.

Comments

Please login to add a comment.

Don't have an account? Register now!

DNS zones and records

Understanding DNS Zones

Zone Files Basics

Key Resource Records

SOA (Start of Authority)

NS (Name Server) Records

A and AAAA Records

CNAME (Canonical Name) Records

MX (Mail Exchanger) Records

TXT Records

SRV Records

PTR Records (Reverse DNS)

CAA Records

Wildcard Records

Forward vs Reverse Zones in Practice

Forward Zones

Reverse Zones

Administrative Best Practices

Comments

Where to Move