DNS Zone Files Explained — Structure and Examples
A DNS zone file is a text file that contains the mappings between domain names and IP addresses for a specific domain. It is the authoritative source of DNS records for that domain. Every time a DNS resolver needs to answer a query about your domain, it reads from this zone file.
Zone files follow a strict format defined in RFC 1035. They consist of directives and resource records. Each line in the file represents either a comment, a control entry, or a DNS record. The format looks intimidating at first, but it is actually straightforward once you understand the structure.
If you use a managed DNS provider, you probably never see or touch zone files directly. The provider's control panel generates them for you. But understanding the zone file structure helps you debug DNS issues and appreciate what happens behind the scenes.
What Is a DNS Zone?
A DNS zone is a portion of the DNS namespace that is managed by a specific organization or administrator. For most people, a zone is simply their domain: example.com. The zone includes all the records for that domain and its subdomains.
Zones are divided at delegation points. When you delegate a subdomain like sub.example.com to different nameservers, sub.example.com becomes its own zone. The parent zone (example.com) contains NS records pointing to the child zone's nameservers. This hierarchical structure is how DNS scales to handle millions of domains.
The zone file sits on the authoritative nameserver. It contains all the records the server needs to answer queries about the domain. When you update a DNS record through your provider's control panel, the provider updates the zone file, increments the serial number, and propagates the change to all its nameservers.
Zone File Structure
A zone file starts with directives denoted by the $ character. The most common directive is $TTL, which sets the default TTL for all records that do not specify their own. Without a $TTL directive, resolvers would not know how long to cache the records.
Each resource record in the zone file follows this format: [name] [TTL] [class] [type] [data]. The name is the domain or subdomain. TTL is optional and overrides the default if specified. Class is almost always IN (Internet). Type is the record type like A, AAAA, or MX. Data is the value of the record.
If the name field is blank or starts with whitespace, the record inherits the name from the previous record. This saves space and makes the file more readable. The @ symbol represents the current zone origin, typically the domain name itself.
Semicolons start comments. Everything after a semicolon on the same line is ignored. Comments are used to document the zone file, mark sections, or temporarily disable records.
The SOA Record — Start of Authority
The SOA (Start of Authority) record is the first record in every zone file. It contains essential administrative information about the zone. Every zone must have exactly one SOA record. It is the record that defines the zone.
The SOA record includes the primary nameserver (the master server for the zone), the email address of the zone administrator (formatted with a dot instead of @), and a serial number. The serial number is critical. Secondary nameservers check the serial number to know when they need to update their copy of the zone. If the serial number on the primary is higher than the secondary's copy, the secondary initiates a zone transfer.
The SOA also contains timing values: refresh (how often secondaries check for updates), retry (how long to wait after a failed refresh), expire (how long secondaries can serve stale data if the primary is unreachable), and minimum TTL (the default TTL for negative responses). These values directly affect how quickly DNS changes propagate.
NS Records in Zone Files
NS records specify the authoritative nameservers for the zone. Every zone must have at least two NS records pointing to different nameservers for redundancy. The NS records appear in two places: in the zone file itself and at the parent zone (the TLD nameservers). Both should list the same nameservers.
When you register a domain and set nameservers at your registrar, you are configuring the NS records at the parent level. The zone file on your nameservers also contains NS records. If these two sets of NS records do not match, DNS resolution becomes unreliable. Some resolvers use the parent's NS records, and others use the zone's NS records.
Example Zone File
Here is what a complete zone file looks like for example.com:
$TTL 3600
@ IN SOA ns1.example.com. admin.example.com. (
2026070801 ; serial
3600 ; refresh
900 ; retry
604800 ; expire
86400 ; minimum TTL
)
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
@ IN A 192.0.2.1
@ IN AAAA 2001:db8::1
www IN A 192.0.2.1
mail IN A 192.0.2.2
@ IN MX 10 mail.example.com.
@ IN TXT "v=spf1 mx ~all"
Zone Transfers
Zone transfers are how secondary nameservers synchronize their copy of the zone with the primary nameserver. There are two types: AXFR (full zone transfer) and IXFR (incremental zone transfer). AXFR transfers the entire zone file. IXFR only transfers the changes since the last update.
Zone transfers are initiated by the secondary server when it detects that the serial number on the primary is higher than its local copy. The primary server must be configured to allow zone transfers from authorized secondary servers. Unauthorized zone transfers are a security risk because they expose all your DNS records to anyone who requests them.
In modern DNS management, zone files are rarely edited by hand. Managed DNS providers handle zone file generation, serial number management, and zone transfers automatically. If you use Cloudflare, AWS Route 53, or Google Cloud DNS, you never need to think about zone files. The provider abstracts all of this away.