Zone Files: Structure and Management

## What a Zone File Is A DNS Zone File is a plain-text database that maps domain names to their DNS resource records. Every Authoritative DNS Server server loads zone files — or their database equivalent — to answer queries for the zones it serves. The format is standardized in RFC 1035 (1987) and extended by numerous subsequent RFCs. Understanding zone files is the foundation of all DNS configuration work. Even if you use a managed DNS provider that abstracts zone files into a GUI, the underlying data model is identical. When things go wrong, reading the raw zone is the most reliable diagnostic tool. ## The $ORIGIN Directive ``` $ORIGIN example.com. ``` `$ORIGIN` sets the base domain that relative names are appended to. Every name in a zone file that does not end with a dot is treated as relative to the current `$ORIGIN`. The dot at the end of `example.com.` is critical — it indicates the fully qualified domain name (FQDN) and prevents the parser from appending `$ORIGIN` again. ``` ; Relative name: ns1 → resolves to ns1.example.com. ; Absolute name: ns1.example.com. → stays as-is ``` If no `$ORIGIN` is set explicitly, most parsers default to the zone apex. ## The $TTL Directive ``` $TTL 3600 ``` `$TTL` sets the default TTL (Time To Live) (in seconds) for all records that do not specify their own TTL. This directive should appear near the top of the file, before any resource records. Individual records can override the default: ``` www 300 IN A 192.0.2.1 ; short TTL, overrides $TTL mail 3600 IN A 192.0.2.2 ; uses explicit 3600 ftp IN A 192.0.2.3 ; uses $TTL default ``` ## The SOA Record: Zone Authority The SOA Record (Start of Authority) must be the first resource record in every zone file. It contains: ``` $ORIGIN example.com. $TTL 3600 @ IN SOA ns1.example.com. hostmaster.example.com. ( 2024020601 ; Serial 7200 ; Refresh (2 hours) 3600 ; Retry (1 hour) 1209600 ; Expire (14 days) 300 ; Negative cache TTL (5 min) ) ``` The `@` symbol represents the zone apex (resolves to the current `$ORIGIN`). Fields: - **MNAME**: Primary authoritative nameserver for this zone - **RNAME**: Responsible person's email (dots replace `@` — `hostmaster.example.com.` = `[email protected]`) - **Serial**: Zone version number. Must be incremented every time the zone changes. Secondary servers compare serials to decide whether to fetch a fresh copy. - **Refresh**: How often secondaries check for updates - **Retry**: How long secondaries wait before retrying after a failed refresh - **Expire**: How long secondaries serve the zone if they cannot reach the primary - **Negative TTL**: How long resolvers cache NXDOMAIN responses ## NS Records: Nameserver Delegation NS Record records declare which servers are authoritative for this zone. Every zone needs at least two NS records (for redundancy): ``` @ IN NS ns1.example.com. @ IN NS ns2.example.com. ``` These are zone-apex NS records — they appear in the zone file itself. The TLD registry also holds NS records for your domain (called "delegation NS records"), and these must match. A mismatch between the delegation NS in the parent zone and your own zone's NS records is a common source of propagation issues. ## Common Record Types ``` ; A record (IPv4) www IN A 203.0.113.1 ; AAAA record (IPv6) www IN AAAA 2001:db8::1 ; CNAME record (canonical name alias) blog IN CNAME www.example.com. ; MX record (mail exchange) @ IN MX 10 mail1.example.com. @ IN MX 20 mail2.example.com. ; TXT record (arbitrary text — SPF, DKIM, verification tokens) @ IN TXT "v=spf1 include:_spf.google.com ~all" _dkim._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..." ; SRV record (service location) _sip._tcp IN SRV 10 20 5060 sip.example.com. ; CAA record (certification authority authorization) @ IN CAA 0 issue "letsencrypt.org" ``` ## Glue Records in Zone Files When a nameserver hostname is within the zone it serves (e.g., `ns1.example.com` for the `example.com` zone), a chicken-and-egg problem arises: you need to resolve `ns1.example.com` to query the `example.com` zone, but the `example.com` zone is what would answer `ns1.example.com` queries. The solution is Glue Record records — A/AAAA records for the nameserver hostnames included in the delegation (at the TLD level) and also in the zone itself: ``` ; Glue records (nameserver hostnames within the zone) ns1 IN A 203.0.113.53 ns2 IN A 203.0.113.54 ``` Without matching glue at the registry, resolvers cannot bootstrap zone delegation. See Glue Records: When Your NS Lives in Your Zone for the full treatment. ## Reverse DNS Zone Files Reverse DNS (PTR Record) zones use a special naming convention. IPv4 reverse zones use the `in-addr.arpa.` domain with the octets reversed: ``` $ORIGIN 113.0.203.in-addr.arpa. $TTL 86400 @ IN SOA ns1.example.com. hostmaster.example.com. ( 2024020601 3600 900 604800 300 ) @ IN NS ns1.example.com. @ IN NS ns2.example.com. 1 IN PTR www.example.com. 53 IN PTR ns1.example.com. ``` ## Serial Number Conventions The serial number must increase monotonically. Three conventions are common: - **Date-based**: `YYYYMMDDNN` (e.g., `2024020601` = 2024-02-06, change #1). Most readable. Allows up to 99 changes per day. - **Unix timestamp**: Large integer, auto-increments. Fine for automation but unreadable. - **Simple counter**: Starts at 1, increments by 1. Easy but loses date context. Date-based is the industry default. If you ever need to "reset" a zone that has somehow gone backwards in serial (e.g., after restoring from backup), you can force secondaries to reload by either setting the serial very high or using `rndc reload` on all nameservers. ## Zone File Best Practices **Version control your zone files.** A git repository is the correct home for zone files. Each commit message should describe the change. This gives you full history, rollback capability, and peer review for DNS changes. **Use a consistent TTL strategy.** Low TTLs (60–300 seconds) allow fast failover but increase resolver query load. High TTLs (3600–86400) reduce load but mean changes propagate slowly. A practical approach: lower TTLs in advance of planned changes, restore after. **Validate before deploying.** Use `named-checkzone` (BIND) or `kzonecheck` (Knot DNS) to catch syntax errors before loading: ```bash named-checkzone example.com /etc/bind/zones/example.com.zone ``` **Sign zone files with DNSSEC.** Unsigned zones are vulnerable to DNS Spoofing (Cache Poisoning). For the signing workflow, see DNSSEC Deep Dive: Signing, Validation, and Troubleshooting. DNS Record Helper