A current WHOIS lookup shows the registration data available at query time. If the registrar, nameservers, status codes, or dates change later, the protocol does not supply an earlier version. RFC 3912 defines WHOIS as a text query and response protocol. It does not define a historical log. A history service has to make and retain its own observations.
The familiar term "WHOIS history" now covers more than legacy port 43 WHOIS data. ICANN made RDAP the definitive source for gTLD registration information on 28 January 2025. RDAP uses HTTP and structured responses, and RFC 9224 defines how clients find an authoritative RDAP service. ICANN says gTLD registries and registrars are no longer required to provide WHOIS except for .com, .name, and .post. Traditional WHOIS also remains relevant in some country code and other registration systems, so a current history product may normalize observations from either protocol.
How DomScan history is collected
DomScan does not claim to crawl every registered domain on a schedule. It records registration data after a fresh, successful RDAP-backed request to GET /v1/whois or GET /v2/whois. For a given domain, DomScan stores no more than one snapshot per UTC day. Another qualifying lookup on a later day can add a snapshot. Cached responses, bulk WHOIS requests, history reads, and traditional WHOIS only fallbacks do not create snapshots.
Each snapshot stores selected normalized fields rather than a complete raw registry response. It does not store registrant identity, organization, email, phone, address, or raw contact records. The stored fields include the registrar and IANA registrar ID, creation and expiry dates, the last updated date, domain status codes, nameservers, DNSSEC state, transfer lock state, and whether the response appeared privacy protected. DomScan automatically compares only the registrar name, expiry value, nameservers, status codes, DNSSEC, transfer lock, and privacy state. The API stores `created_date`, but it does not automatically flag creation date changes, and the public history tool does not display that field.
Other history providers may use scheduled crawls, licensed datasets, customer queries, or a mixture of collection methods. Their coverage can differ by provider, TLD, time period, and field. A claim that one provider has data back to a certain year does not mean every domain or every TLD has continuous coverage from that year. Ask what was collected, how often it was observed, and whether the response came from WHOIS, RDAP, or another source.
What first seen and last seen mean
The `first_seen` value in a DomScan history response is the date of the oldest snapshot in that returned result window. It is not the domain's registry creation date. It does not say when the domain first appeared on the internet, when a person acquired it, or when DomScan first knew that it existed outside the returned window. The endpoint returns 50 snapshots by default and accepts a limit up to 100, so a limited response may omit older stored observations.
The `last_seen` value is the newest snapshot date in the response. `total_snapshots` is the number of snapshots returned, subject to the requested limit. Read all three fields together. For example, a response with 50 snapshots and a `first_seen` date one year ago may simply have reached the 50 record limit. It does not establish that coverage began one year ago.
How to interpret common changes
A historical difference is an observation, not a verdict. Several legitimate administrative actions can produce the same change, and privacy rules often remove the registrant data that would distinguish them. Treat each field as one part of the evidence.
- Registrar difference: A changed registrar name may reflect a transfer, correction, normalization, or source variation. The observed difference does not prove that a transfer occurred or identify the owner.
- Nameserver change: New authoritative nameservers can indicate a DNS provider or hosting migration. It can also follow a compromise, but the nameserver change alone does not establish malicious access.
- Expiry date change: A later expiry date usually reflects a renewal or transfer extension. A shorter or irregular value can reflect registry rules, correction, or parsing differences, so compare the underlying dates before drawing a conclusion.
- Creation date difference: API snapshots store this date, but DomScan does not automatically compare it or show it in the public tool. A later date may fit deletion and re-registration, but registry migrations, corrections, and source differences can also alter it.
- Status change: EPP status codes can show transfer locks, holds, redemption, or pending deletion. Interpret them using the registry lifecycle and the exact timestamp of the observation.
- Privacy state change: A change in redaction or proxy presentation may follow a registrar transfer, a registrant choice, or an upstream publication policy. It is not direct evidence of a new registrant.
Correlated changes are more informative than isolated ones. A registrar transfer, nameserver replacement, privacy change, and multi-year expiry extension observed together can support a hypothesis that operational control changed. The same bundle can also occur during a planned migration by the existing registrant. Confirm ownership with transaction records, registrar records, authorized account evidence, legal disclosure, or another source that directly addresses the registrant.
A snapshot comparison in practice
Consider two observations of a fictional domain. The later snapshot has a different registrar and nameserver set, and the expiry date moved forward by several years.
{
"older": {
"snapshot_date": "2024-11-03",
"registrar": "Example Registrar A",
"nameservers": ["ns1.provider-a.test", "ns2.provider-a.test"],
"expiry_date": "2025-09-15",
"privacy_protected": true
},
"newer": {
"snapshot_date": "2025-02-18",
"registrar": "Example Registrar B",
"nameservers": ["ns1.provider-b.test", "ns2.provider-b.test"],
"expiry_date": "2030-09-15",
"privacy_protected": false
}
}This comparison supports a transfer or migration hypothesis. It does not prove a sale, identify the registrant, or tell us when each change occurred between 3 November and 18 February. The fields may have changed on different days. If the domain matters to an investigation, check DNS history, certificate issuance, web archives, passive DNS, and any authorized registrar or account records for the same interval. DomScan DNS history is also built from observations, and correlation between the two histories is manual.
Investigation uses and their limits
Brand protection
For a lookalike domain, registration history can establish that DomScan observed a certain registrar, nameserver set, or status on a given date. That helps investigators compare infrastructure across related domains and place changes near a product launch or phishing campaign. It does not establish bad faith by itself. A UDRP or court proceeding depends on the applicable legal test and evidence about rights, use, and intent, not simply a close registration date.
Domain purchasing and due diligence
A buyer can use snapshots to test a seller's claims about continuity. Long gaps, a creation date discontinuity, or repeated registrar and nameserver changes justify more questions. Stable observations are useful too, but they do not prove uninterrupted ownership between collection dates. Pair registration history with contracts, registrar account records, trademark checks, historical content, backlink review, reputation data, and DNS history before assigning value or accepting a chain of title.
Incident response
During an incident, a snapshot can narrow the interval in which infrastructure changed. If one observation shows the expected nameservers and the next shows an unfamiliar provider, the change happened somewhere between those dates. The snapshot dates are observation times, not necessarily event times. Authentication logs, registrar notifications, DNS logs, certificate transparency records, and threat telemetry can narrow the interval and help distinguish a planned change from account compromise.
Privacy and historical registration data
Public registration data changed substantially around the enforcement of the EU General Data Protection Regulation in May 2018. ICANN adopted a temporary specification for gTLD registration data, followed by an interim policy. The current ICANN Registration Data Policy took effect on 21 August 2025. It defines publication and disclosure requirements for ICANN accredited registrars and gTLD registry operators.
Some older third-party archives contain contact fields that are not present in current public responses. Coverage and retention vary, and an old snapshot is not guaranteed to identify the true registrant. It might contain outdated data, a privacy service, a reseller contact, or inaccurate information. Personal data in an archive also carries legal and ethical handling obligations. Use only the data needed for a legitimate purpose, follow the provider's terms, and use an authorized disclosure process when nonpublic gTLD data is required.
A practical history workflow
- Run a live WHOIS lookup and record the source, query time, registrar, nameservers, dates, and status codes.
- Request WHOIS history with a limit appropriate to the investigation. Treat `first_seen`, `last_seen`, and `total_snapshots` as properties of the returned window.
- Compare adjacent observations and note exactly which fields changed. Do not assign a single event time when there is a gap between snapshots.
- Cross-check the interval with DNS history, certificate transparency, web archives, passive DNS, and internal logs that are available to you.
- Write conclusions with confidence levels. Separate facts such as "the nameservers differed" from hypotheses such as "operational control may have changed."
- Use Domain Monitor separately for scheduled availability, status, and expiry checks. Monitor checks do not add WHOIS history snapshots or track every registration and DNS field.
Registration history is most reliable when the report names the source, observation dates, missing intervals, and alternative explanations. For DomScan data, include the requested limit and avoid treating `first_seen` as domain age. Those details let another investigator reproduce the query and understand how far the evidence reaches.