A DNS zone file is the closest thing the domain industry has to a census: for a given top-level domain, it lists what is registered and how it is delegated. That makes it the natural starting point for domain research — but a raw zone file is a long way from an actionable list. This article covers what the file actually contains, how access differs between gTLDs and ccTLDs, and what has to happen to the data before it is useful for SEO, investment or outreach work.
WebTrackly publishes TLD zone files, CMS and technology lists, and curated datasets as CSV files in ZIP archives. One-time purchases, instant download, no subscription required.
The Anatomy of a DNS Zone File
A DNS zone file is a plain text file describing a DNS zone. It maps domain names to IP addresses and other resources, defining how traffic for a domain is routed. At TLD scale these files are large: the .com zone covers 157,775,115 domains, while a mid-sized ccTLD may hold a few hundred thousand. Any parsing approach has to be designed for the size of the zone it targets — what works for a small ccTLD in a spreadsheet will not survive .com.
SOA Records: The Zone's Metadata
Every zone file begins with a Start of Authority (SOA) record. It holds the zone's metadata: the primary nameserver, the administrator's email address in DNS notation, a serial number, and timing parameters. The refresh value — how often a secondary server should check the primary for updates — commonly sits between one hour and 24 hours. The serial number is the practical field: it increments on change, which makes it a cheap way to confirm you are looking at a newer copy of a zone than the one you already have.
NS Records: Delegating Authority
Nameserver (NS) records specify which DNS servers are authoritative for a domain. In a TLD zone file these are the delegation records, and they are usually the only per-domain data present — a registry zone file typically contains delegations rather than the full record set for each domain. They are still useful: nameserver patterns identify the registrar or hosting platform behind a domain, and known parking nameservers can be filtered out before any further processing.
A and AAAA Records: The IP Address Connection
A records (IPv4) and AAAA records (IPv6) link a domain or subdomain to an IP address. These live in the domain's own zone, served by the nameservers the TLD delegates to, so obtaining them means resolving each domain rather than reading the TLD file. That resolution step is where hosting provider and geographic attribution come from, and it is considerably more expensive than parsing the zone file itself.
MX Records: The Mail Gatekeepers
Mail Exchanger (MX) records define which servers handle email for a domain, and in what priority order. They are also the fastest-moving records in practice: a domain can change mail providers without any other visible change. For anyone using domain data to plan email work, MX validity is worth re-checking close to the point of use rather than relying on a record captured weeks earlier.
Zone files, technology lists and curated datasets — CSV in ZIP, generated fresh at purchase from a source refreshed daily.
Sourcing Zone Files: The gTLD vs ccTLD Divide
Obtaining zone file data is not a uniform process. Access varies sharply between Generic Top-Level Domains (gTLDs) and Country Code Top-Level Domains (ccTLDs).
gTLD Zone Files: Relatively Accessible
For gTLDs such as .com, .net, .org, .xyz and .app, access is governed by ICANN's Centralized Zone Data Service (CZDS). Registries operating under ICANN contracts are required to make zone files available to approved requesters, who apply per TLD and agree to usage terms. Approval is per registry and can be refused or revoked, and files are published on a daily cycle. The process is workable but administrative: each TLD is a separate application, and access has to be maintained.
ccTLD Zone Files: The Data Acquisition Challenge
ccTLD zone files are considerably harder to obtain than gTLD ones. ccTLD registries operate outside ICANN's gTLD contracts and set their own policies. Some publish zone data to researchers under agreement, some publish nothing at all, and privacy-sensitive jurisdictions frequently fall into the second group — DENIC for .de and AFNIC for .fr both restrict bulk zone access rather than publishing openly. Where a registry does not publish, coverage has to be assembled from other sources: passive DNS, certificate transparency logs, crawl data and aggregated commercial datasets. That is why a genuinely global domain database is never a single pipeline.
The Noise Problem in Newly Registered Domains
Newly registered domain lists, derived from daily zone file diffs, are useful but noisy. A large share of any day's new registrations are parked pages, PPC placeholders, defensive registrations, or bulk registrations that will never host a real site. Working with the raw diff means working mostly with those.
The filtering that helps is straightforward in principle. Drop domains delegated to known parking nameservers. Deprioritise registrars whose new-registration volume is dominated by bulk activity. Resolve the survivors and check whether anything answers on HTTP. Each layer removes a chunk of the noise, and the layers are cheap to build compared with the cost of running outreach or analysis against an unfiltered list.
One caution worth stating: aggressive nameserver-based filtering has a real false-positive rate. Small businesses and personal projects frequently launch on the cheapest available hosting, whose nameservers look indistinguishable from low-value bulk registrations. Filtering on nameservers alone will discard legitimate domains, so it is better used as one signal among several than as a hard cut.
Fresh Lists vs Stale Marketplace Dumps
For outreach against newly registered domains, freshness matters more than volume. The reason is mechanical rather than statistical: the value of a new registration as a prospect lies in the fact that the owner is currently setting the domain up and is actively making decisions about hosting, design and marketing. A list that is 30 or 60 days old has passed that window — many of those domains are already built, already abandoned, or already flagged.
Bulk lists sold cheaply on general marketplaces are usually assembled once and resold repeatedly, which means the registration dates spread across months and the recipients have often been contacted before. A smaller list generated from a current zone diff, filtered down to the TLDs and platforms you actually target, is a different kind of asset even though it costs more per row.
Practical Takeaways
- Validate MX records close to use. MX data ages faster than almost anything else in a domain record. Re-check before a campaign rather than trusting a record captured earlier. Difficulty: moderate.
- Filter new registrations on more than one signal. Combine parking nameserver detection, registrar patterns and a basic HTTP check. Any one of them alone produces either too much noise or too many false negatives. Difficulty: high.
- Prioritise freshness over volume for outreach. A current, narrow list generated on a weekly or daily cadence outperforms a large stale dump. Difficulty: low to moderate.
- Do not assume a uniform file format. Zone files differ in record types, comment conventions and encoding between registries. Build the parser to fail loudly on unexpected input rather than silently dropping records. Difficulty: moderate.
- Buy aggregated data where direct access is closed. Where a registry does not publish, negotiating access is rarely worth the time. WebTrackly's catalog covers 716 TLD zones as ready-to-use CSV downloads. Difficulty: low.
716 TLD zone files, 79 CMS and technology lists, 27 curated datasets. One-time purchases from $3.50, delivered as CSV in ZIP.
FAQ Section
How frequently are DNS zone files updated?
Update frequency varies by TLD. Major gTLDs such as .com and .net publish daily, typically in the early hours UTC. Some ccTLDs publish weekly, less often, or not at all. WebTrackly's files are generated at the moment of purchase from a source refreshed daily, so a download reflects the current state rather than a stored export.
Can I get a full list of all domains from a zone file?
A TLD zone file contains the delegated domains registered under that TLD, so in principle yes for that one extension. Doing it across every TLD is the hard part: gTLD access runs through ICANN's CZDS with a separate application per registry, and many ccTLDs offer no public access at all. WebTrackly's zone catalog covers 716 zones, and the all-registered-domains dataset holds 272,614,863 rows.
What's the difference between a DNS zone file and a WHOIS database?
A DNS zone file lists domain names and their delegation records, describing how traffic is routed. A WHOIS database holds registration metadata — registrar, registration and expiration dates, and, where not redacted, registrant details. The two answer different questions. WebTrackly's packages cover the zone and technology side; they contain domains, not personal contact data.
How useful is newly registered domain data for lead generation?
It reliably tells you which domains were registered and when, which is a genuine timing signal. It does not tell you who registered them or whether the registration represents a real business — a large share of any day's new registrations are parked or defensive. Filtering by nameserver, registrar and a basic HTTP check is what turns the raw diff into something worth acting on, and contact discovery remains a separate step performed with your own tooling.
