Gera Tools

DNS Zone File Parser

Parse BIND-format DNS zone files and display records as a structured table.

Free BIND zone file parser. Tokenizes RFC 1035 master-file syntax (SOA, NS, MX, A, AAAA, CNAME, TXT) into a structured table with owner-name inheritance and TTL normalization. Runs entirely in your browser — nothing is uploaded. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What zone file syntax does this support?

It follows the RFC 1035 master file format used by BIND. It handles $ORIGIN and $TTL directives, owner-name inheritance, the @ origin shorthand, semicolon comments, and multi-line records wrapped in parentheses such as SOA.

A DNS zone file is the plain-text source of truth for a domain’s DNS records, written in the RFC 1035 master file format that BIND and most authoritative nameservers understand. When you export a zone from your DNS provider or migrate between hosts, it helps to see every record laid out cleanly with names, TTLs, and types resolved. This parser does exactly that in your browser.

How it works

The parser tokenizes the zone file the way a nameserver would when loading it:

  1. Lines are pre-processed: semicolon comments are stripped (while respecting quoted strings), and records wrapped in parentheses — such as a multi-line SOA — are joined into a single logical line.
  2. Directives $ORIGIN and $TTL update the current origin and default TTL.
  3. For each record, if the line begins with whitespace the owner name is inherited from the previous record; otherwise the first token is the owner name. @ expands to the origin, and names without a trailing dot get the origin appended.
  4. Optional TTL and class tokens (in either order) are detected, then the record type and remaining tokens become the RDATA.

TTL values such as 1h30m are normalized to seconds using the standard unit table (s, m, h, d, w).

Example

Given the directive $ORIGIN example.com. and the line:

www  IN  A  203.0.113.10

the parser resolves the owner name to www.example.com., class IN, type A, and RDATA 203.0.113.10. A blank-owner follow-up line inherits www automatically.

Notes

A successful parse confirms the file is syntactically well-formed — it does not query live DNS, so it will not tell you whether the records are actually published or propagated. Use it to audit exports, diff zones, or sanity-check hand-edited records before importing them.

Common zone file patterns to verify

When you receive a zone export from a registrar or DNS provider, several things are worth checking in the parsed output before importing it elsewhere:

SOA record completeness. The SOA should have a primary nameserver, a responsible mailbox (the @ is a literal dot, not an actual at-sign), and five timing values: serial, refresh, retry, expire, and minimum TTL. Missing or zero values here can cause secondary nameservers to refuse zone transfers.

Relative vs. fully-qualified names. A record like mail IN MX 10 relay with no trailing dot on relay means the parser will append the current $ORIGIN. If your RDATA refers to an external host (a third-party mail relay, for example), it must end with a dot. Parsing reveals this immediately.

TTL consistency. The parsed table shows the resolved TTL for every record in seconds. A common error is mixing 3600 and 1h and accidentally leaving some records at the $TTL default when you intended a shorter value. Scanning the numeric column in the table catches stray defaults.

Duplicate or conflicting CNAMEs. A CNAME cannot coexist with any other record at the same name. The structured table makes duplicates visible at a glance — scan the owner-name column for names that appear more than once and check whether any pair includes a CNAME.

Typical workflow

  1. Export your zone as plain text from your DNS control panel.
  2. Paste into this parser and read the structured table.
  3. Spot any flagged errors or suspicious records before importing at the new host.
  4. Use the normalized TTL column to confirm caching behaviour matches your intentions.