Stolen Domain Litigation Support

By Bill Hartzer, domain name expert witness·August 10, 2026

Where this work starts

This page covers one thing: the evidentiary and litigation-support role once a hijacked or misappropriated domain has stopped being a recovery problem and become a case.

It deliberately does not cover how a hijack happens, what a registry lock does, or what a victim's recovery options are. Those are mechanism questions, they are covered thoroughly elsewhere, and repeating them here would put the wrong material in front of the wrong reader. The reader here is an attorney with a live matter who needs to know what record can be reconstructed, what it will prove, what it will not, and which of it has to be demanded from someone else before it disappears.

US-specific: the compelled-disclosure procedures, the Federal Rules of Evidence and the ACPA referred to below are United States law only. ICANN's transfer and dispute policies apply across generic extensions; country-code registries sit outside ICANN consensus policy and run their own rules, with their own retention obligations or none.

One framing point that governs everything after it. The records show what happened. Establishing who caused it requires records that the registrar may never have held, and an expert who blurs the two has produced an argument rather than an analysis.

The control timeline is the deliverable

The product is a timeline with one row per observed state change, each carrying its own source record and its own date, so that the moment control moved and the mechanism by which it moved are both documented and separately traceable.

Fix the pre-incident baseline. The registrant, registrar, name servers and registration status codes as they stood before the disputed change, from historical registration data and passive DNS.
Locate the change events. Registrar transfer, change of registrant, name server change, DNS record change, hosting change, certificate issuance — each dated from its own independent source rather than from a single narrative.
Read the status codes across the window. Locks, holds and pending operations record what constraints were in force, and therefore what should have been possible at each point.
Corroborate operational control independently. Certificate transparency entries in the window, hosting and address records, and archived site content each show who was operating the name, which may differ from who was recorded as its registrant.
Follow the onward chain. Names are commonly moved again, listed for sale, or sold to a party asserting good-faith purchase. Marketplace listings, escrow records and subsequent transfers are part of the same timeline, not a separate matter.

Built from independent sources, no date in the timeline rests on a single record — which is the property that makes it survive examination.

Test the transfer against the policy that was actually in force

A transfer either did or did not follow the mechanics the applicable policy sets. That is a documentary comparison, and it is squarely expert work — provided the right version of the policy is used.

Under the ICANN Transfer Policy, a change of registrant carries a sixty-day inter-registrar transfer lock, subject to a registrant opt-out exercised before the change is initiated. A transfer completing inside a window where a lock should have applied is a documented anomaly the report can state as an anomaly — without characterizing it, and without asserting what it means.

Identify the version. The Transfer Policy has been updated since its 2016 text, with a staged implementation schedule for contracted parties, so the version in force on the relevant dates is not necessarily the version published today. Citing the current text for events that predate it is a small error that produces a large problem in cross-examination. The report names the version and the dates it applied.

Separately, the transfer dispute procedure is a registrar-to-registrar mechanism about policy compliance. It is not a vehicle for adjudicating ownership between private parties, and treating it as one misstates what a favorable outcome there would even mean.

The Form of Authorization, and what it does not evidence

The Form of Authorization is the record a registrar keeps showing that a transfer was authorized, and it is the document that ties a transfer to an authorizing party. Under the Transfer Policy a registrar is required to retain it and, on a losing registrar's request, to produce a written or electronic copy within five calendar days.

Two things follow, and the second is the one that matters.

First, there is a defined channel by which the document moves, and a defined window. Where the requester is not the losing registrar, it reaches the file by legal process instead.

Second, and this is where reports overreach: the Form of Authorization may be a checkbox record. It evidences that an authorization flow completed. It does not evidence that the human who owned the account performed it. An authorization completed by whoever controlled the mailbox or the account at that moment looks identical, in that record, to one completed by the rightful holder. Establishing which is which requires the account file underneath — creation date, contact history, payment instrument, and, where retained, authentication logs, addresses and session records.

Reaching the records that are not public

Roughly half the useful record in a theft matter is publicly retrievable and roughly half is not, and the division is worth knowing before a preservation letter goes out.

Publicly retrievable, subject to redaction: current and historical registration data, passive DNS, certificate transparency entries, archived pages, zone and routing data. Available on day one, and the material an expert can start on immediately.

Requires legal process or a policy channel: registrar account records, authentication and address logs, payment instruments, the Form of Authorization where the requester is not the losing registrar, hosting account records, marketplace and escrow records, and email provider records. In the United States, provider-held records and content are governed by 18 U.S.C. 2703, and registrars publish their own subpoena procedures describing what they will accept and produce.

One route is easy to overlook: an administrative complaint under the domain dispute policy triggers registrar verification disclosure to the provider, which is a distinct path to underlying registrant data. Whether that route fits a matter where both parties assert title is a question for counsel — the dispute policy addresses abusive registration by a third party, which is a different question from a contested claim of ownership.

Preserve before remediating, because the clocks are short

The instinct in a theft matter is to fix it. The evidentiary problem is that regaining control, repointing name servers or re-registering can overwrite the very state that documents the incident — and the overwriting is not reversible.

Preservation comes first, broadly, on the claimant's side and against every third party identified. The clocks it is racing:

Authentication and hosting logs — the records that would show how an account was accessed — are typically retained for the shortest period of all, and the retention is provider-dependent with no standard default to rely on.
Twelve months — the outer window for filing a transfer policy dispute after an alleged violation.
Registrar registration-record obligations run to a defined outer bound after a registration is deleted or transferred away, and a further minimum retention applies to transfer-dispute-relevant data after sponsorship ends.
Marketplace listings and parking pages change without notice and leave no archive behind them.

Every retrieved record is captured with its retrieval method, timestamp and hash rather than as a screenshot, and handled under published digital-evidence practice. A screenshot of a registration lookup is an image of a claim. A captured raw response with a recorded query time, responding server and hash is a record.

What the record cannot establish

It cannot say who did it. The records show what happened, when, and from what address. Attribution to an individual requires records the registrar may never have held, and an expert who names a person from a log has stepped past the evidence.

Redaction. Public registration data omits most registrant fields, so the public record frequently cannot say who held the name before or after the disputed change.
Historical registration archives are third-party reconstructions with sampling gaps; a missing snapshot is not evidence that no change occurred in that interval.
Retention windows close. Registrar registration records have a defined outer bound, and the authentication logs that would show how an account was accessed are usually kept for far less.
The Form of Authorization may be a checkbox record, evidencing that a flow completed rather than who completed it.
An address in a log is not a person.
Passive DNS and certificate logs are coverage-dependent, and archives crawl on their own schedule, so the state of a site on a critical date may simply never have been captured.
Country-code extensions sit outside ICANN consensus policy — no transfer policy, no dispute procedure, no retention obligation, and often no public registration data at all.

What counsel gets, and what a retaining attorney should expect

Three documents, and the third is often the most immediately useful.

The control timeline and its exhibit set — historical registration responses with retrieval timestamps and hashes, passive DNS records, status code history, transfer records and the Form of Authorization where obtained, registry transaction records, certificate log entries, archived captures, hosting and address records, and any marketplace or escrow records where the name moved on.

A chain-of-custody log, recording what was collected, by what method, at what time, with what hash, and everything done to it since.

A data-needs analysis naming each record still outstanding and the party that holds it, so that process can be directed at the right entity rather than at the most obvious one. In my experience this is what changes the shape of a matter fastest, because it converts a general sense that evidence exists somewhere into a list with addresses on it.

US-specific: authentication under FRE 901, self-authentication routes at 902(13) and 902(14), business records under 803(6), the timeline itself a candidate for summary presentation under FRE 1006, and the opinions governed by FRE 702 as amended effective 1 December 2023. Bill Hartzer has testified in domain-related legal cases and has provided expert witness reports in others, and has worked in this field since 1996; the current engagement record is maintained at hartzer.com. Which forum fits a matter, and what to file, are questions for counsel.

Frequently Asked Questions

What does a domain expert do once a theft becomes a legal matter?

Reconstructs and authenticates the record of how control moved. That means a control timeline with one row per observed state change, each dated from an independent source: the pre-incident baseline of registrant, registrar, name servers and status codes; the change events themselves; the status codes across the window; independent corroboration of who was operating the name; and the onward chain if the name moved again. Alongside it come a chain-of-custody log and a data-needs analysis identifying which records are still outstanding and who holds them.

Can an expert identify who took the domain?

The records show what happened and when, and often from what address. Identifying a person is a different question, and it usually requires records the registrar may never have held — authentication logs, session records, payment instruments — which are retained for short periods where they exist at all. An address in a log is not a person. A defensible report states plainly the difference between what the records show happened and what they do not show about who caused it, and identifies the outstanding records that would narrow the question.

What is the Form of Authorization and how much does it prove?

It is the record a registrar keeps showing that a transfer was authorized, and under the transfer policy the registrar must retain it and produce a copy to a losing registrar on request within five calendar days. It proves less than it appears to. It may be a checkbox record evidencing that an authorization flow completed, not that the account's rightful holder completed it. Establishing which requires the account file underneath — creation date, contact history, payment instrument and, where retained, authentication and session logs.

Should the domain be recovered first or preserved first?

Preservation should come first wherever it can, because regaining control, repointing name servers or re-registering can overwrite the state that documents the incident, and that overwriting is not reversible. In practice recovery and preservation often run together under time pressure, which is why the preservation demand goes out early and broadly — to the claimant's own providers and to every third party identified. What is captured before remediation is usually the only version of that state anyone will ever have.

How long do the relevant records survive?

Unevenly, and the most useful ones go first. Authentication and hosting logs, which would show how an account was accessed, are typically retained for the shortest periods, and retention is provider-dependent with no standard default. Registrar registration records have a defined outer bound after a registration is deleted or transferred away, with a further minimum retention for transfer-dispute-relevant data after sponsorship ends. A transfer policy dispute has a twelve-month filing window. Marketplace listings and parking pages simply vanish without notice.

Does it matter which version of the transfer policy applied?

Yes, and it is a common oversight. The transfer policy has been updated since its 2016 text, with a staged implementation schedule for contracted parties, so the version in force on the dates in dispute may not be the version published today. Testing a transfer against the wrong version produces a comparison that looks rigorous and is wrong. The report should name the version, the dates it applied, and the specific requirement being tested — and should state anomalies as anomalies rather than characterizing them.

Is a transfer dispute procedure the right way to resolve ownership?

That is a question for counsel, but one structural point is worth knowing. The transfer dispute procedure is a registrar-to-registrar mechanism concerned with whether a transfer complied with policy. It is not designed to adjudicate ownership between private parties who both assert title, and treating it as though it were misstates what an outcome there would mean. Likewise, the domain dispute policy addresses abusive registration by a third party, which is a different question from a contested claim of title between two parties.