People still search for a WHOIS domain search when they want to know who is behind a website. That wording creates the first problem. A domain registrant, a website operator, a registrar, a DNS provider and a hosting company are different parties. Public registration data may name one of them and say nothing about the others. A correct result is often useful, but it is rarely a clean answer to the question of who owns a website.
The protocol has changed too. For generic top-level domains such as .com, .org and the newer gTLDs, a current search should start with RDAP rather than assume the old WHOIS service is authoritative. This guide uses the familiar term WHOIS search because people still use it, but it treats RDAP as the primary registration data source and keeps attribution claims separate from observed facts.
WHOIS search now means RDAP first for gTLDs
ICANN announced that, as of 28 January 2025, the Registration Data Access Protocol became the definitive source for generic top-level domain registration information. ICANN-accredited registrars and gTLD registries had offered RDAP since 2019, but the 2025 cutover ended the period in which users could treat plaintext WHOIS as the default source. ICANN's current guidance says gTLD registries and registrars are no longer required to provide WHOIS, with contractual exceptions for .com, .name and .post.
RDAP fixes several practical weaknesses in RFC 3912 WHOIS. Queries use HTTPS. Responses use defined JSON objects. Clients can discover the correct service from IANA bootstrap registries instead of maintaining a hand-built list of WHOIS hosts. RDAP also supports internationalized registration data and differentiated access, so a server can return a public response while reserving nonpublic fields for an authenticated, authorized process. RFC 9082 defines the query paths, RFC 9083 defines the response objects, and RFC 9224 defines authoritative service discovery.
Current authoritative examples, checked 10 July 2026
The IANA DNS RDAP bootstrap file published on 9 July 2026 mapped .com to `https://rdap.verisign.com/com/v1/`. Following that authoritative mapping and requesting the registry record for example.com returned the response below on 10 July 2026. The excerpt is deliberately short. It retains the fields needed to show what the registry actually asserted and leaves out notices and links.
{
"objectClassName": "domain",
"handle": "2336799_DOMAIN_COM-VRSN",
"ldhName": "EXAMPLE.COM",
"status": [
"client delete prohibited",
"client transfer prohibited",
"client update prohibited"
],
"events": [
{ "eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z" },
{ "eventAction": "expiration", "eventDate": "2026-08-13T04:00:00Z" },
{ "eventAction": "last changed", "eventDate": "2026-01-16T18:26:50Z" },
{ "eventAction": "last update of RDAP database", "eventDate": "2026-07-10T00:51:55Z" }
],
"nameservers": [
{ "ldhName": "ELLIOTT.NS.CLOUDFLARE.COM" },
{ "ldhName": "HERA.NS.CLOUDFLARE.COM" }
],
"secureDNS": { "delegationSigned": true },
"entities": [
{ "handle": "376", "roles": ["registrar"] }
]
}This response establishes a registry handle, registration events, three client status restrictions, the delegated nameservers, signed delegation and the registrar entity. It does not contain a registrant entity. That absence is part of the result, not an invitation to fill the gap with a guess. Example.com is also an IANA-reserved example domain, so its registrar labeling and operational setup should not be treated as typical of ordinary registrations.
The event named `last update of RDAP database` is the time the registry refreshed or generated its RDAP view. It is not evidence that the registrant changed the domain at that moment. The `last changed` event is closer to a registration object update, but it still does not explain which field changed or why. An expiry event is a registration date, not a prediction that the domain will become available on that date. Renewal, auto-renew grace periods and registry lifecycle states can all affect what happens next.
Country-code responses show why one example cannot define the whole namespace. On 10 July 2026, Nominet's authoritative RDAP response for nominet.uk included a registrant entity naming Nominet UK. On the same date, SIDN's response for sidn.nl used `REDACTED FOR PRIVACY` in administrative and technical entity fields and a redacted domain handle. Both responses were valid outputs from their respective registry services. Their publication choices were different.
What public registration data can establish
- The domain object queried and the registry handle assigned to it, when the service publishes a handle.
- The sponsoring registrar or registrar identifier reported by the registration service.
- Registration, expiration, last-changed and database-update events that the server chose to publish.
- Current registration status codes, including transfer, update or deletion restrictions.
- Delegated nameservers and DNSSEC delegation data included in the registration response.
- Published entities, redacted entities, contact forms, remarks, notices and links provided by that server.
Each field needs a narrow reading. A registrar manages the registration; it does not necessarily host the website or control its content. Nameservers identify the delegated DNS service, but a shared provider can serve millions of unrelated customers. A status such as `client transfer prohibited` means the registrar has applied a transfer restriction. It is not a trust score and does not prove that the domain is well managed.
Dates also need care. Creation usually refers to the creation of the current registry object, not the first time a phrase appeared on the web. An updated date can reflect routine registration maintenance. The registry expiry date and registrar registration expiration date are distinct policy fields and may not always match. Preserve the event name and source instead of flattening every date into one generic updated timestamp.
The current ICANN Registration Data Policy
For gTLD contracted parties, the current reference is ICANN's Registration Data Policy. It took effect on 21 August 2025 and replaced the interim policy. ICANN revised it on 12 May 2026 to add a response timeline for urgent lawful disclosure requests. The policy applies to ICANN-accredited registrars and gTLD registry operators with ICANN agreements. It does not turn every registration field into public data.
Section 9 sets publication and redaction requirements. Operational fields such as the domain name, registrar, registrar IANA ID, status, creation date and last RDDS update are among the required public elements. Nameservers, updated date and DNSSEC elements are published when collected, transferred or generated. Personal contact values can be redacted under the policy. A registrant organization value has its own consent rules: when the registered name holder agrees to publication, the registrar must publish it and the organization is treated as the registered name holder. Without that agreement, the organization value may be redacted.
Nonpublic data is not a second search endpoint waiting to be discovered. ICANN directs eligible requestors to the Registration Data Request Service for participating registrars or to the sponsoring registrar's disclosure process. A request needs a lawful basis and is evaluated under the applicable process. Submission does not guarantee disclosure. For urgent requests, the current policy defines a narrow category involving imminent threats to life, serious bodily injury, critical infrastructure or child exploitation, with authenticated requestor requirements.
Country-code domains require registry-specific checks
Country-code top-level domains are not covered by ICANN's gTLD registrar and registry contract framework in the same way. Each ccTLD operator decides which registration service to provide and what its public policy allows. Some publish RDAP through the IANA bootstrap registry. Some retain a web lookup or port 43 WHOIS service. Others expose a limited result or impose terms that restrict automation. A tool should report the source it reached and avoid manufacturing gTLD-shaped fields when the registry did not provide them.
The IANA bootstrap snapshot published 9 July 2026 contained RDAP base URLs for .uk, .au, .ai, .fr and .nl. It had no domain RDAP bootstrap entry for .de, .es, .jp, .us or .io. That statement is date-specific and describes the IANA bootstrap file, not the entire availability of registration lookup services for those namespaces. A missing bootstrap entry means the client must consult the registry's current documentation or use another supported lookup path.
Avoid fixed claims that a country code always publishes a registrant name or always hides it. Registry policy changes, legal obligations differ and individual records can contain consented organization data, privacy service data or redaction markers. The response in front of you, its authoritative source and the registry's current policy are stronger evidence than a generic list of transparent or private TLDs.
Do not confuse the registrant with the website operator
- The registered name holder is the party recorded for the domain registration. Public RDAP may or may not identify that party.
- The website operator controls or publishes the site. It may be the registrant, a customer, an agency, a tenant or another organization.
- The registrar sponsors and manages the registration. It does not become the website operator by appearing in RDAP.
- The registry operates the top-level domain database and authoritative registration service.
- DNS, CDN, certificate and hosting providers supply infrastructure. Shared infrastructure alone does not attribute two domains to the same party.
The distinction matters during fraud investigations and acquisition research. A legal notice on a website may identify the site operator but not the registered name holder. A privacy or proxy entity in RDAP may be the published registration contact but not the underlying customer. A corporate name in a certificate can describe the certificate subject, not the domain registrant. Record each relationship with its source instead of collapsing all of them into an owner field.
A practical domain registration workflow
- Normalize the exact domain. Preserve the full hostname separately, but query registration data for the registrable domain rather than an arbitrary subdomain.
- Discover the authoritative RDAP service through IANA bootstrap data or use a client that performs RFC 9224 discovery.
- Save the query time, request URL, HTTP status and source. Registration data changes, so an undated screenshot is weak evidence.
- Read the object class and domain identifier before extracting fields. Make sure the server returned the domain you asked for.
- Record events with their eventAction values. Do not merge registration, expiration, last changed and database update into one date.
- Review status, registrar, nameservers, DNSSEC, entities, remarks, notices and redaction markers. Preserve nulls and absent fields as absent.
- If the task concerns a website operator, check the site's legal pages and other first-party disclosures. Label that evidence as operator information, not registration data.
- If nonpublic gTLD data is necessary for a lawful purpose, use the sponsoring registrar's process or ICANN RDRS where available.
This workflow produces a result that another analyst can reproduce. It also makes uncertainty visible. A report can say that Verisign RDAP showed a particular registrar and nameserver set at a stated time while the registrant entity was absent. That is stronger than claiming that the registrar, CDN or website footer proves ownership.
Infrastructure pivots without false attribution
DNS records, certificates and web content can add context after the registration lookup. They answer different questions. A nameserver change can show that delegation moved. An MX record can identify the current mail route. Certificate Transparency can show that a certificate for a name was logged. A privacy policy can name the entity claiming to operate the service. None of those observations, alone, proves who registered the domain or why it was registered.
- Shared Cloudflare nameservers show use of a shared DNS platform, not a relationship between all domains on that platform.
- A DNS TXT verification token shows that a service challenge was configured. It does not identify the legal registrant unless the token can be tied to a documented account through a reliable source.
- A Domain Validated certificate shows successful domain-control validation for issuance. It does not identify the registrant.
- A company name in terms, privacy or imprint text can support website-operator attribution, but the registration may be held by an affiliate, employee, agency or privacy service.
- Domains registered through the same registrar are not necessarily related. Large registrars serve unrelated customers.
Corroboration still matters. If current RDAP, first-party legal text and a verified corporate disclosure point to the same organization, an analyst can describe that convergence and cite each source. The wording should match the evidence: operated by, registered to, uses the same infrastructure as, or was observed with. Those phrases are not interchangeable.
Using DomScan for single and bulk searches
DomScan's WHOIS Lookup returns parsed, normalized registration data including registrar, dates, nameservers and status. The response also reports source and fallback evidence, which matters when a registry lacks a working RDAP path and the lookup uses another supported source. Use this endpoint when you want a consistent registration shape rather than the registry's raw object.
curl -H "X-API-Key: $DOMSCAN_API_KEY" \
"https://domscan.net/v1/whois?domain=example.com"
curl -H "X-API-Key: $DOMSCAN_API_KEY" \
"https://domscan.net/v1/rdap?query=example.com&type=domain"
curl -H "X-API-Key: $DOMSCAN_API_KEY" \
"https://domscan.net/v1/rdap?query=8.8.8.8&type=ip"
curl -H "X-API-Key: $DOMSCAN_API_KEY" \
"https://domscan.net/v1/rdap?query=AS174&type=autnum"The raw RDAP Lookup supports domain, IP address and autonomous system number objects. Domain is the default query type; `type=ip` and `type=autnum` select the other object classes. Use raw RDAP when entity roles, notices, remarks, links or registry-specific extensions matter. Clients should tolerate optional or unknown JSON members, as RFC 9083 permits servers to omit optional registration fields and add namespaced extensions.
The Domain Profile is narrower. It turns RDAP registration data into a clean profile with registrar information, registration dates, nameservers, DNSSEC and status. It is not a combined DNS, hosting, technology or reputation report. Use Domain Overview or the relevant dedicated endpoints when the task needs those other layers.
For batches, `POST /v1/whois/bulk` accepts between 1 and 20 domains and charges 2 credits per domain. It returns parsed registration results for each input. A bulk request does not populate DomScan WHOIS History. Keep the input list, request time and per-domain errors so a missing result is not mistaken for an unregistered domain.
curl -X POST "https://domscan.net/v1/whois/bulk" \
-H "X-API-Key: $DOMSCAN_API_KEY" \
-H "Content-Type: application/json" \
-d '{"domains":["example.com","nominet.uk","sidn.nl"]}'What DomScan WHOIS History records
DomScan WHOIS History is an observation log, not a commercial historical WHOIS archive. A fresh, successful, RDAP-backed single-domain request to `GET /v1/whois` or `GET /v2/whois` can store at most one normalized snapshot for that domain per UTC day. Cached responses, bulk lookups, history reads and traditional WHOIS-only fallbacks do not create snapshots. A popular domain can therefore have no DomScan history, and a quiet domain can have gaps between observations.
Snapshots can include registrar name and IANA ID, creation, expiry and update dates, status, nameservers, DNSSEC, transfer-lock detection and privacy or redaction detection. Comparisons can report changes in those normalized fields. The log does not store registrant identity or contact history, and it cannot prove an ownership change or transfer. Summary values such as first seen, last seen and total snapshots describe the returned limit-scoped window, not an undisclosed lifetime archive beyond that window.
Common questions
Can a WHOIS search tell me who owns a website?
Usually not by itself. Public RDAP may publish a consented registrant organization or another registrant entity, but many responses redact or omit personal contact fields. Even a named registered holder may differ from the entity operating the website. Report the role actually shown by the source.
Does a missing RDAP result mean the domain is available?
No. The service may be unavailable, the TLD may lack an IANA RDAP bootstrap entry, the query may be malformed, or the registry may use another lookup system. Availability needs a domain availability check that understands the relevant registry and treats network or protocol errors as unknown rather than available.
Does the updated date show a transfer or contact change?
Not without more evidence. RDAP event actions distinguish `last changed` from the `last update of RDAP database`, but a last-changed event does not state which field changed. Compare dated responses and preserve the specific field differences. Do not infer a transfer from one timestamp.
Can I request nonpublic gTLD registration data?
A person with a legitimate, lawful need can use the sponsoring registrar's disclosure process. ICANN RDRS provides a standardized submission route for participating registrars. The requestor must supply the required basis and documentation, and the registrar evaluates the request. Public search tools do not bypass that process.
Write the conclusion the evidence supports
A good domain registration report is specific and dated. It identifies the authoritative service, records the response time, quotes the registrar and events, distinguishes absent fields from redacted ones, and labels infrastructure observations separately. It also states what the data cannot answer. That discipline is more useful than a confident owner name assembled from a registrar, a shared nameserver and an old screenshot.
Start with RDAP for gTLDs. Follow the registry's current policy for country codes. Use normalized WHOIS when you need consistent fields, raw RDAP when you need the original object, bulk lookup for a reproducible list, and DomScan history only for its actual observation window. If the registrant is not public, leave it unknown unless another authoritative source establishes the relationship.