Domain name evidence, forensics and litigation support
Abstract nested ring illustration representing Domain Ownership Investigation

EvidenceAnalytical

Domain Ownership Investigation

Produces
A dated control timeline with sourced exhibits
Sources
Registry and registrar records, RDAP events, FOAs, archives
How it is obtained
Public records are retrievable; the account file is not
Authority
ICANN Transfer Policy; TDRP; 2013 RAA § 3.4; FRE 902(11)

Not who owns it, but who controlled it on a specific date, and which records can show that

Fix the question to a date, or it has no answer

"Who owns this domain" is not an answerable question, and an expert who answers it as asked has already conceded ground. Ownership of a domain name is not recorded anywhere as a property interest; what exists is a registration, sponsored by a registrar, managed through an account, with a record of who the registrant of record was said to be at particular moments. "Who controlled this name on March 14, 2022" is answerable from records. Every step that follows is anchored to that date.

It is worth being equally plain about what the answer is. Like attribution, a control finding is an inference assembled from converging documentary records, not a fact retrieved from a register. The records themselves are documentary: registry event data, transfer authorizations, account files, archived pages. The conclusion drawn from them — that a particular account, operated by a particular party, held control on the date in question — is an opinion, and it is stronger or weaker depending on how many independent records point the same way.

What strengthens it: a custodian-produced account record, a transfer authorization naming an authorizing party, and status codes that constrain what could have happened. What weakens it: reliance on a single aggregator's history, an unexplained gap in the timeline, or a registrant field that nobody ever verified.

Identify the sponsoring registrar before anything else

The sponsoring registrar, or registrar of record, is the ICANN-accredited company through whose account the domain is managed. The registry operator is the organization running the top-level domain's central database. The distinction decides the whole investigation, because control is exercised through a registrar account, while the registry holds only the sponsorship record and the domain's status.

So the first retrieval is the registrar of record on the date in question, together with its IANA registrar identifier, from registry data and from historical registration-data observations. That single fact determines two things: which custodian holds the account file that could name a controller, and which jurisdiction's process might reach it. A matter that appeared to be about a domain frequently turns out to be about which court's process a Canadian or German registrar accepts.

It also flags the ccTLD problem immediately. A ccTLD is a country-code top-level domain, and ICANN's consensus policies — the Transfer Policy, the transfer dispute rules, the Registrar Accreditation Agreement, the Registration Data Policy — apply to generic top-level domains. Each country-code registry sets its own rules for records, retention and disclosure. Any ccTLD in a matter is a jurisdiction-specific question from the outset, and none of the retention floors described below can be assumed to apply.

Reading the event history and the status codes

An RDAP response for a domain carries structured events, and the required set is informative on its own: registration, expiration, and the last update of the RDAP database must be present, while last changed, transfer and registrar expiration events are conditional and are omitted where the underlying event never occurred. The absence of a transfer event is therefore itself evidence, not an empty field.

Alongside the events sit the EPP status codes — machine-readable flags recording locks, holds and pending operations on a domain. A response must carry at least one. They matter because they constrain the narrative: a status code showing a name was locked in a period when a party says a change was made is a documented inconsistency that requires explanation, and in my experience it is the single most frequently ignored artifact in a domain dispute.

Two timestamps are being handled here, and confusing them is a common error. The event time is when the registry says a change occurred. The observation time is when a record of that state was captured by whoever captured it. A timeline that mixes them silently is unreliable, so each row of the control timeline records both, with time zones, and identifies which source supplied which.

Transfer mechanics as a test of the narrative

The ICANN Transfer Policy gives an investigation something valuable: a set of things that were supposed to happen, against which what actually happened can be measured. A Change of Registrant — a change to the registrant's identifying details, as distinct from moving a domain between registrars — triggers a 60-day inter-registrar transfer lock, from which the registrant may opt out before initiating the change. A transfer that occurred inside a window where a lock should have applied is a documented anomaly, and explaining it is a legitimate line of inquiry.

The central document is the Form of Authorization, the record showing that a transfer was authorized. Under the same policy a registrar must retain the FOA and produce a written or electronic copy to a losing registrar within five calendar days of a request. It is the artifact that ties a transfer to an authorizing party rather than to an assertion.

The transfer dispute rules go further and enumerate what each registrar is expected to be able to supply: a completed FOA, registration data output from the transfer initiation date, identity verification documentation, modification history, and inter-registrar communications. Those rules are a registrar-to-registrar mechanism and a party cannot file under them — but the enumeration is a reliable map of what a registrar ought to hold.

Registrant of record is not the same as controller

The registration record names a registrant. It does not tell you who had the password. An account can be operated by an employee, a contractor, a web agency that registered the name on a client's behalf, a former business partner, or an intruder, and the registration data looks identical in every one of those situations. This gap is where most ownership disputes actually live.

Closing it means corroborating with evidence of operation rather than registration. Name server delegation shows who was directing the domain's DNS. Hosting account records show who was paying for and configuring the server it pointed to. Certificates issued during the period show who could demonstrate control of the name to a certificate authority, which is a meaningful technical fact. Archived site content shows whose material was published under the name and when it changed.

None of those is conclusive either, and they can diverge from the registration in perfectly innocent ways — an agency legitimately runs a client's hosting. The value is in the pattern across the timeline. When registration control, DNS control and hosting control all move together on the same day, that is a coordinated act by someone with access to all three. When they move separately, the separation is the finding.

What an ownership investigation cannot establish

It cannot establish a property interest. The records show sponsorship, registration and control; the legal characterization of what rights those reflect is not an expert question and belongs to counsel.

It cannot establish that a named registrant is a real, correctly identified person. Registrar accuracy obligations require validation and verification of certain contact fields, which may include contacting the registrant by phone, email or postal mail, with suspension or deletion where verification does not occur in time. That is a test of whether a contact point functions, not of who somebody is.

It cannot recover records that have aged out, and the windows are shorter than most people expect. The transfer dispute filing window runs twelve months from the alleged violation. The Registrar Accreditation Agreement provides that a registrar is not obliged to maintain records relating to a registration beginning two years after that registration's deletion or transfer away. Fifteen months after sponsorship ends is the floor for transfer-dispute data elements. Past those points, the Form of Authorization and the account record may simply not exist, and nothing announces their departure.

It cannot assume uniformity across registrars. Retention windows have been reduced by waiver for registrars in some jurisdictions, and where a registrar has been acquired, de-accredited or wound up, account records may have been merged, moved or lost. For any ccTLD, none of these policies applies at all.

Reaching the account file, and the clocks against you

The registrar's records of the Registered Name Holder account — creation date, contact history, payment instrument, and where retained, login and session logs — are what convert "the public record said X" into "an account controlled by X made this change on this date." They are reachable only through legal process, through ICANN's request service for nonpublic registration data, or through the verification step of a filed dispute proceeding. Which of those is available in a given matter is for counsel to determine.

What is not for counsel is the calendar. The retention floors run from events in the domain's own history, not from the date anyone became aware of a problem, and they run while correspondence is still being exchanged. In a live matter the practical sequence is: identify the registrar of record, capture everything publicly available immediately, and put the retention windows on a schedule at the start of the engagement rather than discovering them later.

Where a record turns out to be absent, the report says which kind of absence it is: the record never existed, the retention window expired, the custodian declined, or it was never requested. Those are four different findings and they are not interchangeable.

What the deliverable looks like

The product is a dated control timeline: one row per observed state change — registration, registrar transfer, contact change, name server change, status code change, certificate issuance, site content change — each with its source record, the custodian who holds it, the event and observation timestamps, and the hash of the captured artifact. Behind the timeline sits the exhibit set: raw registration-data captures, registry records, transfer documentation and account records where produced, and archived pages.

A timeline of this kind almost always mixes two categories of evidence, and the report keeps them separate. Records produced by a registrar or registry are custodian records; in United States federal practice their authentication is generally approached through the certification routes for records of a regularly conducted activity and for records generated by an electronic process (FRE 902). Captures the expert made personally are authenticated instead by his own description of the collection process and his hash record. That is US-specific, and application in any matter is for counsel.

Then the opinion: control on the date in question, the records that support it, the independent lines of evidence that converge, and a plain statement of what the timeline does not show.

Frequently Asked Questions

Can an expert say who owns a domain name?

An expert can say who was the registrant of record on a date, which registrar sponsored the registration, what changes were made and when, and — as an opinion built from converging records — which account appears to have exercised control. That is different from ownership, which is a legal characterization for counsel and the tribunal rather than an expert conclusion. The distinction matters practically as well as formally: registration records identify an account, and accounts are routinely operated by employees, agencies, contractors and former partners rather than by the named registrant.

What is a Form of Authorization and why does it matter?

The Form of Authorization is the record showing that a domain transfer was authorized. It matters because it is the one transfer artifact that ties the movement of a name to an authorizing party rather than to an assertion made after the fact. Under ICANN's Transfer Policy a registrar must retain it and produce a written or electronic copy to a losing registrar within five calendar days of a request. In a disputed transfer it is normally the first document worth identifying, because the record-retention clocks run against it like everything else.

How far back can a domain's history be reconstructed?

Publicly, as far as third-party observations and archives happen to reach, which varies enormously by domain and is often thinner than expected for low-traffic names. From custodians, only as far as retention permits: two years after a registration's deletion or transfer away under the Registrar Accreditation Agreement, fifteen months after sponsorship ends for transfer-dispute data elements, and shorter periods for log and payment-source records. Those floors have also been reduced by waiver for registrars in some jurisdictions, so retention is registrar-specific rather than uniform.

Do EPP status codes actually prove anything?

They constrain what could have happened, which is frequently more useful than proving what did. Status codes record locks, holds and pending operations on a domain, and a response must carry at least one. If a name carried a lock during a period when a party's account says a change was made, that is a documented inconsistency requiring explanation. They are also among the most commonly overlooked artifacts in a domain matter, because they look like technical noise to anyone reading a lookup for names and dates.

What if the domain is a country-code domain rather than a .com?

Then almost none of the ICANN framework applies. The Transfer Policy, the transfer dispute rules, the Registrar Accreditation Agreement's record-keeping obligations and the Registration Data Policy govern generic top-level domains. Each country-code registry sets its own rules on transfers, records, retention and disclosure, and those rules sit within a national legal system. The investigative method is the same — fix a date, identify the custodian, reconstruct the events — but every policy assumption has to be re-established from that registry's own published rules.

Why does an ownership investigation start with capture rather than analysis?

Because the analysis can be done later and the capture cannot. Registration data, DNS answers and site content are all changeable by whoever controls them, without notice and without leaving a mark on the domain itself. Custodian records sit behind retention windows that expire on their own schedule. The first task in a live matter is therefore to preserve what is publicly available immediately, with timestamps and hashes, and only then to work out what it means. Analysis performed on records that have since moved is not reproducible.
Keep reading

The guides put the pieces in order

An entry covers one kind of work and the record it produces. A guide runs the sequence: when an expert is retained, what is preserved first, what has to be authenticated, and what the report has to carry.

A reference, not an intake page. This site describes what a domain name expert witness does and what the domain record can be made to show. It is not legal advice, nothing on it creates any relationship, and no engagement is taken through this website. The current record of credentials is at hartzer.com.

Top