{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Target{{ resultsReady ? values.target_label : '—' }} Origin{{ resultsReady ? values.origin : '—' }} Blockers{{ resultsReady ? values.blocker_count : '—' }}
Origin Authority Records {{ targetStageLabel }}
Paste one complete zone, or browse for a .zone, .db, .bind, or .txt file. No content is uploaded.
{{ sourceStatusText }}
Use a DNS name such as example.com or 2.0.192.in-addr.arpa.
The target changes required authority and handoff checks.
Mail adds MX/SPF/DMARC expectations; internal tolerates private addresses.
Use strict failure in CI and allow only when the target is known to support the type.
Standard weights warnings normally; strict blocks on warnings; advisory reduces their score weight.
Used only when the source provides no zone or record TTL.
s
Effective TTLs above this value receive a migration warning.
s
This changes only the normalized artifact, not parsing or lint findings.
SeverityLineCheckFindingNext actionCopy
{{ row.severity }}{{ row.line }}{{ row.check }}{{ row.message }}{{ row.action }}
No findings for the selected profile.
LineOwnerTypeTTLRDATACopy
{{ row.line }}{{ row.owner }}{{ row.type }}{{ row.ttl }}{{ row.rdata }}

The chart renderer is unavailable. Record counts remain available in the record ledger.

{{ values.normalized_zone }}
DNS Zone File Generator Draft a BIND or provider-ready DNS zone file with normalized records, SOA and TTL checks, plus mail and DNSSEC review warnings.
DNS Cache Capacity Calculator Estimate DNS resolver cache memory from insert churn and TTL, then compare budget headroom with upstream QPS and hit-versus-miss latency.
Reverse DNS Zone Generator Generate an IPv4 reverse DNS zone with PTR records and SOA validation plus RFC 2317 classless delegation and parent-zone CNAME guidance.
DoH Query Packet Crafter Build an exact DNS-over-HTTPS query packet, inspect its wire fields and EDNS options, then replay it with GET or POST against a resolver.

A zone file is the source text from which an authoritative DNS server or provider builds answers for a domain. One misplaced owner name can put a record outside the intended zone, a missing address can leave a nameserver or mail exchanger unreachable, and a long time to live can keep an incorrect answer in resolver caches after the source has been fixed.

Master-file syntax saves repetition. $ORIGIN supplies the base name for relative owners, @ denotes the zone apex, $TTL supplies a default cache lifetime, an omitted owner may inherit the previous owner, and parentheses join a record across lines. Those conveniences are useful, but they make review dependent on context rather than on each line alone.

A useful pre-import review separates four kinds of evidence:

  • Syntax checks whether directives and resource records can be separated and read.
  • Authority checks the Start of Authority (SOA) record, apex nameservers, serial, timers, and in-zone nameserver addresses.
  • Relationships catches CNAME conflicts, mail exchangers that point at aliases, missing in-zone addresses, and exact duplicate records.
  • Operational policy considers the import target, public or internal use, mail records, DNSSEC handoff, unknown types, and cache lifetime.

The right rule depends on the destination. A BIND primary zone normally needs SOA and apex NS records. A provider import may manage those records itself. An internal view can intentionally contain private addresses, while a public-zone review should flag them. A signed handoff needs DNSKEY and RRSIG material, but seeing those record types does not prove that signatures are cryptographically valid.

Parsing success does not prove that the live DNS is correct. Parent delegation, provider transformations, DNSSEC validation, authoritative convergence, and recursive-cache behavior exist outside the text file. Use zone-file validation before deployment, then check the receiving server or provider and query the served records afterward.

TTL values deserve planning rather than a universal good or bad label. A long TTL reduces repeated lookups but slows rollback; a short TTL helps a cutover but increases query traffic. The warning ceiling should reflect the change window, not serve as a permanent rule for every zone.

How to Use This Tool:

Validate the same complete zone text and origin that you plan to hand to the destination.

  1. Paste or load the Zone file, then enter the Zone origin without relying on a filename to supply it.
  2. Choose the Validation target and Review profile. These settings decide whether authority records, public addresses, mail policy, or DNSSEC records are expected.
  3. Set Record type policy. Fail unknown types for a controlled CI gate, warn during ordinary review, or allow them only when the receiving system is known to support the type.
  4. Adjust the Finding threshold, Fallback TTL, and TTL warning ceiling when the default policy does not match the handoff. The normalized owner format changes presentation only.
  5. Clear errors in the Finding ledger, review warnings against the destination, and inspect expanded owners and effective TTLs in the Record ledger before loading the zone.

Interpreting Results:

Zone load blocked means at least one error was found. Strict review needed means there are no errors, but strict mode promotes warnings into release blockers. A pass with warnings means the text cleared hard rules under standard or advisory review; it does not mean the warnings are irrelevant.

The score is a compact lint summary, not a DNS quality grade. Its warning penalty changes with the selected threshold, so scores from different strictness settings are not directly comparable. Read the error, warning, and note counts with the actual finding messages.

The normalized zone expands names and effective TTLs for inspection. It does not expand $INCLUDE or $GENERATE, contact a provider, load a nameserver, verify delegation, or validate DNSSEC signatures. Treat it as review evidence rather than a deployment guarantee.

Technical Details:

Zone parsing begins by removing semicolon comments outside quoted strings and joining parenthesized statements. Directives update the current origin or default TTL. Record owners are then expanded against the current origin, and TTLs are resolved in this order: explicit record TTL, current $TTL, then the configured fallback.

Rule Core

The parser applies record-local checks first, then evaluates relationships across the resulting record set.

Rule areaChecksImportant boundary
Names and scopeValid labels, owner expansion, and containment within the declared zone.Names may be at most 253 characters; each label may be at most 63 characters.
TTLDirective, record, and fallback TTLs; zero-TTL notes; ceiling warnings.Accepted DNS range is 0 to 2,147,483,647 seconds. The warning ceiling is 60 seconds or greater.
AuthorityRequired SOA and apex NS records, one SOA, SOA fields, serial, timers, and in-zone nameserver addresses.SOA serial is an unsigned 32-bit integer from 0 to 4,294,967,295.
Record dataBasic shapes for A, AAAA, NS, CNAME, DNAME, PTR, SOA, MX, SRV, and CAA records.MX preference and SRV priority, weight, and port use 0 to 65,535; CAA flags use 0 to 255.
RelationshipsCNAME exclusivity, apex CNAME, duplicate rows, MX aliases, and missing in-zone target addresses.A CNAME owner cannot also carry ordinary data at the same name.
Selected policyPublic/private address expectations, MX/SPF/DMARC presence, CAA note, unknown types, and DNSKEY/RRSIG presence.Presence checks do not prove delivery, delegation, provider acceptance, or cryptographic validity.

Formula Core

The lint score starts at 100, subtracts a fixed amount for each error and note, and uses a warning weight selected by the finding threshold.

S=max(0,round(100−22E−wW−N))

Here, E is the error count, W is the warning count, and N is the note count. The warning weight w is 9 for strict review, 6 for standard review, and 3 for advisory review. The score is rounded to a whole number and cannot fall below zero.

Blockers are counted separately from the score. Every error is a blocker; warnings also become blockers only in strict mode. Notes never block. This is why two reviews can show the same findings but different score and release status when their threshold settings differ.

Limitations and Privacy Notes:

Zone text and selected files stay in the browser and are not uploaded. The review accepts source up to 500,000 characters.

  • $INCLUDE and $GENERATE are identified but not expanded.
  • The bounded CNAME rule treats every same-owner non-CNAME row as a conflict; use a DNSSEC-aware authoritative checker for signed-zone RRSIG and denial-of-existence exceptions.
  • IPv6 checking is a bounded textual check, not a complete canonical IPv6 parser.
  • Provider-specific ALIAS, ANAME, flattening, private types, and import transformations require the provider's own validator.
  • DNSSEC handoff review checks for record presence only; it does not verify signatures, key relationships, or parent DS data.
  • Final acceptance should include the authoritative server's zone checker, a load or import test, delegation checks, and live queries.

Worked Examples:

Mail-zone migration with a long TTL

A public zone has valid SOA, NS, A, and MX records, but its effective TTL is 172,800 seconds while the migration ceiling is 86,400. The mail-ready profile also finds no DMARC record. Neither condition is a syntax error, yet both appear as warnings. Standard review can pass with warnings; strict review blocks the handoff until the TTL plan and mail policy are resolved or deliberately accepted.

References: