Instiq
Chapter 2 · Domain name servers·v1.0.0·Updated 7/7/2026·~11 min

What's changed: Initial version (topic 2.08, subtopics 2.08.1–2.08.3)

2.2Managing Zone Data

Key points

Learn the layout of a zone file and the format of common resource records (SOA, NS, A, AAAA, MX, CNAME, PTR). Also cover named-compilezone and named-checkzone for converting and checking zone files.

While named.conf declares where a zone lives, the zone file is what actually records name-to-address mappings. Reading and writing each resource record line accurately is central to L2's practical skill.

2.2.1Zone file layout

  • A zone file places one SOA record (Start of Authority—the zone's authority metadata) near the top, followed by various resource records. The general format is name [TTL] IN type value.
  • The SOA carries a serial number (triggers zone transfers—incremented on every change), refresh (how often a secondary checks in), retry, expire (how long before discarding data if unreachable), and a negative TTL (how long negative answers are cached).

2.2.2Key resource records

  • NS designates the zone's authoritative servers. A maps a hostname to an IPv4 address. AAAA maps a hostname to an IPv6 address.
  • MX gives the mail destination host and a priority (lower number = higher priority). CNAME is an alias pointing to the canonical name—note the rule that no other records may coexist at a name that already has a CNAME.
  • PTR is dedicated to reverse lookups (IP address → hostname), served from in-addr.arpa (IPv4) or ip6.arpa (IPv6) reverse zones.
Exam point

Frequent contrasts: forgetting to bump the SOA serial means secondaries never see the update, lower MX numbers mean higher priority, reverse = PTR, forward = A/AAAA. The rule against coexisting records at a CNAME name is also a target.

Editing a zone file is a classic case where a small slip cascades. Adding a new web server means not just writing www IN A 192.0.2.10, but also always incrementing the SOA serial number—otherwise secondaries never pull the change via zone transfer (even after the refresh interval, an unchanged serial reads as "nothing new"). For mail deliverability, list multiple MX records at different priorities, e.g. example.com. IN MX 10 mail1.example.com. and IN MX 20 mail2.example.com., so mail2 becomes the fallback if mail1 fails. CNAME is convenient for aliasing a hostname, but adding another record at the same name as a CNAME—say www IN TXT "..." alongside www IN CNAME app.example.com.—is prohibited, a common misconfiguration. After editing, always validate the zone file's consistency with named-checkzone before deploying, and use named-compilezone to convert text format into a faster internal representation. Neglecting reverse lookups is another practical pitfall: many receiving MTAs perform a reverse-lookup check on mail servers, and a missing PTR can cause deliveries to be rejected.

Record typePurposeExample
SOAZone authority metadata (serial, etc.)@ IN SOA ns1.example.com. admin.example.com. ( ... )
NSDesignates authoritative servers@ IN NS ns1.example.com.
A / AAAAHostname to IPv4 / IPv6www IN A 192.0.2.10
MX / CNAME / PTRMail priority / alias / reverse lookupIN MX 10 mail1.example.com.
Warning

Trap: "a higher MX number means higher priority" is wrong—a lower number means higher priority. Also, "editing a zone file without changing the serial still propagates automatically at the next refresh interval" is wrong—secondaries never detect a change unless the serial number changes.

Zone file SOA, NS, A/AAAA, MX, CNAME, and PTR records, plus the named-checkzone validation flow.
Forgetting the serial bump blocks the transfer

2.2.3Section summary

  • SOA = authority metadata (serial must be bumped) / NS = authoritative servers / A, AAAA = forward lookup / MX = mail priority (lower = higher) / CNAME = alias / PTR = reverse lookup
  • Validate consistency after editing with named-checkzone; convert to internal representation with named-compilezone

Sign in to track progress — Log in.

Quick check

(just a quick review)

Q1. After adding an A record to the zone file, you must ensure the secondary server picks up the change. What must you not forget?

Q2. You run two mail servers and want mail2 to be the fallback if mail1 fails. Which zone file setting is correct?

Q3. Before deploying an edited zone file, you want to validate its consistency. Which command?

Check your understandingPractice questions for Chapter 2: Domain name servers