What Is a Zone File? Understanding DNS Zone Structure

← Back to Blog

Every domain's DNS records have to live somewhere. That somewhere is a zone file: a text-based blueprint that defines how a domain resolves, where its email goes, which servers are authoritative, and dozens of other instructions that make the domain work. If you've ever managed DNS through a provider's dashboard, you've been editing a zone file without seeing it. The dashboard is just a friendly interface over the underlying structure.

Understanding the zone file demystifies a lot of DNS. It shows you how records relate to each other, why certain rules exist (like the constraints on CNAMEs), and what's actually happening when you add an A record or change a nameserver. For anyone running self-hosted DNS, the zone file is the thing you edit directly.

This guide explains what a zone file is, walks through its structure line by line, and covers the records and directives you'll find inside one.

What Is a Zone File?

A zone file is a plain-text file that contains all the DNS records for a particular zone, which is usually a domain and its subdomains. It lives on the authoritative nameserver for that domain and is the definitive source of truth for how the domain resolves.

The format is standardized (originally defined in RFC 1035) so that any DNS server software can read it. Whether you use BIND, PowerDNS, Knot, or NSD, the zone file format is broadly the same, which is part of why DNS is so interoperable.

A "zone" and a "domain" are closely related but not identical. A domain is the name (yourcompany.com). A zone is the administrative boundary that the nameserver is authoritative for. Usually they line up, but a zone can be split: you might delegate sub.yourcompany.com to a different nameserver, creating a separate child zone. The parent zone file then contains a delegation pointing to the child's nameservers rather than the child's records directly.

The Anatomy of a Zone File

Here's a representative zone file for example.com. We'll break down each part.

$TTL 3600
$ORIGIN example.com.

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

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

@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
@       IN  AAAA    2001:db8::10

@       IN  MX  10  mail.example.com.
mail    IN  A       203.0.113.20

@       IN  TXT     "v=spf1 include:_spf.example.com -all"

ftp     IN  CNAME   www.example.com.
ns1     IN  A       203.0.113.2
ns2     IN  A       203.0.113.3

Directives: $TTL and $ORIGIN

Lines starting with $ are directives that control how the rest of the file is interpreted.

$TTL 3600 sets the default Time to Live for records that don't specify their own. This is how long resolvers should cache the records, in seconds. Individual records can override it. We covered TTL strategy in depth in our TTL best practices guide.

$ORIGIN example.com. defines the base domain that gets appended to any name not ending in a dot. This is what makes the shorthand in zone files work. When you write www, it expands to www.example.com. because of the origin. The trailing dot matters enormously here, which we'll explain next.

The Critical Detail: Trailing Dots

This is the single most common source of zone file errors, and it trips up even experienced administrators.

In a zone file, a name that ends with a dot is fully qualified, meaning it's complete and absolute. A name that does NOT end with a dot is relative, and the $ORIGIN gets appended to it.

Consider these two lines:

www     IN  CNAME   example.com.      ← correct: points to example.com
www     IN  CNAME   example.com       ← WRONG: points to example.com.example.com

The second line is missing the trailing dot, so the origin (example.com.) gets appended, producing example.com.example.com., which is almost certainly not what you intended. This kind of mistake creates broken resolution that can be maddening to debug because the zone file "looks right" at a glance.

The rule: if you're writing a complete domain name as a record's target, end it with a dot. If you're writing a name relative to your own domain (like www or mail), leave the dot off.

The SOA Record

Every zone file begins with a Start of Authority (SOA) record. It defines the administrative parameters for the zone and is mandatory. There can be only one SOA record per zone.

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

Breaking it down:

@ is shorthand for the origin (example.com.). The @ symbol always means "the current origin."
ns1.example.com. is the primary nameserver for the zone.
admin.example.com. is the administrator's email address, with the @ replaced by a dot. So this represents [email protected]. This substitution exists because @ already has a special meaning in zone files.
Serial (2026061501) is a version number for the zone. Every time you change the zone, you increment it. Secondary nameservers compare serials to know when to pull updates. A common convention is the date plus a counter (YYYYMMDDnn).
Refresh (7200) is how often secondary servers check the primary for changes, in seconds.
Retry (3600) is how long a secondary waits to retry if a refresh fails.
Expire (1209600) is how long a secondary keeps serving the zone if it can't reach the primary, before giving up.
Minimum TTL (3600) controls negative caching, which is how long resolvers cache "this record doesn't exist" (NXDOMAIN) responses.

The serial number is the field you'll interact with most. If you edit a zone file but forget to increment the serial, secondary nameservers won't realize there's an update and will keep serving the old records. Most managed DNS providers handle serial incrementing automatically, but in self-hosted setups it's a manual step that's easy to forget.

NS Records: Declaring the Nameservers

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

NS records declare which nameservers are authoritative for the zone. A zone should have at least two for redundancy. These records must match the nameserver delegation set at your registrar (the parent zone). A mismatch between the NS records in your zone file and the delegation at the registrar causes "lame delegation," a common DNS misconfiguration where resolvers are sent to nameservers that don't properly serve the zone.

The Resource Records

The bulk of a zone file is resource records, each defining one piece of DNS information. Every record follows the same general format:

NAME    TTL   CLASS   TYPE   DATA

In practice, TTL is often omitted (inheriting the $TTL default), and CLASS is almost always IN (Internet). So most records read as NAME IN TYPE DATA.

Common Record Types in a Zone File

A maps a name to an IPv4 address: www IN A 203.0.113.10
AAAA maps a name to an IPv6 address: www IN AAAA 2001:db8::10
CNAME creates an alias to another name: ftp IN CNAME www.example.com.
MX defines mail servers, with a priority value: @ IN MX 10 mail.example.com.
TXT holds arbitrary text, used for SPF, DKIM, DMARC, and verification: @ IN TXT "v=spf1 ..."
NS declares authoritative nameservers (covered above)
SRV defines services with port and priority information
CAA restricts which certificate authorities can issue certificates for the domain
PTR maps an IP back to a name (used in reverse DNS zones, covered in our reverse DNS guide)

The @ Symbol and Bare Records

The @ in records like @ IN A 203.0.113.10 refers to the zone apex, the bare domain itself (example.com with no subdomain). This is why the apex can have A records but, as we explained in our A record vs CNAME guide, cannot have a CNAME: the apex must hold the SOA and NS records, and a CNAME can't coexist with other records at the same name.

Reverse Zone Files

The zone file we've discussed is a forward zone, mapping names to IPs. There are also reverse zone files that map IPs back to names using PTR records. These live under the special in-addr.arpa (IPv4) or ip6.arpa (IPv6) hierarchy and are typically managed by whoever controls the IP address block, often your hosting provider rather than you. Reverse zones are essential for email deliverability, which we cover in detail in the reverse DNS article linked above.

How Zone Files Relate to Managed DNS

If you use a managed DNS provider (Cloudflare, Route 53, Google Cloud DNS, etc.), you probably never see a raw zone file. The provider's dashboard presents records as form fields and tables. Behind the scenes, though, the provider maintains the equivalent of a zone file and serves it from their authoritative nameservers.

This abstraction is convenient, it handles serial incrementing, validates syntax, and prevents trailing-dot errors, but understanding the underlying zone file structure helps you reason about what the dashboard is actually doing. When a provider offers "zone export" or "import via zone file," they're giving you the raw text representation, which is useful for migrations and backups.

For self-hosted DNS, the zone file is the real, editable artifact. You edit it directly, increment the serial, and reload the zone. This gives maximum control but also means you're responsible for the syntax, the serial, and the correctness that managed providers handle automatically. We compare these approaches in our self-hosted vs managed DNS guide.

Common Zone File Mistakes

Forgetting the trailing dot on fully qualified names, causing the origin to be appended incorrectly. The number one zone file error.
Not incrementing the serial after changes, so secondary nameservers never pick up the update.
Multiple records that conflict, like a CNAME coexisting with other records at the same name, which violates DNS rules.
NS records not matching the registrar delegation, causing lame delegation.
Syntax errors (missing parentheses in the SOA, malformed records) that prevent the zone from loading at all.

In self-hosted environments, DNS server software usually validates the zone file when it loads and refuses to serve a zone with syntax errors, which is a useful safety net but can also cause an outage if a bad edit is deployed without testing.

How DNS Assistant Helps

Whether your records live in a hand-edited zone file or a managed provider's system, what matters is what resolvers actually receive when they query your domain. DNS Assistant monitors that, the live, authoritative answers, rather than the configuration source.

Record monitoring across all the record types found in a zone file (A, AAAA, MX, TXT, NS, CNAME, SOA, CAA, and more), with alerts when any value changes.
SOA serial tracking so you can see when your zone has been updated, useful for confirming changes propagated or detecting unexpected modifications.
NS delegation validation to catch lame delegation where your zone's NS records don't match the registrar.
DNSSEC validation of the chain of trust that protects your zone's authenticity.
Multi-channel alerting via email, Slack, Microsoft Teams, webhooks, and SMS.

This is especially valuable for self-hosted DNS, where a zone file edit that introduces an error, forgets a serial increment, or breaks a delegation can cause problems that are hard to spot from the configuration alone.

Check Your Zone

Use the DNS lookup tool at dnsassistant.com/tools to query your domain's records and see what your zone is actually serving, including your SOA and NS records. Run a Free Domain Risk Report for a comprehensive view of your DNS configuration.

For continuous monitoring of everything your zone serves, with real-time alerting, sign up at dnsassistant.com.

Start Monitoring Your DNS Today

Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.