DNS Record Generator & Zone File Builder

How to Build DNS Zone Files and Records

1. Specify your target domain name (e.g., example.com) and default TTL value.
2. Add or modify individual resource records (A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, PTR).
3. Use the Provider Presets tab to load recommended DNS record templates for Google Workspace, Microsoft 365, GitHub Pages, or Vercel.
4. Use the SPF Wizard and DMARC Wizard tabs to generate compliant email authentication records.
5. Review live syntax validation warnings (e.g., CNAME apex restrictions or missing trailing dots).
6. Copy the BIND zone file or download it directly as a .zone file for deployment.

Key Features

• Comprehensive Record Support: Build A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, and PTR records with custom TTLs and priorities.
• BIND Zone File Export: Live generator producing BIND-compatible zone files consistent with RFC 1035 and related DNS standards, with customizable Start of Authority (SOA) parameters.
• Interactive SPF Wizard: Generate v=spf1 records (RFC 7208) by selecting authorized mail sources (Google, Microsoft 365, Mailgun, SendGrid) and enforcement mechanisms (~all, -all), supporting IP addresses, CIDR ranges, hostnames, and include mechanisms.
• DMARC Policy Wizard: Build v=DMARC1 policy records (RFC 7489) with configurable policies (none, quarantine, reject), aggregate reporting addresses (rua=), optional filtering percentages (pct=), and SPF/DKIM alignment settings.
• Provider Presets: Recommended DNS record templates for Google Workspace, Microsoft 365, GitHub Pages, Vercel, and Cloudflare.
• 100% Offline & Private: All record generation and zone file formatting occur locally in your browser without transmitting data to external servers.

Common Use Cases

• Domain Migration: Generate zone files when migrating authoritative DNS between registrars or DNS hosting providers.
• Email Security Configuration: Prevent domain spoofing and improve inbox deliverability by deploying SPF and DMARC policies.
• Web App Hosting Setup: Quickly configure DNS records required to link custom domains to GitHub Pages, Vercel, AWS Amplify, or other hosted platforms.
• Name Server Administration: Maintain authoritative BIND zone files with configurable SOA serial numbers and TTL controls.

Frequently Asked Questions

What is a BIND Zone File?

A BIND zone file is a text file that stores the authoritative DNS data for a domain or zone. It includes directives such as $ORIGIN and $TTL, Start of Authority (SOA) parameters, and resource records (such as A, CNAME, MX, and TXT) that map domain names to IP addresses, hostnames, or external services.

Why does a CNAME record require a trailing dot?

In standard BIND zone file syntax, a trailing dot (e.g., target.example.com.) signifies a Fully Qualified Domain Name (FQDN). If the trailing dot is omitted, DNS servers append the zone's $ORIGIN domain to the target string, resulting in an unintended domain resolution (such as target.example.com.example.com).

Why is a CNAME prohibited at the domain apex (@)?

According to RFC 1034, a CNAME record cannot coexist with any other record type for the same hostname. Because the apex domain (@) must contain SOA and NS records, placing a standard CNAME at the apex creates a protocol conflict. Modern DNS providers offer custom ALIAS, ANAME, or CNAME flattening features to safely alias apex domains.

Why must MX records reference hostnames instead of IP addresses?

According to RFC 1035 and RFC 2181, an MX (Mail Exchanger) record's value must specify a domain name or hostname. It cannot point directly to an IP address. The referenced hostname must resolve to one or more valid A or AAAA records.

What is an SOA serial number and how is it used?

The Start of Authority (SOA) serial number is an unsigned 32-bit integer (commonly formatted as YYYYMMDDnn) that indicates the revision version of a DNS zone file. Secondary (slave) DNS servers compare their local serial number against the primary (master) server's serial number during refresh intervals to determine whether an incremental (IXFR) or full (AXFR) zone transfer is required to synchronize updated zone data.

What is the difference between SPF, DKIM, and DMARC?

• SPF (Sender Policy Framework, RFC 7208) specifies authorized mail sources using IP addresses, CIDR ranges, hostnames (a, mx), and include mechanisms for a domain.
• DKIM (DomainKeys Identified Mail, RFC 6376) uses public-key cryptography to digitally sign selected email headers and the message body, storing the signature in the DKIM-Signature header so receiving mail servers can verify message integrity and sender authenticity.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) builds on SPF and DKIM by evaluating domain alignment, publishing a policy for receiving servers on how to handle messages failing SPF and/or DKIM alignment (none, quarantine, reject), and enabling aggregate reporting (rua=).