Six of the Actors in this catalogue read the same thing. Knowing exactly what that thing is explains every answer they give and every limit they state.
The registry's own record of delegation
A zone file is the authoritative list of what exists inside one top-level domain. When a registry delegates example.com, it publishes a record saying that the name exists and naming the servers that answer for it. The zone file is the accumulation of those records — not a crawl, not a sample, not an observation. It is the registry stating what it has done.
What is actually in a zone file
| Record | What it says |
|---|---|
NS | This domain exists and delegates to these nameservers |
DS | The parent vouches for this domain's DNSSEC signing key |
Glue A / AAAA | The address of a nameserver that lives inside this same zone |
That is close to the whole of it. Delegation, the signing vouch, and the minimum addressing needed to make the delegation resolvable.
What is not, and will not be
No registrant name. No email address. No registrar. No registration date, no expiry date, no status. Those live in registrar and registry databases reached through WHOIS or RDAP, which is a different source with different access rules — and, under the agreement that provides zone data, one that cannot be queried at scale alongside it.
Why a site's own records are somewhere else
A zone file says where a domain delegates. It does not say what those nameservers answer. The domain's A, MX, TXT and CNAME records are published by its nameservers, one level down, which is why a zone file cannot tell you where a site is hosted, where its mail goes or what platform it runs on.
What follows for every tool built on one
Delegation is certain, so “this domain exists” is a fact. Absence is ambiguous, so “this domain is free” is a verdict with an error rate. Change is visible only by comparing two snapshots, which is why a delegation change is detectable and a registration date is not. Every product built on this source is some arrangement of those three facts.
