{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Target {{ resultsReady ? artifacts.compatibility.short : '—' }} Record types {{ resultsReady ? computation.values.record_type_count : '—' }} Default TTL {{ resultsReady ? `${computation.values.default_ttl_seconds} s` : '—' }}
Provider imports omit SOA but retain the record draft for review.
Choose the operational context that should drive review findings.
Use a bare forward-zone name such as example.com.
300, 3600, and 86400 seconds are common operational values.
seconds
Use a trailing dot for an absolute hostname, such as ns1.example.com.
Enter hostmaster@example.com or an already normalized absolute RNAME.
BIND output requires a serial; provider-managed is valid only for provider import targets.
Use the UTC change date for a YYYYMMDDnn serial.
{{ serialInputHelp }}
Enter one absolute or relative nameserver hostname per line.
Use one priority and host per line, for example 10 mail.example.com.
Choose the narrowest family that covers the intended record set.
Use external signing and validation tools before DNSSEC publication.
{{ recordFamilyHelp }}
The default inherits $TTL and does not change entered values.
Default: 3600 seconds.
seconds
Default: 900 seconds; normally shorter than refresh.
seconds
Default: 1209600 seconds.
seconds
Default: 3600 seconds.
seconds
Off by default so the generated artifact contains only directives and records.
{{ include_comments ? 'Enabled' : 'Disabled' }}
{{ artifacts.zone_text }}

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

KindItemStatusDetailNext actionCopy
{{ row.kind }}{{ row.item }}{{ row.status }}{{ row.detail }}{{ row.action }}
DNS Zone File Validator Validate a DNS zone file before import, uncover authority and TTL conflicts, and inspect expanded records without uploading the source.
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.
DNS Configuration Report Audit a domain's public DNS for authority, address and mail-policy gaps while comparing TTL horizons and resolver-visible evidence across common records.
DNS Record Lookup Look up DNS records for a domain, URL or IP through Google or Cloudflare with response codes, returned TTL evidence and DNSSEC flags.

A DNS zone is the authoritative record set for one part of the domain namespace. Its records connect names to addresses, mail exchangers, aliases, verification text, service endpoints, and DNSSEC data. A zone file is one way to express that set for an authoritative server or a provider import.

Each resource record combines an owner name, time to live (TTL), class, type, and type-specific data. Relative names are interpreted beneath the zone origin, while a trailing dot marks an absolute name. Missing that distinction can quietly turn mail.example.com into mail.example.com.example.com.

SOA record
Identifies the primary authority, responsible mailbox, zone serial, refresh and retry timing, expiry interval, and negative-cache TTL.
NS records
Name the authoritative servers. Parent delegation and any required glue must agree with the final zone.
Zone serial
Versions the zone for secondary servers. It must change when a BIND-style master zone changes.
TTL
Controls how long cached answers may remain in use. Short TTLs can speed a planned change, but they do not repair inconsistent authoritative data.

Provider imports are not identical to BIND master files. Managed DNS services commonly control the SOA record themselves, so an import draft may omit SOA even though the logical zone still has one. DNSSEC is also a separate operational process: placing DNSSEC records in a draft does not sign the zone, publish the parent DS record, or prove the live chain validates.

A generated zone should therefore be treated as a reviewable draft. Syntax checks, provider previews, comparison with the existing record set, and live authoritative queries each catch a different class of error. Delegation changes and low-TTL rollouts still need a rollback plan.

How to Use This Tool:

Choose the deployment target first because it determines whether SOA data belongs in the output and which checks matter before publication.

  1. Select BIND master file or a provider import target, then choose the public, mail-ready, split-horizon, or migration profile that matches the zone's role.
  2. Enter the bare zone domain, default TTL, primary nameserver, responsible mailbox, serial strategy, authoritative nameservers, and optional mail exchangers.
  3. Choose the narrowest Record family and DNSSEC readiness mode that covers the intended records. Enter resource rows as CSV using owner, type, value, optional TTL, and optional priority.
  4. Review the advanced TTL policy and SOA refresh, retry, expire, and minimum values. BIND output needs an explicit serial; provider-managed serials are valid only for provider import targets.
  5. Resolve every blocking input issue, then inspect the zone text and audit findings. Warnings identify operational gaps such as missing address records, a single nameserver, or incomplete mail and DNSSEC data.
  6. Validate the saved artifact with named-checkzone for BIND or the receiving provider's import preview. Compare the live authoritative answers after publication.

Interpreting Results:

Zone draft ready to lint means the local normalization and validation rules passed without a review warning. It is not confirmation that an authoritative server or provider accepts the file.

  • The Zone File is the generated artifact. In provider modes it omits SOA and reports that authority data as provider-managed.
  • RR Mix counts emitted records by type. Use it to catch an unexpectedly empty or unbalanced draft, not as a quality score.
  • The Audit separates blocking errors from review warnings and normalization notes. Resolve a blocking error before trusting any output.
  • After publication, compare complete record sets across every authoritative server. Matching serials alone do not prove that every intended record is present.

Technical Details:

Zone generation normalizes the origin and record names before it renders master-file text. Relative record targets are expanded beneath the origin, absolute targets retain their trailing dot, and the responsible mailbox can be converted from email form to SOA RNAME form.

Transformation Core:

  1. Normalize the zone origin and validate DNS labels.
  2. Resolve the selected serial strategy and apply any TTL floor.
  3. Normalize SOA, NS, and MX data, then parse each resource-record CSV row.
  4. Validate type-specific values, remove exact duplicate resource rows, and test cross-record constraints.
  5. Render $ORIGIN, $TTL, optional SOA, then NS, MX, and remaining resource records.
  6. Project the same normalized record set into counts and audit findings.

Formula Core:

The provider-floor policy raises an entered TTL below 300 seconds; the other policies leave the entered value unchanged.

Teffective = max(Tentered,Tfloor)

For the UTC date-plus-revision strategy, an eight-digit date and a two-digit revision form a conventional ten-digit serial.

Sdate = 100×D+r where0≤r≤99

For example, date digits 20260901 and revision 3 produce serial 2026090103. All explicit serials must contain digits and fit within the unsigned 32-bit maximum of 4,294,967,295.

Rule Core:

AreaBlocking ruleReview signal
NamesOwners must stay inside the zone and use valid labels. A or AAAA data must be a valid address.In-zone NS or MX targets without an A or AAAA record are flagged.
CNAMEA CNAME cannot coexist with another record at the same owner, and the zone apex cannot be a CNAME.None; these conflicts block output.
AuthorityAt least one authoritative nameserver is required.Public zones with one NS, or a primary NS absent from the NS list, are flagged.
SOA timingValues must be whole seconds from 0 through 2,147,483,647.Retry not shorter than refresh, or expire not greater than refresh, is flagged.
Mail-ready profileEntered MX rows must have a priority from 0 through 65,535 and a valid target.Missing apex MX, SPF TXT, or _dmarc TXT records are flagged.
DNSSECDNSSEC record types are accepted only by the relevant family or readiness mode.Signed import checks for DNSKEY, RRSIG, and NSEC or NSEC3; parent handoff checks for DS, CDS, or CDNSKEY.
Raw importEach row still needs owner, type, and non-empty record data.Unknown record types are preserved without type-specific validation.

Standard record families accept A, AAAA, CAA, CNAME, MX, NS, SRV, and TXT. The service family adds HTTPS, NAPTR, SSHFP, SVCB, TLSA, and URI. DNSSEC modes add CDNSKEY, CDS, DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, and RRSIG. TXT data is escaped and split into quoted chunks of up to 240 characters for readable master-file output.

Limitations and Accuracy Notes:

Local validation catches supported syntax and cross-record problems, but it cannot reproduce every authoritative server, provider importer, registry, or resolver policy.

  • Provider modes are drafts. Confirm how the destination manages apex SOA and NS records, unsupported directives, aliases, and DNSSEC data.
  • Raw import preserves unfamiliar record data with limited validation. Check that data against the receiving platform and the record type's specification.
  • Signer-ready and signed-import modes do not sign a zone or validate a live DNSSEC chain.
  • Split-horizon zones require checks from the intended resolver view. Public queries cannot prove private-view behavior.
  • No local warning proves that delegation, glue, transfers, firewall access, or cached resolver answers are correct.

Worked Examples:

BIND authoritative draft

A public zone for example.com with two nameservers, serial 2026090101, and a 3,600-second default TTL emits $ORIGIN, $TTL, SOA, NS, MX, and entered resource records. Save the text and run named-checkzone example.com zonefile before loading it.

Provider mail-zone import

Choosing a provider import and the mail-ready profile omits SOA from the artifact. If the record set has an MX entry but no apex SPF TXT or _dmarc policy, the draft remains usable for review but reports those missing mail-policy records before publication.

References: