DNS Zone File Validator

Introduction:

A DNS zone file turns a domain plan into the records an authoritative nameserver or DNS provider is expected to serve. The same text can decide where a website resolves, which hosts receive mail, how certificate authorities are restricted, which nameservers are authoritative, and how long resolvers may keep old answers. Because those records are copied into caches and sometimes imported into provider systems, a small mistake can last much longer than the edit that created it.

BIND-style master files are compact by design. Operators can use @ for the current origin, leave owner names relative, inherit the previous owner on indented lines, set a default $TTL, and split long records across parentheses. Those shortcuts make real zone files readable, but they also mean the text a person reviews is not always the fully expanded record set a server will load.

Origin

The base zone name used to expand relative owners, such as example.com..

Authority

The SOA and apex NS records that identify the zone's administrative source and authoritative nameservers.

TTL

The cache lifetime attached to an answer. Long values reduce repeat lookups but slow migrations and rollback.

RDATA

The record-specific value after the owner, TTL, class, and type, such as an address, host target, or TXT policy.

The apex deserves special care. A normal zone needs exactly one Start of Authority record at the top of the zone and authoritative nameserver records at the apex. In-bailiwick nameservers usually need address records and parent glue planning. Provider-managed zones may hide or rewrite some of that authority data, which is why import files and raw BIND master files are not always judged by the same rules.

CNAME handling is a common source of false confidence. A name with a CNAME is an alias and should not carry ordinary address, mail, or text records at the same owner name. That makes an apex CNAME invalid in a normal zone, because the apex already needs SOA and NS records. Provider features such as ALIAS, ANAME, or CNAME flattening can solve some apex-alias cases, but those are provider behaviors rather than plain CNAME rows in a master file.

Mail and certificate records add operational checks beyond syntax. MX targets should resolve to hosts with address records, not aliases. SPF is normally a single TXT policy per owner. DMARC lives below _dmarc, and CAA records can constrain certificate issuance. A zone can parse successfully while still being weak for mail delivery, migration, certificate issuance, or DNSSEC handoff.

Zone-file review is a pre-flight step, not proof of live delegation. A text check can catch malformed rows, risky relationships, and mismatched policy, but final confidence still comes from loading the zone with the receiving nameserver or provider, checking parent delegation, and querying the served records after deployment.

How to Use This Tool:

Use the validator before importing, loading, or handing off a complete BIND-style zone file.

1. Enter Zone origin with the authoritative zone name, such as example.com or 2.0.192.in-addr.arpa. The summary and record ledger should then show owners expanded inside that origin instead of drifting into another zone.
2. Choose Validation target. BIND master file and Internal BIND view expect SOA and apex NS records, Provider import file tolerates provider-managed authority, and Signed DNSSEC handoff adds DNSKEY and RRSIG expectations.
3. Select Review profile for the zone purpose. Public and mail-ready profiles add routable-address, delegation, SPF, DMARC, CAA, and mail-host checks; internal and migration profiles reduce public-zone assumptions.
4. Set Record type policy to warn, fail, or allow unknown types. Use fail for strict CI or provider imports, warn for mixed modern DNS records, and allow only when RFC3597-style or provider-specific rows are intentional.
5. Paste the Zone file, browse a .zone, .db, or .txt file, or load the sample. If syntax rows appear immediately, fix unclosed quotes, unmatched parentheses, missing owners, or missing RDATA before judging the cross-record findings.
6. Open Advanced when cache or output policy matters. Finding threshold changes warning weight, Fallback TTL supplies a deterministic inherited TTL when $TTL is absent, TTL warning ceiling flags long cache lifetimes, and Normalized owner format controls expanded or relative output.
7. Read Issue Ledger first, then use Record Ledger and Normalized Zone to verify the parsed record set. The chart tabs help summarize severity and record-type mix, while JSON is useful when another review system needs the diagnostics.

Interpreting Results:

The issue ledger matters more than the score. A single error can block a zone load or create an invalid record relationship, while several notes may simply document intentional choices. Treat errors as release blockers, warnings as review items, and notes as context that should be acknowledged before handoff.

Do not treat a clean parse as a live DNS result. After source issues are fixed, load the zone with the receiving nameserver or provider checker, confirm parent delegation and glue, and query served A, AAAA, MX, NS, TXT, CAA, DNSKEY, or RRSIG records from the resolvers that matter for the change.

Technical Details:

Zone validation starts by turning raw master-file text into logical DNS statements. Comments are removed while quoted strings are preserved, parenthesized records are joined, quoted strings and parentheses are checked for closure, and indented statements can inherit the previous owner. Directives such as $ORIGIN and $TTL update parsing context for the records that follow.

Rule Core

Score Formula

The health score is a compact triage number built from issue counts. It is useful for comparing repeat checks of the same zone, but it should not override a blocking error.

In the formula, E is the error count, W is the warning count, I is the note count, and w is the selected warning weight. Strict review uses 9, standard review uses 6, and advisory scan uses 3. Errors always subtract 22, notes subtract 1, and the final score is rounded and floored at zero.

Normalization Core

Normalized output is rebuilt from parsed records instead of source formatting. Owners can be expanded to fully qualified names or expressed relative to the origin. Effective TTLs are written from explicit record TTLs, the active $TTL, or the selected fallback TTL. Host-valued RDATA in NS, CNAME, DNAME, PTR, MX, SRV, and SOA records is expanded where applicable, while TXT and CAA values are quoted consistently.

For fair comparisons, keep the same zone origin, validation target, review profile, record type policy, fallback TTL, TTL warning ceiling, and normalized owner format between runs. Changing those settings can change both issue severity and the normalized handoff text.

Limitations and Privacy Notes:

The zone text is analyzed locally in the browser. The validator does not query live DNS, contact registries, expand external include files, verify DNSSEC signatures, run a nameserver's full loader, or prove that a provider will accept every record type.

• $INCLUDE and $GENERATE are reported because their final records need to be expanded by another process before production validation.
• DNSSEC handoff checks look for record presence and basic field counts, not cryptographic proof or chain-of-trust state.
• Provider features such as ALIAS, ANAME, flattening, hidden SOA/NS handling, and proprietary record types can behave differently from a plain master file.

Advanced Tips:

• Lower TTL warning ceiling during migration planning so long-lived records stand out before the cutover window starts.
• Use Provider import file when the receiving DNS service manages SOA and apex NS records, but keep a stricter BIND pass for zones that will be loaded by named.
• Choose Fail on unknown types for conservative import gates. Use a warning or allow policy only when the receiver supports RFC3597-style TYPE#### records or documented provider-specific types.
• Compare expanded and relative normalized owner formats when reviewing a migration. Expanded names are easier to diff across providers, while relative names stay closer to traditional zone-file style.
• Before sharing ledgers or normalized output, remove internal hostnames, private addresses, customer names, and unpublished DNSSEC material when those details are sensitive.

Worked Examples:

These examples show how common zone-file patterns should be read before the source is sent to a provider or authoritative server.

FAQ:

Glossary:

Zone origin

The base domain used to expand @ and relative owner names in a zone file.

SOA

Start of Authority, the apex record that carries the primary nameserver, responsible mailbox, serial, and zone timer values.

TTL

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

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 records and parent glue planning.

DNSSEC handoff

A transfer or review point where signed-zone records such as DNSKEY and RRSIG need to be present for the selected workflow.

References:

• RFC 1035: Domain Implementation and Specification
• RFC 2181: Clarifications to the DNS Specification
• RFC 2308: Negative Caching of DNS Queries
• Simplified Guide: How to query DNS records in Windows