DNS Zone File Generator
Draft DNS zone files from SOA, nameserver, mail, DNSSEC, and host records with TTL checks, ledger rows, and lint-ready exports.- {{ error }}
{{ 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 }} |
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.
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.
- 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.
- Choose the Zone profile that matches the draft. Public, mail-ready, internal, and migration profiles change which warnings matter most.
- 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.
- Add Authoritative nameservers and Mail exchangers. In-zone NS and MX hosts should also appear as A or AAAA records in the resource rows.
- Select Record family and DNSSEC readiness before entering records, because those choices decide which record types are accepted or preserved.
- 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.
- Open Advanced when SOA timers, TXT quoting, generated comments, or TTL floor policy need to match a change request or provider limit.
- 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.
| 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.
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:
| 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:
| 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:
| 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.
References:
- RFC 1035: Domain Names - Implementation and Specification, IETF, November 1987.
- RFC 1982: Serial Number Arithmetic, IETF, August 1996.
- RFC 2181: Clarifications to the DNS Specification, IETF, July 1997.
- RFC 2308: Negative Caching of DNS Queries, IETF, March 1998.
- RFC 4033: DNS Security Introduction and Requirements, IETF, March 2005.
- BIND 9 named-checkzone reference, Internet Systems Consortium.
- How to check DNS resolution in Linux, Simplified Guide.
- How to query DNS records in Windows, Simplified Guide.