Summary

  • ICANN’s Centralized Zone Data Service standardizes the request and agreement, but it does not turn every zone-file application into one decision by ICANN. Credentialing, registry approval, compliance and user obligations remain distinct.
  • Approval grants a limited, non-transferable right to copy zone data, not ownership of names or control of a top-level domain. The unresolved control problem is time: the registry agreement sets no deadline for processing a request.

One request can still produce many decisions

CZDS offers a striking convenience: an interested party can use one portal to request access to zone files supplied by participating generic top-level-domain registries. For security teams, researchers and rights investigators, that removes the need to discover a different contract and delivery route for every gTLD.

Yet ICANN’s own guidance contains the sentence that defines the service’s governance gap. The registry agreement does not specify how long a registry operator must take to process a request. Central intake has therefore solved part of the transaction cost without creating a common clock.

That distinction matters. A request delayed for a day and one left unanswered for weeks enter through the same interface. Both may look administratively “pending”, even though their value for incident response, longitudinal measurement or abuse research is very different.

A zone file is useful, but it is not a title register

A gTLD zone file is a bulk view of names delegated in that top-level domain and the DNS records needed to find their authoritative servers. It can help an analyst observe additions, removals and infrastructure patterns. It is not a complete directory of registrants, and a name’s appearance in the file does not prove who owns it or why it was registered.

This boundary explains why access can be broad in principle and still limited by contract. Under the amended Specification 4, the user receives a non-exclusive, non-transferable and limited right to obtain a copy, generally no more than once per 24 hours. The permitted use cannot become unsolicited marketing, a high-volume query campaign against registries or registrars, or interference with registrants’ operations.

The copy is a research and operational input. It is not a licence to redistribute the database without limit, alter the zone or exercise registry power.

Three gates, not one

The amended agreement separates authorities that the portal visually compresses. First, the centralized zone-data access provider—ICANN or a designee—may reject a requester who does not satisfy credentialing requirements. That is an identity and contactability gate.

Second, the registry operator may reject a request when the credentials are incorrect or illegitimate, or when it reasonably believes the proposed use will breach the contractual restrictions. That is a provider decision bounded by stated grounds.

Third, a registry may revoke access when it has evidence that the user violated those restrictions. Revocation is not simply a delayed refusal; it depends on conduct after a grant. ICANN Contractual Compliance, meanwhile, receives complaints about a registry’s obligation to provide third-party access. Compliance review is not the same act as approving the original request.

The result is a chain of accountable decisions: common credentialing, registry provision, user conduct and contractual oversight. Calling all of it “ICANN approval” would obscure who acted and which remedy applies.

Sources