{{ result.summaryTitle }}
{{ result.primary }}
{{ result.summaryLine }}
{{ badge.label }}
$ORIGIN {{ zoneStageRecordCountLabel }} {{ zoneStageTtlLabel }}
DNS zone file generator inputs
Choose the target that will receive the generated file so SOA and policy checks match the workflow.
Public authority expects resilient delegation; mail-ready checks SPF/DMARC cues; internal and migration profiles adjust warnings.
Use a bare domain such as example.com; trailing dots, URLs, and mailbox domains are normalized.
Seconds accepted; 300, 3600, and 86400 are common operational values.
seconds
Use an authoritative nameserver hostname; relative labels are expanded under the zone.
Provider minimum raises values below 300 seconds in the generated text and records the adjustment in checks.
Enter hostmaster@example.com or hostmaster.example.com.; the zone file uses DNS RNAME syntax.
Use an increasing unsigned 32-bit value, for example 2026050401.
Manual uses the field above; date and Unix strategies generate the SOA serial in the output and JSON.
Enter one hostname per line; in-zone nameservers should also have A or AAAA records in the ledger.
Use one priority and hostname per line, for example 10 mail.example.com.
Standard keeps common forward-zone records; service and DNSSEC families admit their operational record types; raw import preserves unknown RDATA.
Unsigned keeps DNSSEC out of scope; signed import expects DNSKEY/RRSIG evidence; DS handoff focuses parent-delegation material.
{{ recordFamilyHelp }}
Rows are local only and update the zone text immediately.
Seconds accepted; 3600 is a common default for small zones.
seconds
Keep retry shorter than refresh so temporary transfer failures recover quickly.
seconds
Use a value comfortably larger than refresh and retry.
seconds
Use a value aligned with your negative caching policy.
seconds
Leave on unless your TXT RDATA is already fully escaped and quoted.
{{ quote_txt ? 'On' : 'Off' }}
Turn off when you need only records and directives in the exported file.
{{ include_comments ? 'On' : 'Off' }}
{{ result.zoneText }}
TTL Owner Type Output Source RDATA Copy
{{ row.ttl }} {{ row.owner }} {{ row.type }} {{ row.output }} {{ row.source }} {{ row.rdata }}
Severity Check Current Action Copy
{{ row.severity }} {{ row.check }} {{ row.current }} {{ row.action }}

        
Customize
Advanced
:

Introduction:

Authoritative DNS changes usually begin as a controlled text draft. A zone file defines the records for one DNS zone, such as example.com., before an authoritative name server or hosted DNS provider accepts those records and starts answering queries.

A zone is smaller than the public DNS tree. It has an origin, an apex, authority records, and resource records that describe host addresses, aliases, mail exchangers, text policies, service endpoints, certificate authority policy, and sometimes DNSSEC material. Names inside the file may be relative to the origin or absolute with a trailing dot, so a small punctuation choice can change the final fully qualified name.

Origin
The base domain used to expand relative owner names and targets.
Apex
The zone's own name, commonly written as @ in master-file text.
TTL
The cache lifetime, in seconds, attached to records or inherited from the file default.
RDATA
The type-specific value after the record type, such as an address, hostname, TXT string, or DNSSEC value.
DNS zone file anatomy showing origin, SOA timers, authority records, resource rows, review checks, and served answers

Common review failures come from details that look harmless in a text editor. A hostname without a trailing dot may be expanded under the origin, an apex CNAME conflicts with required authority data, an MX or in-zone NS target may lack an address record, and a serial that does not increase can prevent secondary servers from noticing a change.

A good draft reduces those mistakes before the real validation step. It still cannot prove parent delegation, registrar glue, DNSSEC signing, provider import acceptance, or authoritative-server reload behavior until those systems are checked directly.

How to Use This Tool:

Start with the zone's authority settings, add records, then use the generated checks before copying or downloading the zone text.

  1. Set Output compatibility for the target workflow. BIND master file emits SOA data, while provider import modes leave SOA handling to the receiving DNS provider.
  2. Choose the Zone profile that matches the draft. Public, mail-ready, internal, and migration profiles change which warnings matter most.
  3. Enter Zone domain, Default TTL, Primary nameserver, Responsible mailbox, and a serial strategy. URLs, mailbox domains, and trailing dots are normalized where the value can be safely understood.
  4. Add Authoritative nameservers and Mail exchangers. In-zone NS and MX hosts should also appear as A or AAAA records in the resource rows.
  5. Select Record family and DNSSEC readiness before entering records, because those choices decide which record types are accepted or preserved.
  6. Enter Resource records as CSV rows in owner, type, value, TTL, and priority form. Use Load sample for a known shape, Normalize after editing, and Reset records when you want to rebuild only the resource section.
  7. Open Advanced when SOA timers, TXT quoting, generated comments, or TTL floor policy need to match a change request or provider limit.
  8. Review Zone File, Record Ledger, Zone Checks, and JSON. Fix Needs edits before using the text, and read every Review warnings row before treating the draft as ready to lint.

    The generated zone text updates from the values on the page. The next operational step is still a real zone linter, provider import preview, or authoritative-server load test.

Interpreting Results:

Trust the status only after reading the supporting rows. The summary tells you whether the draft can be reviewed, but Zone Checks explains why a row is blocked, warned, or merely noted.

DNS zone generator result cues
Result cue What it means What to do next
Needs edits One or more high-severity checks found an input that makes the draft unsafe to use. Fix the named domain, TTL, serial, record type, address, or CNAME conflict first.
Review warnings The text can be assembled, but a practical DNS risk remains. Decide whether the warning fits the selected profile before linting or importing.
Ready to lint No blocking issues or review warnings were found by the page checks. Run named-checkzone or the target provider's import validation.
Record Ledger Each emitted or provider-managed row is expanded with TTL, owner, type, source, and RDATA. Use it to catch unexpected relative names, inherited TTLs, duplicate removals, or omitted SOA output.
DNSSEC readiness The selected DNSSEC posture affects record acceptance and warning text. Do not treat readiness notes as signatures, DS publication, validation, or key rollover.

A small draft can still be wrong when one owner name expands unexpectedly. A large draft can be acceptable when the ledger, checks, and external linter all agree.

The safest copy target is the final Zone File text after the Zone Checks tab has no blocking entries. If a provider import mode omits SOA, compare the provider-created apex records after import rather than assuming they match the draft settings.

Technical Details:

DNS master files describe records as owner name, optional TTL, class, type, and RDATA. $ORIGIN sets the base name for relative owners and targets, while $TTL supplies the default TTL for records that do not carry their own TTL. The generated records use Internet class IN.

The SOA record carries the primary nameserver, responsible mailbox, serial, refresh, retry, expire, and minimum values. The serial is an unsigned 32-bit value that secondary servers compare using DNS serial number arithmetic. Modern negative caching practice treats the SOA minimum field as the negative response TTL, so it affects how long resolvers may remember NXDOMAIN or no-data answers.

Formula Core:

TTL policy can leave inherited TTLs alone, write explicit TTL values, or raise low TTLs to a provider-friendly minimum. The effective emitted TTL is the entered record TTL when present, otherwise the default TTL, after any selected floor is applied.

EffectiveTTL = max ( RecordOrDefaultTTL , PolicyMinimumTTL )

If the provider floor is 300 seconds and a resource row enters 60 seconds, the ledger shows 300 seconds and the checks note the adjustment. If no floor is active, the same row keeps the entered TTL, subject to the accepted whole-second range.

Rule Core:

DNS zone generation and validation rules
Area Rule applied Result effect
Origin The zone domain must be a valid DNS name. URL and mailbox-shaped input can be reduced to the domain part. Invalid origins become blocking checks; valid origins control relative-name expansion.
TTL and timers Default TTL, resource TTL, and SOA timers must be whole seconds from 0 through 2147483647. Out-of-range values become blocking checks, and low values may be raised by the selected TTL policy.
Serial The SOA serial must be digits only and fit from 0 through 4294967295 when emitted. Date-shaped serials are encouraged for manual operation, but non-date serials warn rather than block.
Authority At least one NS record is required. A single NS warns unless the internal profile is selected. Weak public authority data appears in Zone Checks before publication.
CNAME A CNAME owner cannot be the apex and cannot share an owner with other resource records. Apex aliases and owner conflicts are blocking checks.
Mail-ready profile Mail-ready zones are checked for apex MX, SPF TXT, and _dmarc TXT policy cues. Missing mail policy records warn so delivery and authentication can be reviewed.
Duplicate records Exact duplicates with the same owner, TTL, type, and RDATA are removed. The emitted text stays shorter while distinct records remain intact.

Transformation Core:

DNS zone file transformation path
Stage Input shape Generated output
Header Zone domain and default TTL. $ORIGIN example.com. and $TTL 3600.
SOA Primary NS, responsible mailbox, serial, refresh, retry, expire, and minimum. One apex SOA record for BIND master output, or provider-managed status for import modes.
Authority Nameserver list and mail exchanger list. Apex NS and MX records, with in-zone target address checks.
Resource rows CSV rows with owner, type, value, optional TTL, optional priority, and type-specific extra fields. Expanded owner names, normalized targets, quoted TXT strings, and ledger rows.
Review data Errors, warnings, policy notes, and emitted records. Zone text, record ledger, zone checks, and a JSON summary for audit or handoff.

Record Type Notes:

Supported DNS record type expectations
Record family Accepted types Important behavior
Standard host and mail A, AAAA, CAA, CNAME, MX, NS, SRV, TXT Addresses, CAA fields, SRV priority/weight/port, MX priority, and TXT quoting receive type-specific checks.
Service discovery and security Standard types plus HTTPS, NAPTR, SSHFP, SVCB, TLSA, URI Specialized RDATA is preserved after owner and TTL checks, so external validation remains important.
DNSSEC and delegation Standard types plus CDNSKEY, CDS, DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG Readiness checks look for expected DNSSEC evidence but do not sign records or publish DS data.
Raw import pass-through Unknown uppercase record types that fit the accepted type-name pattern. RDATA is preserved with limited type-specific validation, making provider or authoritative validation mandatory.

TXT values are escaped when quoting is enabled, and long text is split into quoted chunks. Keep those chunks as one TXT record when moving the draft into DNS tooling.

Limitations and Privacy Notes:

A zone-file draft is not the same as an authoritative DNS deployment. Treat the output as configuration text that needs the same review you would apply to a firewall rule, mail-routing change, or certificate policy update.

  • The page does not query registrars, parent zones, hosted-zone APIs, live DNS, or authoritative servers.
  • Provider import modes do not prove that the receiving provider will accept every directive or record type.
  • DNSSEC readiness does not create signatures, validate RRSIG periods, publish DS records, or manage key rollover.
  • Rows are processed in the browser from the values on the page. Still avoid pasting confidential internal hostnames into shared screenshots, tickets, or exported files.

Worked Examples:

Small public site. With Zone domain set to example.com, Default TTL at 3600, nameservers ns1.example.com. and ns2.example.com., an MX line of 10 mail.example.com., and A rows for @, www, mail, ns1, and ns2, the summary should move toward Ready to lint. Confirm the Record Ledger shows two NS records, one MX record, and address records for the in-zone NS and MX hosts.

Provider TTL floor. A row such as api,A,192.0.2.20,60 with TTL policy set to Enforce 300-second provider floor becomes a 300-second row in the Record Ledger. Zone Checks records the adjustment so the change reviewer sees that the entered TTL was not emitted as written.

Mail-ready warning. If the Zone profile is Mail-ready public zone and the records include MX but omit apex SPF TXT or _dmarc TXT policy rows, the status can show Review warnings. The zone may still be syntactically usable, but the warnings identify mail-authentication items to settle before publication.

Apex alias block. A resource row of @,CNAME,www.example.net. produces Needs edits. The apex already carries SOA and NS data, so the Zone Checks tab blocks the alias instead of emitting a misleading apex CNAME draft.

Absolute target check. A CNAME value of cdn.example.net. remains outside the zone because of the trailing dot. Entering cdn.example.net without the dot is interpreted as relative and may expand below example.com., so the Record Ledger is the place to verify the final target name.

FAQ:

Can I publish the generated zone file directly?

Use it as a draft. Copy or download the Zone File only after fixing Needs edits, then run named-checkzone, a provider import preview, or an authoritative-server load test before production use.

Why did a record type get rejected?

The accepted types depend on Record family and DNSSEC readiness. Switch to the service, DNSSEC, or raw import path only when that matches the real zone workflow, because raw import preserves more RDATA with fewer type-specific checks.

Why does the trailing dot matter?

A trailing dot marks an absolute DNS name. Without it, a target such as cdn.example.net may be expanded under the current origin and become a different name in the Record Ledger.

What serial should I use?

Use a serial strategy your DNS operations can keep increasing. Manual serials must be digits within the unsigned 32-bit range. A YYYYMMDDnn value is a common review-friendly pattern, while other valid digit strings can still work but may prompt a warning.

Does DNSSEC readiness mean the zone is signed?

No. DNSSEC readiness changes accepted records and warnings. Signing, RRSIG validation, DS publication, and key rollover remain outside the generated draft.

Does the page check live DNS?

No. The checks come from the entered zone data and selected policies. They do not confirm parent delegation, glue, hosted-zone state, propagation, or authoritative answers.

Glossary:

Origin
The base DNS name used to expand relative names in the zone file.
Apex
The zone's own domain name, represented as @ in many master files.
SOA
The Start of Authority record that identifies the zone's primary source, responsible mailbox, serial, and timers.
Serial
The SOA version number secondary servers compare to detect zone changes.
TTL
The time, in seconds, that DNS answers may be cached.
RDATA
The value part of a DNS record after the owner, TTL, class, and type.
RRset
All records with the same owner name, class, and type.
Negative caching
Caching of negative answers such as NXDOMAIN or no-data responses.