Dev
Fake DNS Record Generator
Used by developers, writers, and creators worldwide.
A fake DNS record generator is exactly what you need when hand-crafting zone file test data is eating your afternoon. This tool produces realistic A, CNAME, MX, and TXT records — including properly structured SPF and DMARC strings — formatted to BIND zone file conventions. Set any base domain and choose how many records to generate; the output varies TTL values, subdomain names like api, mail, and staging, and rdata fields in ways that reflect real-world configurations. Developers building DNS parsers, infrastructure engineers documenting Terraform modules, and trainers running DNS workshops all get plausible, copy-paste-ready fixture data without touching production zone files.
Loading usage…
Free forever — no account required
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Enter your target domain in the Domain field (e.g., acme-internal.io) to set the zone origin for all records.
- Set the Number of Records to match your testing needs — use 8 for quick parser tests, higher counts for stress tests.
- Click Generate to produce the zone file entries with varied record types, TTLs, and realistic rdata values.
- Copy the output and paste it directly into your parser, test fixture file, documentation block, or zone import tool.
- Re-click Generate to produce a fresh set with different hostnames and IPs each time you need non-duplicate test data.
Use Cases
- •Testing a Go or Python BIND zone-file parser against all four record types with realistic rdata
- •Populating README examples for a Terraform Route 53 or Cloudflare provider module
- •Mocking AWS Route 53 API responses in Postman collections or Jest integration tests
- •Generating per-session lab data for DNS administration workshops so every student cohort gets a fresh zone
- •Adding believable DNS output samples to runbooks and Confluence pages without redacting production records
Tips
- →For parser edge-case testing, generate two batches and concatenate them — this creates repeated subdomains with different TTLs, which parsers often handle incorrectly.
- →Use a .internal TLD (e.g., corp.internal) as your domain when generating records for private network documentation so readers immediately know the data is non-public.
- →If your test suite checks MX priority handling, generate 10+ records — the varied priority values across multiple MX entries will reveal ordering bugs in your code.
- →Pair the generated SPF TXT records with a DMARC checker tool to verify your security scanner correctly parses both policy types from the same zone.
- →When writing Terraform or Pulumi examples, generate 5 records and use one of each type — A, CNAME, MX, TXT — to show the full range of your DNS module's capabilities.
- →Avoid using the default example.com domain in committed documentation; swap it for a domain you own or a clearly fake TLD like .example to prevent confusion.
FAQ
what dns record types does this generator produce
The generator outputs A records with plausible IPv4 addresses, CNAME records pointing to realistic subdomains, MX records with priority values and mail server hostnames, and TXT records including SPF (v=spf1) and DMARC (v=DMARC1) entries. That covers the four types needed to simulate a believable, functional-looking zone file for parser and validator testing.
is the output valid bind zone file format
Yes. Every record follows the standard five-field layout: owner name, TTL, class (IN), type, and rdata. TTL values sit in realistic ranges like 300, 900, and 3600 seconds, so the output can be dropped straight into a BIND-compatible parser or validator without reformatting.
can i use a custom domain instead of example.com
Absolutely — just type any domain into the Base Domain field, such as acme-test.internal or staging.myapp.io, and every generated record will use it as the zone origin. This is handy when your test environment expects records scoped to a specific namespace and example.com would break assertions.