DNS Zone File Validator

Introduction:

A DNS zone file is the authoritative text record of a zone: the owner names, record types, time to live values, and resource data a nameserver or DNS provider should publish. In BIND-style master files, shorthand such as @, relative names, inherited owners, $ORIGIN, $TTL, comments, and parenthesized records make the file compact, but they also make mistakes easy to miss during review.

Zone-file validation matters because DNS errors often fail after deployment, not while typing. A missing apex nameserver, a CNAME sharing a name with other records, a mail exchanger that points to a CNAME, a long TTL before migration, or an out-of-zone owner can produce confusing lookup behavior long after the file was imported. The safest time to catch those problems is before the zone reaches a public authoritative server or provider import workflow.

The apex records carry special weight. The zone apex normally needs a Start of Authority record and authoritative nameserver records. The SOA serial and timers guide zone maintenance and caching behavior. In-zone nameservers need address records and parent glue outside the zone. Long TTLs make a stable zone efficient, but they slow migrations and rollback because resolvers may keep old answers until the cache expires.

CNAME records have a stricter rule than many operators expect. A name that has a CNAME should not also have A, AAAA, MX, TXT, or other ordinary data at the same owner name. That is why apex CNAMEs are a problem in normal zone files: the apex already needs SOA and NS records. Provider features such as ALIAS or ANAME may simulate apex aliasing, but those are provider behaviors, not ordinary CNAME records inside a master file.

Mail-ready zones add another layer of review. MX targets should point to hosts with address records rather than aliases. SPF should usually appear as one TXT policy per owner, not several competing SPF rows. DMARC lives under _dmarc, and CAA records can constrain certificate issuance. A basic syntax pass can miss these operational checks because the rows can be syntactically valid while still being risky for mail, migration, or certificate workflows.

A zone-file validator is a pre-flight check, not a live delegation test. It can inspect the pasted source, expand names, check record relationships, and normalize output, but it cannot prove what parent registries, DNSSEC signing systems, secondary servers, provider importers, or public resolvers will serve after deployment.

How to Use This Tool:

Paste one complete zone file, choose the intended handoff target, and read the issue ledger before importing or loading the zone elsewhere.

1. Enter the Zone origin, such as example.com or a reverse zone. The origin is used to expand @ and relative owner names.
2. Choose the Validation target. BIND master file expects SOA and apex NS records, Provider import file is more cautious about directives, Signed DNSSEC handoff expects DNSSEC records, and Internal BIND view allows private addresses.
3. Select a Review profile. Public and mail-ready profiles add delegation, mail policy, CAA, and routable-address checks. Internal and migration profiles reduce some public-zone assumptions.
4. Set Record type policy to warn, fail, or allow unknown and private record types depending on how strict your receiving system is.
5. Paste the Zone file, browse a text file, or drop a .zone, .db, or .txt file onto the source area. The parser handles comments, quoted strings, parenthesized records, $ORIGIN, and $TTL.
6. Open Advanced to change the finding threshold, fallback TTL, TTL warning ceiling, and normalized owner format.
7. Use Issue Ledger for errors and warnings, Record Ledger for parsed rows, Zone Health Map for severity and type charts, Normalized Zone for diffable output, and JSON Export for structured diagnostics.

Interpreting Results:

The score starts from 100 and drops for errors, warnings, and notes. In standard review, errors carry the largest penalty and warnings carry a moderate penalty. Strict review makes warnings more consequential, while advisory scan keeps warnings lighter. A high score is useful, but the issue rows are more important than the number when a single error can block a zone load or break a record relationship.

The common false-confidence mistake is treating a clean text parse as a live DNS proof. After fixing source issues, still load the file with the authoritative nameserver or provider checker, confirm parent delegation and glue, and query the public result from more than one resolver after deployment.

Technical Details:

The parser converts raw zone text into logical DNS statements before checking records. It strips comments while respecting quoted strings, joins parenthesized multi-line records, detects unmatched parentheses and open quotes, and then walks directives and resource records in source order. Relative owners are expanded against the active origin, and inherited owners follow BIND-style master-file behavior.

Rule Core

The scoring model subtracts severity-weighted issues from a perfect score. Errors subtract 22 points each. Warnings subtract 9 points in strict review, 6 points in standard review, or 3 points in advisory scan. Informational notes subtract 1 point each. The final score is floored at zero.

In that expression, E is the error count, W is the warning count, I is the note count, and w is the warning weight selected by strictness. A score of 100 with no warnings is reassuring for the pasted text, but a score below 100 can still be acceptable when every remaining note is intentional and documented.

The normalized output is derived from parsed records, not from the original text formatting. It writes owner, effective TTL, class, type, and normalized RDATA in a consistent order. Host-valued RDATA such as NS, CNAME, PTR, MX, SRV, and SOA names are expanded where applicable so cross-provider diffs are easier to read.

Limitations and Privacy Notes:

The validator analyzes the pasted source locally in the browser. It does not query live DNS, ask a parent registry for delegation data, verify DNSSEC signatures, expand external include files, or guarantee that a DNS provider will accept every supported record type.

• $INCLUDE and $GENERATE are reported because this page does not expand them into concrete records.
• DNSSEC checks look for expected record presence in a signed handoff profile, not cryptographic validity.
• Provider features such as ALIAS, ANAME, flattening, synthetic records, and hidden SOA/NS handling can differ from a plain BIND-style zone file.

Worked Examples:

Public authoritative handoff. A zone includes one SOA, two apex NS records, address records for in-zone nameservers, A records for the apex, an MX host with an address, SPF, DMARC, and CAA. The issue ledger stays clear or shows only low-priority notes, and the normalized zone is ready for a final nameserver-side check.

Apex CNAME conflict. A migration file places @ IN CNAME vendor.example. at the apex. The validator reports a CNAME exclusivity error because the apex also needs SOA and NS records. The next action is to use provider-level aliasing or publish address records instead of a normal CNAME.

Mail profile cleanup. A mail-ready profile finds MX but no _dmarc TXT and two SPF TXT rows at the apex. The rows can be syntactically valid, yet the issue ledger asks for one merged SPF policy and a DMARC policy before mail handoff.

FAQ:

Does this replace named-checkzone?

No. Use it as a browser-side pre-flight review, then validate the final expanded file with the authoritative nameserver or provider tool that will actually load the zone.

Why does a provider import profile allow missing SOA and NS?

Many DNS providers manage SOA and authoritative NS records themselves. The provider profile still warns or errors on source patterns that commonly break imports, such as unexpanded directives.

Why are private addresses warned in public profiles?

Private or documentation-range addresses are usually wrong for public authoritative zones. Internal and split-horizon profiles reduce that warning because private addresses can be intentional there.

Why does a missing TTL still show an effective TTL?

The analysis uses the file's $TTL directive when present. If the file lacks one, it uses the selected fallback TTL for deterministic review and marks that inherited behavior in the issue ledger.

Glossary:

Zone origin

The base domain used to expand relative owner names in the zone file.

SOA

Start of Authority, the apex record that names the primary authority and serial/timer values for the zone.

TTL

Time to live, the number of seconds a resolver may cache an answer before refreshing it.

RDATA

The record-specific data after owner, TTL, class, and type.

In-bailiwick nameserver

A nameserver whose name is inside the zone it serves, often requiring address data and parent glue planning.

References:

• RFC 1035: Domain Implementation and Specification
• RFC 1034: Domain Names - Concepts and Facilities
• RFC 2308: Negative Caching of DNS Queries