Guide
Writing and checking a BIND zone file
Zone files are the text form of DNS, and they are unforgiving. A missing dot, a CNAME in the wrong place or a stale serial rarely produces an error at the moment you save; it produces an outage when the server reloads. The page has two modes: build a complete file from a table of records, or paste an existing zone and have it examined.
What a zone file contains
The file begins with two directives. $ORIGIN example.com. sets the domain that relative names are completed with, and $TTL 1h sets the default time to live. Then comes the SOA record with the primary server, the contact (with a dot for @), the serial and four timers, followed by the resource records, each with a name, optional TTL, class IN, type and data. The builder writes the SOA with sample timers of two hours for refresh, thirty minutes for retry, two weeks for expire and one hour for negative caching, each annotated with a comment, and lets you set the serial.
The trailing dot
The most common mistake in zone files is writing a target without its final dot. Inside a zone, a name that does not end in a dot is relative: the origin is appended. So MX 10 mail.example.com in the zone example.com points to mail.example.com.example.com, which does not exist, and mail disappears. The builder avoids it by adding the dot to targets that look like complete names. The checker flags the problem in files you paste.
The rules the checker applies
A zone needs an SOA and at least one NS at its apex. A name with a CNAME cannot hold any other record (RFC 1034), so a CNAME at the apex, where SOA and NS must exist, is an error. An MX or NS target must be a host name, not an IP address. A name server inside the zone needs address records so that the parent can publish glue. Addresses are checked for validity, and duplicate records are reported with both line numbers. TXT values longer than 255 bytes are written as several quoted strings.
A worked example
On the Build tab the sample produces a zone with two NS records, an address for ns1, an apex A record, www as a CNAME of @, an MX of 10 mail.example.com. and a TXT record "v=spf1 mx -all", and the checker confirms “No problems found”. On the Check tab, press Sample for a deliberately faulty file. The findings read: line 5, a name server inside the zone with no A or AAAA record, so glue is needed; line 7, the MX target mail.example.com has no trailing dot and is read as mail.example.com.example.com; line 8, a CNAME at the apex, plus the rule that a CNAME must be the only record at its name; line 10, 999.0.2.25 is not a valid IPv4 address; and line 11, a duplicate of line 9.
Limits
The checker looks for the common structural mistakes. It does not implement every record type or validate DNSSEC material, and directives beyond $ORIGIN and $TTL may not be handled. Run named-checkzone example.com example.com.zone from BIND before loading a zone into a live server, and remember to raise the serial. Nothing you enter is sent anywhere. To inspect the zone after publishing, use the DNS Lookup and SOA Lookup.
Related tools
- SOA Lookup reads the live SOA of a published zone.
- DNS TTL Calculator helps choose TTLs for your records.
- Reverse DNS Zone Generator builds the reverse zones for your addresses.
- DNS Compare verifies the published zone against another domain.
Checked against the current version of the BIND Zone File Generator on .