DNS Zone File Validator – Check Syntax, Structure, and Misconfigurations
A DNS zone file is the authoritative text file that defines every DNS record for a domain. Even a small typo — a missing trailing dot, a malformed IP address, or a duplicate SOA record — can silently break email delivery, cause websites to become unreachable, or prevent DNS changes from propagating. This free, offline validator parses your zone file line-by-line and reports errors, warnings, and informational notes so you can fix problems before loading the file on a live name server.
What the Validator Checks
The validator analyses zone files against RFC 1034, RFC 1035, and related standards. It covers four main categories of issues:
| Category | Examples | Severity |
|---|---|---|
| Syntax errors | Invalid IPv4/IPv6 address, malformed TTL, missing record fields, @ in SOA email | Error |
| Structural issues | Missing SOA record, fewer than two NS records, duplicate SOA | Error / Warning |
| CNAME conflicts | CNAME sharing a name with A, MX, NS, or any other record type | Error |
| TTL inconsistencies | Record TTL deviating more than 10x from the $TTL default, TTL set to zero | Warning / Info |
The SOA Record — Why It Is Mandatory
The SOA (Start of Authority) record must appear exactly once in every zone file. It identifies the primary name server, the administrator's email address (with@ replaced by a dot), and five timing parameters that govern how secondary name servers synchronise with the primary. The validator checks that the serial number is a valid positive integer, flags serials that do not follow the recommended YYYYMMDDNN ten-digit format, and rejects admin emails that contain a literal@ character — a common mistake when copy-pasting from a contact form.
Understanding CNAME Conflicts
RFC 1034 §3.6.2 states that a CNAME record must not coexist with any other record at the same name. If a hostname has a CNAME, it is an alias — adding an A, MX, or NS record to the same name creates a contradiction that resolvers handle inconsistently. The most common real-world mistakes are:
- Placing a CNAME at the zone apex (
@) where SOA and NS records are required — this is always invalid. - Adding both a CNAME and an A record for a subdomain (e.g., trying to override a CDN alias with a direct IP).
- Pointing a mail subdomain with an MX record and then also giving it a CNAME.
The validator flags all of these cases with an error and identifies which record types conflict.
Trailing Dots and Relative Names
In zone file syntax, a hostname without a trailing dot is relative — the DNS server appends the current $ORIGIN to it. A hostname with a trailing dot is an FQDN (Fully Qualified Domain Name) and is used as-is. Forgetting a trailing dot on NS, MX, CNAME, or PTR targets is one of the most frequent zone file mistakes. For example, writing mail.example.com instead of mail.example.com. in an MX record will expand to mail.example.com.example.com. — a name that almost certainly does not resolve. The validator warns whenever a target hostname in these record types is missing its trailing dot.
TTL Recommendations
The TTL (Time To Live) on a DNS record controls how long resolvers cache it. Choosing sensible TTLs involves a trade-off:
Short TTL (300s) → Changes propagate in 5 minutes, but generates more queries
Long TTL (86400s) → Fewer queries, but changes can take up to 24 hours to propagate
Recommended → 3600s (1 hour) for most records; lower to 300s before planned changesThe validator warns if any record has a TTL below 60 seconds (likely to overload resolvers with excessive queries) or above 604,800 seconds (7 days), and flags records whose individual TTL deviates more than 10-fold from the zone default to help identify accidental mismatches.
Supported Record Types
The validator recognises and performs type-specific checks on A, AAAA, CNAME, MX, NS, SOA, TXT, PTR, SRV, and CAA records, as well as the DNSSEC types DNSKEY, DS, RRSIG, and NSEC (syntax only). The $TTL and $ORIGIN directives are parsed and taken into account throughout validation. Multi-line records using parentheses (common in SOA records) are automatically joined before parsing.
Validating Before Deployment
Before loading a zone file on a production name server, always validate it with both this tool and the server-native checker. For BIND 9, use named-checkzone example.com example.com.zone. For PowerDNS, use pdnsutil check-zone example.com. These server-side tools catch additional issues such as missing glue records and DNSSEC chain validation errors that go beyond what a browser-based parser can detect.