DNS Zone File Generator

Introduction

A DNS zone file is the source text an authoritative name server loads to answer questions for a domain. A forward zone usually starts with a Start of Authority record, lists the authoritative name servers, and then adds the host, mail, alias, text, service, and certificate authority records that make the domain useful.

The value of a zone file is not just that it contains records. It gives those records an owner name, a record type, a time to live, and data that must fit the rules for that type. A missing trailing dot, stale serial, CNAME at the wrong owner, or in-zone mail host without an address can turn a neat-looking draft into a reload failure or a production surprise.

Zone files are most useful as change artifacts. They let an operator review the intended authority set, host ledger, and time values before a name server sees the change. That review matters for small sites too: a public zone with one name server, an MX target that has no address, or a serial that did not increase can fail in ways that are easy to miss in a control panel.

A generated zone draft is still a draft. It can organize records, normalize common input forms, and flag obvious mistakes, but it does not prove that a registrar delegation matches the zone, that parent glue is correct, that DNSSEC signing is complete, or that a production name server will accept policy choices outside the generated text.

Technical Details

DNS master-file text uses an owner name, optional TTL, class, type, and type-specific record data. In this tool's output the class is IN, the zone origin is declared with $ORIGIN, and records that do not carry their own TTL use the header value from $TTL. Relative owner names expand below the origin, while an owner of @ means the zone apex.

The Start of Authority record anchors the zone. Its primary name server field names the original source of zone data, the responsible mailbox uses DNS dot form rather than email-at-sign form, and the serial is the version value secondaries compare before transfer. The refresh, retry, expire, and minimum values are seconds-based timers used by authoritative service and caching behavior.

Most record rows are simpler than SOA, but their type-specific data still matters. An A record needs an IPv4 address, an AAAA record needs an IPv6 address, an MX record needs a priority plus host, and a TXT record is made from one or more character strings. CNAME records are aliases, so putting a CNAME at the apex or beside other records at the same owner is a blocking problem.

Rule Core

The generator turns structured inputs into a forward-zone draft and then labels issues as blocking errors, review warnings, or normalization notes. The checks are intentionally practical: they catch the common problems that should be fixed before a final linter or authoritative reload.

Transformation Core

The generated text is assembled in a stable order so the authority block is easy to audit before host records begin.

Record Type Details

The resource-record parser accepts a focused set of common forward-zone records rather than every DNS type. That keeps the generated text predictable and makes the checks more specific.

Everyday Use & Decision Guide

Start with the zone apex and authority records before adding host rows. Enter the bare domain, the default TTL, the primary nameserver, the responsible mailbox, the serial, and at least two authoritative nameservers. Then add mail exchangers and resource rows. This order mirrors how the generated zone is reviewed: authority first, services second, individual hosts last.

The resource-record area is best for a clean host ledger. A typical row such as www,A,192.0.2.10 inherits the default TTL, while api,A,192.0.2.20,300 sets a per-record TTL. For TXT values such as SPF strings, quote the CSV value when it contains spaces or commas, then leave Quote TXT values on unless your text is already fully escaped.

• Use Load sample when you want a complete starting shape with SOA, NS, MX, A, CNAME, and TXT records.
• Use Normalize after pasting URLs, mailbox-style domains, relative hostnames, or mixed-case names so the visible inputs match the generated owner and target names.
• Open Zone Checks before copying the zone. High rows are blocking input errors; Medium rows are operational warnings worth reviewing.
• Use Record Ledger when you need to audit each emitted record by owner, TTL, type, source, and record data.
• Use the JSON view when you want to compare generated inputs, records, and checks outside the text zone file.

The common mistake is treating a generated zone as publish-ready because the text has the right shape. A zone can still be wrong if the registrar delegation points somewhere else, the parent zone lacks needed glue, DNSSEC signing is handled separately, or the serial did not increase before reload. The safest first pass is to clear blocking rows, review warnings, then run the copied zone through named-checkzone or an equivalent linter.

Before you publish, check three fields together: Zone File for the final text, Record Ledger for what actually got emitted, and Zone Checks for warnings that could affect delegation, mail routing, or later cache behavior.

Step-by-Step Guide

1. Enter the zone domain as a bare name such as example.com. If you paste a URL or mailbox address, confirm the normalized domain is the zone you meant to manage.
2. Set the default TTL and SOA fields. Keep the serial increasing; YYYYMMDDnn is warned about only when the shape is unusual, but monotonic increase is the operational requirement.
3. Add the primary nameserver and responsible mailbox. Email form is converted to SOA responsible-mailbox dot form, with dots in the local part escaped.
4. List authoritative nameservers and mail exchangers. For public zones, treat a single nameserver warning as a prompt to add another authoritative server.
5. Add resource rows using CSV form. Use supported types only, and include the extra priority, weight, port, flags, or tag fields required by MX, SRV, and CAA records.
6. Open Advanced only when you need to adjust SOA refresh, retry, expire, minimum, TXT quoting, or generated comments.
7. Review the summary badges and Zone Checks. Fix High rows before you copy or download anything for production use.
8. Copy or download the zone text, then validate it with your name-server tooling before deployment.

Interpreting Results

The summary headline tells you whether the current draft needs edits, has warnings, or is ready for a linter. Needs edits means at least one blocking input error exists. Review warnings means the generated zone text may still be syntactically usable, but an operator should check the listed condition before publishing.

Zone File is the actual master-file text generated from the current inputs. If comments are enabled, the header reminds you to review the file with a zone checker. If blocking errors exist, the generated text includes that reminder too, because the tool still shows draft output even when the inputs need correction.

• High checks should stop the change. Examples include invalid domains, invalid IP addresses, unsupported record types, missing nameservers, out-of-range values, and CNAME conflicts.
• Medium checks deserve operational review. Examples include one authoritative nameserver, missing in-zone address records for NS or MX targets, retry not shorter than refresh, expire not larger than refresh, and duplicate removals.
• Info checks are useful audit notes. They show normalization decisions, SOA summary data, record counts, and reminders about serial increments and final linting.
• The ledger count includes SOA, NS, MX, and resource records. A healthy-looking count does not prove that outside delegation, glue, or signing state is correct.

Worked Examples

Small public site zone

A site owner enters example.com, keeps 3600 as the default TTL, lists ns1.example.com. and ns2.example.com., and adds ns1,A,192.0.2.53, ns2,A,192.0.2.54, @,A,192.0.2.10, and www,CNAME,@. The generated zone has SOA, two NS records, no MX records unless one is added, and a host ledger that makes the in-zone nameserver addresses visible.

Mail-ready apex with SPF

An administrator adds 10 mail.example.com. to the mail-exchanger list and mail,A,192.0.2.25 to the resource rows. The SPF row is entered as @,TXT,"v=spf1 mx -all". With TXT quoting enabled, the SPF value is emitted as a quoted TXT string, and the in-zone MX warning stays clear because mail.example.com. has an address record.

CNAME conflict before deployment

A draft has api,CNAME,@ and api,A,192.0.2.20 at the same owner. The tool still builds a visible draft, but Zone Checks adds a high-severity row because that owner has a CNAME alongside other records. The fix is to choose one model: keep the alias or replace it with address records, not both.

FAQ

Glossary

Zone apex

The root owner of the zone, represented as @ in the generated master-file text.

SOA

Start of Authority record containing the primary name server, responsible mailbox, serial, and timing values for the zone.

TTL

Time to live, measured in seconds, that tells caches how long a record can be reused before rechecking authoritative data.

RDATA

The type-specific data portion of a DNS record, such as an IPv4 address for A or a priority and host for MX.

Glue

Address records needed to reach an in-zone nameserver during delegation.

References

• RFC 1035: Domain Names - Implementation and Specification, IETF, November 1987.
• RFC 2308: Negative Caching of DNS Queries, IETF, March 1998.
• BIND 9 Manual Pages: named-checkzone, Internet Systems Consortium.