Domain name evidence, forensics and litigation support
Abstract hexagonal tile illustration representing Evidence Preservation for Domain Disputes

EvidenceProcedural

Evidence Preservation for Domain Disputes

Produces
A sealed, hashed preservation set with a capture manifest
Sources
Public lookups, live captures, third-party archives
How it is obtained
Self-collected immediately; custodian records need a channel
Authority
NIST SP 800-86; SWGDE 21-F-001 and 18-F-002; UDRP Rules ¶ 1

Almost every domain record is either changeable in seconds or running down a retention clock

Rank the record by volatility, then work in that order

Preservation is not tied to one layer of the domain name system. It is tied to a single uncomfortable fact: almost every domain record is either changeable in seconds by whoever controls it, or sitting on a retention clock that is already running.

The order of volatility in a domain matter is consistent. DNS answers and live page content come first — a name server record or a homepage can change in minutes, at the discretion of the party whose conduct is in dispute, with no notice and no residue. Registration data is next, changeable through a contact update or a transfer. Provider logs follow, governed by retention windows rather than by anyone's decision. Registry records are the most stable, and even those are observations rather than an archive.

NIST's forensic guidance frames the work in four phases — collection, examination, analysis and reporting — with collection defined as identifying, labeling, recording and acquiring data from the possible sources while following procedures that preserve its integrity (NIST SP 800-86). The sequencing point is the one that matters here. Examination and analysis can be done next month. Collection cannot. In a live matter, the first job is very often to capture everything publicly available before anything moves, and to work out what it means afterwards.

What a UDRP lock actually freezes, and what it does not

There is a widespread assumption that filing a dispute freezes the evidence. It does not, and the gap between what people assume and what the rules provide is the most expensive misunderstanding in this area.

Under the UDRP Rules, a "Lock" is defined as a set of measures a registrar applies to a domain name which prevents, at a minimum, any modification to the registrant and registrar information by the respondent — but which does not affect the resolution of the domain name or its renewal. The registrar must supply the full registration data and confirm the lock within two business days of the provider's verification request, and the lock is released within one business day of a dismissal or withdrawal.

Read that definition against what a typical matter turns on. The lock protects the registrant and registrar fields. It does not protect the website, the DNS records, the redirect, the mail configuration, or anything else about how the domain behaves. Site content can be replaced the day after the lock applies, and a redirect can be switched off within the hour. Anything evidentiary about the domain's operation has to be captured independently, before or immediately after filing, by whoever is preserving it.

Capture the raw response, not the rendering

What gets preserved is the data as the server returned it. That means RDAP JSON and legacy WHOIS text exactly as received; DNS query output including which resolver answered; and HTTP response headers and body in native form. It does not mean a screenshot of a lookup website's presentation of those things, which is a rendering by a third party of a query somebody else ran.

The collection guidance published by SWGDE is specific about what accompanies the capture. Preserve content in its native form, file formats and language. Record the URL to include the protocol, domain, subdomains, subpages, path and session information. Record the dates, timestamps and local time zone of access. Where a sequence is involved, give preference to video capture of the screen, with stills used alongside.

The reason is not fussiness. A rendering cannot be re-parsed, cannot be checked against the protocol, and carries a third party's transformations invisibly. A raw response can be re-read years later by someone who was not there, which is the entire purpose. In my experience the single most common defect in evidence handed to an expert is a document full of pasted screenshots with no raw response, no time zone and no hash behind any of them.

Hash at the moment of capture, and log as you go

A hash, or message digest, is a short fixed-length fingerprint of a file; any change to the file changes the fingerprint. It is computed at the moment of capture, not at report time, and SWGDE calls for NIST-approved secure hash algorithms to validate both complete datasets and individual acquired files, and recommends hashing under more than one algorithm to avoid hash collisions.

Verification, as NIST describes it, is computing the digest of the original and of the copied data and comparing them. That is the mechanism behind the working-copy discipline: make a copy, examine and analyze only the copy, and verify the integrity of both. In practice that is a sealed capture set that is never edited, renamed, converted or re-saved, and a separate working copy where the analysis happens.

Around it goes a contemporaneous collection log recording, per SWGDE, the software employed, logs, reports, screenshots of the interface, downloaded data size, number of files, file names and hash values. Two entries that people skip and should not: the items that were sought and could not be obtained, with the reason, and any capture that failed to reproduce. Both are findings, and both are much harder to explain if they surface for the first time under questioning.

Third-party archives are corroboration, not a substitute

Requesting archival capture of the relevant URLs creates an independent record alongside the examiner's own, held by an organization with no interest in the dispute. That independence is the evidentiary value, and it is worth having.

Two properties limit it. The first is timing: the Internet Archive states there is a three to ten hour lag between the time a site is crawled and when it appears in the Wayback Machine, so a same-day on-demand capture is not immediately visible and cannot be verified on the spot. The second is that a request creates a record of the request — live collection of data can alter and create evidence, and should be documented as such. Asking an archive to capture a page is an act by the examiner and it belongs in the log.

The deeper limitation is coverage. Pages can be absent because crawlers were unaware they existed, because robots.txt blocked collection, or because the site owner requested exclusion, and the Archive states it makes no guarantees beforehand about the outcome of an exclusion request. Archived material can also become unavailable later. A third-party archive corroborates a capture that the examiner already holds. It does not replace one.

What preservation cannot achieve

It cannot compel a private party or a provider to hold anything. Nothing in ICANN policy obliges a registrar to preserve records because a private party asked; the retention floors run on their own schedule regardless of who has written to whom. A preservation letter is a request, and at a provider that never agreed to hold anything it does not stop a clock.

US-SPECIFIC. The statutory preservation mechanism most often cited, requiring a provider to preserve records for 90 days with a further 90 on renewal, operates upon the request of a governmental entity. It is not a civil-party tool, and treating it as one wastes the only period in which the records still exist.

It cannot rely on the floors being firm. Retention obligations have been waived for registrars in some jurisdictions, with at least one determination reducing a two-year post-registration period to one year, so the published floors are a starting point rather than a guarantee.

It cannot guarantee reproduction. Responses vary with visitor credentials, browser, location, date and time, so a later attempt at the same capture can legitimately differ, and that has to be disclosed rather than smoothed over.

And it cannot reach providers outside the forum, whose records may be beyond any preservation demand a party could make. Which demands are available at all is a question for counsel.

The custodian clocks that set the real deadline

The binding constraint on a domain matter is almost never the procedural schedule. It is the shortest retention window at the custodian holding the most useful record, and that window began running before anyone was retained.

The floors worth writing down at the start of an engagement: 180 days for registrar log files, billing records and communication source and destination data; two years after a registration's deletion or transfer away for registration records; fifteen months after the end of sponsorship for transfer-dispute data elements; and twelve months from an alleged Transfer Policy violation for a transfer dispute filing. Hosting providers set their own log retention independently, and it is frequently measured in weeks rather than months.

So the enumeration is done in writing, early: which custodians hold what, what each one's published retention period is, and which expires first. The shortest one governs the sequence of work. Everything publicly available is captured immediately, without waiting for that enumeration to be complete, because public capture costs a day and cannot be done retrospectively. The identification of custodians and the routes that might reach them proceeds in parallel, and which routes are available is for counsel.

What the preservation set looks like when it is delivered

The deliverable is a set, not a document. It contains a manifest listing every captured item with its source URL or endpoint, the capture timestamp with time zone, the tool and version used, the file size, and hash values under more than one algorithm. It contains the raw captures themselves: RDAP JSON, WHOIS text, DNS query output, HTTP transcripts, HTML source, screen recordings, packet captures where taken, and certificate data. It contains the contemporaneous collection log. And it contains a written record of every item sought but not obtained, with the reason.

US-SPECIFIC. Self-collected captures are generally authenticated through the collector's description of his process, supported by that log and hash record. Where an automated system produced the capture, the certification routes for records generated by an electronic process, and for data copied from a device, storage medium or file authenticated by a process of digital identification, are the ones ordinarily engaged (FRE 902). Whether and how any of that applies in a given matter is for counsel.

Re-capture on a schedule so the set documents a range rather than a moment. Then seal it, work only from copies, and record the failures as carefully as the successes.

Frequently Asked Questions

Does filing a UDRP freeze the website?

No. Under the UDRP Rules a lock is defined as measures preventing, at a minimum, modification to the registrant and registrar information by the respondent, and it expressly does not affect resolution of the domain name or its renewal. Site content, DNS records, redirects and mail configuration all remain changeable. The registrar must supply full registration data and confirm the lock within two business days of the provider's verification request. Anything evidentiary about how the domain operates has to be captured separately, and the sooner the better.

How quickly does domain evidence need to be preserved?

The most volatile items — DNS answers and live page content — can change in minutes at the discretion of whoever controls them, without notice and without leaving any trace on the domain itself. Registration data can change through a contact update or transfer. Provider logs sit under retention windows already running, the shortest common floor being 180 days for registrar log and communication records, with hosting providers frequently keeping less. In a live matter the practical answer is to capture everything publicly available on day one and analyze it afterwards.

Is a screenshot enough to preserve a web page?

On its own, no. A screenshot is a rendering, cannot be re-parsed, and carries no verifiable link to what the server actually returned. Proper preservation keeps the raw response — the HTTP headers and body, the RDAP JSON or WHOIS text, the DNS output including the resolver used — in native form, with the full URL, the timestamp and local time zone, and a hash computed at capture. Screen recordings and stills belong in the set as supporting material, particularly for sequences like redirects, but not as the only record.

Will a preservation letter stop records from being deleted?

It is a request, and its effect depends entirely on the recipient. Nothing in ICANN policy obliges a registrar to preserve records because a private party asked, and the contractual retention floors run on their own schedule regardless. The statutory preservation mechanism that obliges a provider to hold records for 90 days, extendable by a further 90, operates on the request of a governmental entity and is not a civil-party tool. That is US-specific. Meanwhile, everything publicly available can be captured immediately, and generally should be.

Why hash a capture at the moment of collection?

Because a hash establishes integrity only from the moment it is computed. Hashing at report time, after files have been renamed, re-saved, converted or emailed, records the state of whatever the file has become rather than what was captured. Hashing at collection, under more than one algorithm to guard against collisions, lets anyone later recompute the digest and confirm the file has not changed since. It also underpins the working-copy discipline: seal the original set, analyze only a copy, and verify both against the recorded digests.

What happens if a capture cannot be reproduced later?

It is recorded as a finding rather than quietly dropped. Web responses depend on visitor credentials, browser, location, date and time, so a second attempt from a different network or device can legitimately differ, and conditional redirects and geo-targeted content make this common. The collection log records what was attempted, from where, with which tool, and what happened. Disclosing a non-reproduction alongside the original capture is far stronger than presenting the capture alone and having the variation surface from the other direction.
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