WHOIS and RDAP History Analysis

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

What a historical registration record actually proves

A historical registration record is a dated observation of what a registration database said about a domain name at one moment. That is the whole of it, and it is frequently enough to decide a question. Stacked in order, those observations show when a name was created, when the sponsoring registrar changed, when the nameservers moved, when the record was updated in the days around a disputed transfer, and when a status flag went on or came off.

What such a record does not do is identify a person. Since 2018 the public copy usually does not even attempt to. The registration data anyone can retrieve today is a derived copy; the authoritative record sits with the sponsoring registrar, and in a thick registry (one that stores full contact data rather than only a pointer back to the registrar) a mirror sits at the registry as well. In my experience the most common error in a domain matter is treating the public lookup as the record instead of as a copy of it.

RDAP — the Registration Data Access Protocol, the structured replacement for WHOIS, which returns machine-readable JSON instead of free text — became the definitive source for generic top-level domain registration data on January 28, 2025, when ICANN sunsetted WHOIS for gTLDs (ICANN announcement). RDAP had been available through accredited registrars and registries since 2019.

Which copy of the record you are holding

Four repositories matter, and they answer different questions.

The sponsoring registrar holds the authoritative registration data, together with the account, billing, payment and login records behind it. This is where identity lives.
The registry holds the transaction history — the record of create, update, transfer and delete operations performed on the name. EPP status codes are the machine flags carried on a domain, such as clientTransferProhibited, that show which operations were permitted at a given time.
Data escrow. Registrars deposit registration data off-site under contract with ICANN: full deposits weekly, with daily differential deposits for registrars above 100,000 registration-years in a quarter, and ICANN may obtain a release within twenty-four hours of signed written notice. Escrow is an ICANN compliance mechanism, not a discovery route available to a party.
Third-party history archives — commercial databases of prior lookups. These are evidence of what a vendor observed and when. They are not the registrar's record, and should never be described as though they were.

Ask which of these an exhibit came from before asking what it shows.

A registration history has to be assembled

There is no ICANN-operated public archive of historical registration data. A history is built, not queried. The materials are prior lookups preserved with their retrieval timestamps, commercial historical WHOIS and RDAP databases, archived registrar pages, and — where legal process is available — the registrar's own transaction records.

That construction is why the discipline of the capture matters more than the choice of tool. For every observation I preserve the raw response (RDAP JSON, or port-43 WHOIS text for older records), the exact query issued, the server that answered, and a UTC retrieval timestamp; then I hash the file and record the hash. A screenshot of a lookup website is none of that. It is a rendering by a third party, stripped of the detail that would let anyone verify it later.

The chronology that results should read as a series of observations, each tied to its source and time, with the intervals between them stated plainly. Where a registrant appears to change between two observations eight months apart, the defensible statement is that the change occurred somewhere inside that window — not on either endpoint.

Three dates that reshaped the record

Registration data is not a stable schema across time. Comparing records from different eras without normalizing them manufactures changes that never happened.

May 25, 2018 — ICANN's Temporary Specification for gTLD Registration Data took effect alongside GDPR, requiring redaction of most registrant contact fields absent consent, and an anonymized email address or web form.
January 28, 2025 — RDAP became the definitive source for gTLD registration data; WHOIS was sunsetted.
August 21, 2025 — the Registration Data Policy took effect and all gTLD registries and registrars were required to implement version 2.2 of the RDAP profile (ICANN Registration Data Policy).

Under current policy, redaction is signaled rather than silent. Where a value is withheld, the response must indicate that it is redacted, using a structured extension identifying which members were removed rather than the older free-text convention. Registrant organization, country and state or province are published, with organization requiring the registrant's consent. Redacted is not the same as absent. A record stating that a value was withheld is affirmative evidence that a value existed.

What registration records cannot establish

The public registration record is not a register of ownership, and after May 2018 it is often not identifying at all. Redaction is applied to the record as it is published now, which means a lookup run today can return REDACTED for periods both before and after the events in dispute — the withholding happens at output, it is not frozen at the date the underlying record was created. A measurement published by Interisle Consulting Group in January 2021 reported that in 2020 only 13.5 percent of domains had an actual registrant identified in WHOIS, with 57.3 percent redacted and 29.2 percent behind a privacy or proxy service, against 75.7 percent identifiable in early 2018. That is one study's figure and should be attributed as such; the direction of travel is not in dispute.

The history archives carry their own gaps. A commercial database holds what it polled, when it polled it. Absence of a record for a period is evidence of a collection gap, not evidence that nothing was registered. Country-code registries sit outside ICANN gTLD policy entirely and set their own publication and disclosure rules. And the "updated date" field records a database update, which can be triggered by events having nothing to do with a change of registrant. None of this makes the record useless. It makes an unqualified assertion about it indefensible under cross-examination.

Reaching the record behind the redaction

Two routes exist and neither is automatic.

ICANN's Registration Data Request Service (RDRS), launched November 28, 2023, standardizes the format of requests for nonpublic gTLD registration data. It is a request router, not an access right. All communication and disclosure take place outside the system, ICANN has no role in the disclosure decision, and the service does not guarantee access. Across its two-year pilot ICANN reported that 26 percent of requests were approved, 55 percent denied and the remaining 19 percent partially approved, with registrar participation shifting over time and never covering the whole market. Worth knowing about. Not a plan.

The other route is legal process to the registrar, and its timing is what gets underestimated. Registrars must retain the data elements necessary for the Transfer Dispute Resolution Policy for no less than fifteen months after their sponsorship of a registration ends. Fifteen months is a floor on how long the underlying record is contractually guaranteed to exist — not a promise about anything longer. A preservation request identifying the domain, the date range and the categories of record is the thing that reliably stops that clock. Whether and when to send one is counsel's decision; the expert's job is to specify what should be preserved and why.

Authenticating a registration record (US federal rules)

This section describes United States federal practice only. State courts and other jurisdictions apply different rules, and what any of it means in a particular matter is for counsel.

Federal Rule of Evidence 901(a) requires the proponent to produce evidence sufficient to support a finding that the item is what the proponent claims it is (FRE 901). Three of the rule's illustrations do most of the work here: 901(b)(1), testimony of a witness with knowledge — the analyst who performed and recorded the retrieval; 901(b)(4), distinctive characteristics taken together with all the circumstances; and 901(b)(9), evidence describing a process or system and showing that it produces an accurate result, which is where a description of the RDAP query-and-response path belongs.

Rules 902(13) and 902(14) provide for self-authentication of records generated by an electronic process or system, and of data copied from a file and authenticated by a process of digital identification — hashing, in ordinary practice. Each depends on a qualified person's certification and on the advance written notice that Rule 902(11) requires. Registrar-produced records are ordinarily addressed under the business-records conditions of Rule 803(6).

What this looks like in an expert report

A registration-history section is a table before it is an argument. Each row is one observation: date and time in UTC, source, exact query, responding server, the fields observed, and the hash of the preserved raw file. The narrative that follows says what changed between rows and, explicitly, what the intervals do not show.

Where a value is available from one source and redacted in another, both go in, with the difference explained rather than smoothed away. Where the analysis leans on a third-party archive, the report names that dependence and its limitation. I have provided expert witness reports in domain-related cases and have testified in such cases; the sections that hold up are the ones that stated their gaps before anyone asked.

The current record of engagements and credentials is maintained at hartzer.com. This site describes the practice; it does not attempt to keep an engagement list current.

Frequently Asked Questions

Can WHOIS or RDAP history be authenticated for court?

It can be presented for authentication, and how it is captured decides how straightforward that is. In US federal practice the proponent must produce evidence sufficient to support a finding that the item is what it is claimed to be. An analyst who preserved the raw RDAP JSON or WHOIS text, the exact query, the responding server, a UTC timestamp and a hash can testify as a witness with knowledge and can describe the retrieval process. Records produced by the registrar itself are ordinarily handled as business records. Whether to proceed by certification or by custodian testimony is counsel's call.

What if the registration was privacy-protected?

A privacy or proxy service interposes its own details in the public record; the underlying customer information is held by the provider. That means the public record identifies the service, not the registrant, and the identity question moves to the provider and the registrar through legal process. Proxy contact data is also within the scope of registrar data escrow, but escrow is an ICANN compliance mechanism releasable to ICANN — not a route a party can use. Privacy protection is not concealment in itself; it is a service, and the record showing it was used is still evidence of a choice made on a date.

Does redaction mean the registrant information is gone?

No. Redaction means the value is withheld from publication and the record says so. Under current policy the response must indicate that a value has been redacted rather than silently omitting it, which makes redaction affirmative evidence that a value exists. The data remains with the registrar, subject to that registrar's retention practices and to the fifteen-month floor that runs after its sponsorship of the registration ends. Treating a redacted record as proof that no registrant exists is one of the clearest errors an expert can make in this area.

How far back does registration history go?

It depends entirely on who was collecting and when. There is no official archive of historical registration data, so depth is a property of the commercial vendor being queried, of any prior captures the parties happen to hold, and of the registrar's own records. Different vendors polled different domains at different intervals, so two sources can produce different histories for the same name without either being wrong. The correct way to report this is to state each observation with its source and date and to leave the gaps visible rather than interpolating across them.

Do I need a subpoena to get the registrant's identity?

For most generic top-level domains the unredacted registrant data is not publicly retrievable, so some form of compelled or voluntary disclosure is normally required, and only counsel can decide what is appropriate in a given matter. ICANN's Registration Data Request Service standardizes the format of a request but routes it to the registrar, which decides; across its pilot roughly a quarter of requests were approved. It guarantees nothing and does not cover every registrar. Country-code registries are outside that system entirely and set their own rules.

Does any of this apply to country-code domains?

Only partly. ICANN's consensus policies on registration data, the RDAP profile and the Registration Data Request Service apply to generic top-level domains. Country-code registries set their own publication, retention and disclosure practices, which vary widely — some publish more than gTLD registries now do, others publish almost nothing, and some operate their own dispute and disclosure procedures. An analysis of a country-code registration has to begin with that registry's own published rules rather than with an assumption carried over from gTLD practice.