DNS Zone File Validator

How to use

1. Paste the zone file into the box. It stays in the browser — nothing is uploaded and no lookup is made.
2. Leave the origin box empty if the file starts with $ORIGIN. If it does not, type the zone name there, exactly as the server configuration names it, because the same file means different things under different origins.
3. If the file does not parse, read the line number and the line printed under it: the error is reported where the parser gave up, which for a stray closing quote or an unclosed parenthesis can be one line after the mistake.
4. Check the SOA panel: the responsible mailbox is shown as an email address, and each timer is shown in seconds with a human-readable form beside it.
5. Work through the findings from top to bottom — errors first, then warnings, then notes — and use the line number on each one to jump back to the offending record.

Frequently asked questions

Why did my CNAME turn into example.com.example.com.?

Because the target had no trailing dot. In a master file every name is relative to the current origin unless it ends in a dot, and the parser has no way to know that "example.com" was meant as a fully qualified name rather than as a host called example.com inside your zone. The rule applies to every name field, not just CNAME: MX targets, NS targets, SRV targets and the SOA's primary server all get the origin appended the same way. The habit that avoids it is to write every name that leaves your zone with the dot, and to write the ones inside it as bare labels.

The file has no $TTL. Is that an error?

Not necessarily. RFC 1035 had no $TTL directive at all; RFC 2308 added it and required it, but most parsers, dnspython included, still fall back to the SOA's minimum field for any record that has no TTL of its own — and if the SOA is the first record, its own TTL comes from its minimum too. A record with no TTL that appears before the SOA and before any $TTL is a real error, since there is nothing to inherit from. This tool reports the fallback as a note and tells you which value ended up being used.

Two records with the same name and type have different TTLs. Which one wins?

Neither, really. All the records of one name and type form a single RRset, and an RRset is served with one TTL; when a file gives several, a loader keeps the smallest and there is no warning in the log. That means a 60-second record next to a 86400-second record of the same name and type makes both of them 60 seconds, which is usually the opposite of what the author intended. The tool shows the effective TTL in the table and flags each line whose written TTL was overridden.

Why is a record with a name outside the zone missing from the table?

Because it is missing from the zone. A loader only keeps records whose owner name is at or below the zone origin; anything else is out-of-zone data, and it is discarded silently rather than rejected. This is how a PTR record pasted into a forward zone, or a leftover record from a previous origin after a $ORIGIN line, disappears without the file ever failing to load. The tool lists each dropped name as a finding so the disappearance is at least visible.

Can a TXT record be longer than 255 characters?

The record can; a single string inside it cannot. A character-string in DNS carries a one-octet length, so 255 is the hard ceiling, and a longer quoted string is a syntax error rather than a truncation. The way to write a long DKIM or SPF value is as several quoted chunks on one record — "part one" "part two" — which the server concatenates with nothing in between. Resolvers hand the pieces to the application separately, so a value split at an arbitrary point still reassembles correctly, but only if the pieces are in the right order.

Does a valid zone file mean DNS will work?

No. Parsing proves the syntax, and the extra checks here prove some internal consistency, but nothing in a file can tell you that the parent zone delegates to your nameservers, that those servers have loaded this version, that the addresses are reachable, or that the serial you bumped is actually higher than the one your secondaries already hold. Serial comparison in particular is 32-bit sequence-space arithmetic, so a serial that "went down" because someone typed a date wrong can leave secondaries stuck on the old zone until the number wraps far enough round.

Related tools