ZoneProof FAQ

ZoneProof publishes machine-readable data about internet namespaces. For every top-level domain in the DNS root zone, ZoneProof maintains a structured record describing what the namespace is, who operates it, and what verification, if any, the registry requires before a name can be registered.

Some namespaces are open to anyone; others, like .bank or .pharmacy, are restricted to entities that have passed registry-enforced eligibility screening. That distinction has always existed, but it has not been queryable. ZoneProof makes it queryable by software, AI systems, and anyone who needs to know whether a domain's namespace carries verification guarantees.

ZoneProof covers the entire DNS root zone: generic TLDs, country-code TLDs, and internationalized TLDs delegated by IANA, plus delegated second-level public-suffix zones such as co.uk or gov.au where that data is available.

Namespace-level records exist for TLDs today, drawn from the IANA root database and ICANN Registry Agreements. Deeper domain-level records are being rolled out namespace by namespace, beginning with registry-verified TLDs where eligibility screening makes individual registrant records meaningful, including .bank, .cpa, .creditunion, .insurance, .pharmacy, and .post.

The party with authoritative control of the namespace at that level can claim a listing.

TLD listings can be claimed by the registry operator of record: the ccTLD manager listed in the IANA root database, or the signatory of the ICANN Registry Agreement for a gTLD.

Second-level public-suffix listings can be claimed by the entity that operates that zone, even if it differs from the parent TLD's manager.

Individual domain listings in registry-verified TLDs can be claimed by the domain's verified registrant, such as the bank, pharmacy, credit union, or licensed professional that holds the name.

Claiming confirms control of the record. It does not signal partnership with or endorsement of ZoneProof.

Claiming a listing for a TLD or an individual domain is free. If premium capabilities are introduced later, the baseline ability to claim and maintain an accurate listing will remain free.

Use the claim flow to find the listing, identify your organization, and provide your role with respect to the namespace.

ZoneProof verifies control by asking the claimant to publish a one-time DNS TXT token on the namespace, or, for individual domains, to place a small file at /.well-known/zoneproof.json. For TLD operators, confirmation through the contact of record with IANA or ICANN may also be available.

Once verification succeeds, the record can be marked as confirmed and your organization can be shown as the listing's confirmed operator or registrant. Bulk claiming is available for organizations claiming multiple listings under common control.

Because unclaimed records are inferred, and confirmed records are authoritative. ZoneProof builds baseline data from public sources such as the IANA root database, ICANN Registry Agreements, and zone data. That is useful, but it is still ZoneProof's inference.

When you claim your listing, the record is upgraded from inferred to confirmed, and that provenance is visible to systems that query it. As AI assistants and automated agents increasingly rely on structured data to decide which sources to trust, a confirmed record helps ensure they work from what you have asserted about your namespace, not only what can be deduced about it.

Claiming also creates a notification channel if your record changes, is disputed, or verification needs to be renewed.

ZoneProof runs an MCP server at https://zoneproof.org/mcp. MCP-capable AI clients can connect to it alongside an organization's own MCP servers.

The integration model is complementary. ZoneProof answers namespace and verification questions, such as whether a domain is in a restricted TLD, what screening its registry enforces, and whether a record is confirmed. Your own MCP servers can answer questions about your business or application.

A ZoneProof listing can also point to other machine-readable endpoints, including /.well-known/ resources, a domain-owned MCP server, or llms.txt, so agents discovering a domain through ZoneProof know where to go next.

Within defined limits. ZoneProof records follow a published schema, and fields are classified by how they are verified. Some fields come from systems of record like IANA and ICANN and cannot be edited by claimants. Other fields are asserted by the confirmed claimant and are labeled as such.

As a confirmed claimant, you can populate and maintain claimant-asserted fields such as organization display name, public contact points, official endpoints, and machine-readable resources. For domain listings, that can include content from your own /.well-known/zoneproof.json file.

You cannot alter verified facts, add promotional copy to query responses, or influence how ZoneProof characterizes other namespaces. That restraint is what makes a ZoneProof answer useful.

Email [email protected] with the record in question and, where possible, a pointer to the authoritative source that contradicts it, such as an IANA entry, ICANN Registry Agreement, or RDAP response.

Reports are triaged against the applicable system of record. ZoneProof corrects its data to match authoritative sources rather than adjudicating disagreements itself. If the issue concerns a claimed listing you do not control, the same channel can open a review and re-verification process.

There are two paths. First, richer data can be added to an existing record as new record types become available. For example, TLD operators of brand namespaces may be able to extend verification across second-level domains, and registrants in professional TLDs may be able to attach licensure credentials as that layer rolls out.

Second, if the ZoneProof schema or MCP tools do not yet support a question you need answered about your namespace, you can request a schema extension. Extension proposals are evaluated against the same standard as the rest of the dataset: the new field must be verifiable against an identifiable source. Accepted extensions may be published in the open schema for all namespaces, not just one requester.