Serve the right custodian first
The most expensive error in a domain production request is not the wording. It is the addressee.
The sponsoring registrar — the accredited company through which the registration is held — has the account file. A reseller may be the entity the registrant actually dealt with, and that relationship is invisible in public records; it surfaces only in the registrar's own documents. The registry operator has the transaction record behind delegation, status and transfer events, but has no customer. The hosting provider and the DNS provider may be three different companies from each other and from the registrar. A content delivery network knows the origin server; a lookup of a proxied name does not.
The regional internet registry is a common misdirection: its own guidance describes its role as helping identify which service provider may be connected to a particular end user, and points downstream to that provider for anything more specific. It also cautions that the address on a resource record is not a guarantee of the network's physical location.
Identify the accredited registrar of record and its published legal-process page before drafting anything. What to serve, on whom, and under what authority, is counsel's decision.
Registration and account records
Ask for these in the terms the governing agreements use, because that is how the custodian's own systems are organized.
- Registered Name Holder account records — account creation date, contact history, and the identity behind any privacy or proxy service.
- Registration data submitted electronically, with the submission dates and times and the content submitted — the record of what was supplied at application, which is not the same as what is published today.
- Written communications constituting registration applications, confirmations, modifications and terminations, and correspondence with the account holder.
- Payment records — the payment instrument on file, and the transaction identifiers for the relevant period.
The 2013 accreditation agreement obliges a registrar to maintain records of this kind during the term and for two years afterwards, and sets the outer bound at two years following a registration's deletion or transfer away (2013 RAA). Payment-source data and session records sit in a shorter-window category. Ask the custodian to state its retention periods and whether any responsive record has already been deleted — an absence explains very differently depending on the answer.
Transfer records and the Form of Authorization
Where control moved, the transfer file is the center of the matter.
The Form of Authorization is the record tying a transfer to an authorizing party. Under the Transfer Policy a registrar must retain it and produce a written or electronic copy to a losing registrar on request within five calendar days. Alongside it, the transfer dispute procedure enumerates what registrars are expected to hold for a transfer: a completed Form of Authorization, registration data output from the transfer-initiation date, identity verification documentation, the modification history, and the inter-registrar communications. That enumeration is a useful map of what to name, even where the dispute procedure itself is not the channel — it is registrar-to-registrar and a registrant is not a party to it.
Two mechanics are worth requesting records about explicitly. A sixty-day inter-registrar transfer lock follows a change of registrant, with an opt-out available to the registrant before the change is initiated; and status codes on the registration record what operations were permitted at each point. A transfer completing inside a window where a lock should have applied is a documented anomaly, and the records that explain it sit with the registrar and the registry.
Authentication, access and session logs
This is the category that answers "who did it", and it is the category most likely to be gone.
Name it specifically: log files documenting communication dates, times and session information; login and authentication records with source addresses; account access history; and the source and destination data associated with account activity. In the registrar context these sit in the short-retention category rather than with the registration records, on a floor measured in days rather than years. At hosting and DNS providers the windows are set by each provider, are commonly measured in weeks, and are frequently shorter than the time it takes to identify the right custodian and serve anything.
Two limits belong in the analysis rather than the request. An address in a log is not a person; converting one to the other requires records the custodian may never have held. And a completed authorization flow evidences that the flow completed, not that the human who owned the account performed it — which is precisely why the session and access records matter, and why their loss is rarely recoverable from anywhere else.
If nothing else is served early, serve this.
DNS, hosting and infrastructure records
Different custodians, different documents, and a different set of terms.
From the DNS provider: the zone as configured over the relevant period, the zone change history or audit log, and the account records identifying who made each edit. Public sources show what a name resolved to; only the provider shows who changed it.
From the hosting provider: account and billing records, server assignment and provisioning history, configuration and change logs, web server access logs for the period, and any forwarding or redirect configuration. Where a name was parked or monetized, the parking or advertising provider holds the ad-serving configuration and the revenue reporting, and the publisher or affiliate identifiers recovered from archived page source are what tie those accounts to the pages.
From a content delivery network: the origin server address and origin request logs. A resolution showing a proxying network's address establishes that relationship and nothing about the origin.
From the registry: the transaction history for the name — nameserver changes, status changes, transfer and renewal events — which is a different and more durable record than the registrar's.
What needs no process at all
A production request that asks for material already public wastes the request and returns a copy of what anyone could have collected.
Publicly retrievable: current registration data through RDAP, the structured successor to WHOIS that ICANN has treated as the definitive source for generic top-level domain registration information since 28 January 2025; commercial historical registration databases; Certificate Transparency log entries; web archive captures and their capture indexes; zone data through ICANN's zone-access service; regional internet registry allocation records; public routing-collector archives showing which network announced an address block over time; and passive DNS from sensor operators, typically under contract.
There is also a channel that sits between public and compelled. ICANN's Registration Data Request Service routes requests for nonpublic generic top-level domain registration data to participating registrars. Participation is voluntary, all communication and disclosure happens outside the system, ICANN has no role in the disclosure decision, and the service does not guarantee access to the data requested (ICANN RDRS). Whether it is worth using in a given matter is for counsel.
Constraints that shape what comes back
Four constraints determine the shape of a production, and none of them are negotiable by the requesting party.
Content is walled off. US-specific. Under the Stored Communications Act a covered provider is prohibited from divulging the contents of communications except as the statute enumerates, and a civil subpoena is not among the enumerated exceptions for contents (18 U.S.C. 2702). Providers say so in their published policies, and a request drafted to sweep in email content will be refused on that basis regardless of how it is worded.
Jurisdictional reach. Registrars publish which courts' process they accept, and a registrar outside the forum may be unreachable by that forum's process.
Customer notice is standard. Providers commonly notify the customer whose information is sought so that customer can move to quash, which means production is rarely silent.
Retention is registrar-specific. Retention floors have been waived on a case-by-case basis, so no single figure describes what any particular custodian still holds.
What a production will not contain
Even a complete, cooperative production has known boundaries, and stating them keeps the analysis honest.
It will not contain identity verification. Registrar accuracy obligations historically tested whether a contact point worked — whether a phone number, email or postal address responded — not whether the named person exists or is the person named. A complete, plausible registration record can be entirely fictitious.
It will not contain what happened before the registrar's involvement, or, for a name that moved between registrars, the earlier registrar's account file. Registrar consolidation compounds this: where a registrar has been acquired or wound up, account records may have moved, merged or become unrecoverable.
It will not contain the reseller relationship unless it is asked for by name.
It will not contain anything for a country-code top-level domain governed by these obligations, because ICANN consensus policies apply to generic top-level domains; each country-code registry sets its own retention and disclosure practice.
And it will not contain records that aged out. Which is why the shortest window, not the case schedule, sets the order in which requests go out.