Assess my case

RDAP and WHOIS lookup guide: identifying a hidden registrant

Your domain stopped resolving overnight. The WHOIS record now shows a privacy proxy or a name you do not recognize. The question is not whether something went wrong – it is who is behind the new registration, and how you get that information before a filing deadline runs.

Identifying a hidden registrant today requires three sequential steps: an RDAP lookup to retrieve whatever public data the registrar exposes, a targeted request through ICANN's Registration Data Request Service (RDRS) for the non-public data, and a parallel approach to the registrar's abuse contact where the facts support it. As of 28 January 2025, ICANN no longer requires registrars to operate a WHOIS service; RDAP is now the standard source of registration data, and public lookups frequently return redacted records for individuals. Getting behind that redaction is possible but not guaranteed.

This guide walks each step, explains what the tool below checks off, and states plainly what investigation cannot deliver on its own.

Why WHOIS redaction changed and what RDAP replaced it with

RDAP – the Registration Data Access Protocol – became the baseline registration-data standard when ICANN formally retired the mandatory WHOIS requirement on 28 January 2025. The change did not create new privacy; it standardized a practice registrars had already adopted under data-protection law. Personal data for individual registrants is redacted by default.

What does RDAP actually give you? The registrar name, the creation and expiry dates, the name servers, the domain status codes, and – critically – the registrar abuse contact email and phone number. Registrant name, email, and postal data are typically replaced with a privacy proxy identifier or omitted entirely.

The practical difference from old WHOIS is structural, not cosmetic. RDAP returns machine-readable JSON, supports tiered access (meaning a credentialed requester can see more than an anonymous one), and links to the RDRS channel for disclosure requests. A raw RDAP query tells you whether a disclosure pathway even exists for that registrar – which is the first piece of information an investigation needs.

What does this investigation checklist cover?

The checklist below is a structured investigation workflow. It does not compute a probability or a score. It prompts you to complete and document each step in the correct order, so that nothing is omitted that a panel or court would expect to see in a good-faith investigation record.

Work through every item in sequence. If an item is not applicable to your zone or registrar, note it as inapplicable with a reason – a gap in the record without explanation weakens any later disclosure argument.

  • Run an RDAP lookup on the domain and save the full JSON response with a timestamp.
  • Record the registrar name, the registrar IANA ID, and the registrar abuse contact email and telephone number from the RDAP response.
  • Check the domain status codes: verify whether a registrar lock (clientTransferProhibited or serverTransferProhibited) is present, and note any pendingDelete or redemptionPeriod flags.
  • Confirm whether registrant contact data is redacted (a privacy proxy or empty fields) or partially visible, and document the exact fields returned.
  • Identify whether the registrar participates in ICANN's Registration Data Request Service (RDRS); the ICANN RDRS portal lists current participating registrars.
  • Submit an RDRS disclosure request through the ICANN portal if the registrar participates; state the legal basis for your request, the domain dispute or investigation context, and attach supporting documentation.
  • If the registrar does not participate in RDRS, send a written disclosure request directly to the registrar abuse contact, stating the same legal basis and attaching documentation.
  • Record the date of each disclosure request and the registrar's response or non-response, noting any deadline by which a response is needed for a pending filing.
  • Check historical RDAP and WHOIS snapshots in available public archives to establish the registration history and any changes in registrant data over time.
  • Where the domain is involved in a UDRP or URS complaint, note that WIPO's case-administration process includes a formal mechanism for registrar disclosure; the disclosure request through RDRS or abuse contact is in addition to, not instead of, that channel.
  • Where the matter may proceed to court, preserve all RDAP responses, disclosure requests, and registrar communications in a single timestamped folder – this is your investigation record.
  • Assess whether the data obtained is sufficient to name the registrant in a complaint or filing, or whether a further step – such as a court-ordered subpoena or a formal registrar demand – is needed.

How RDAP, RDRS, and the registrar abuse channel work together

Think of the three channels as a funnel. RDAP is the public layer – open, instant, but heavily redacted. RDRS is the structured request layer – voluntary for registrars, with no guaranteed response time and no guaranteed disclosure. The registrar abuse contact is the direct-contact fallback, and it carries its own practical weight when the facts involve active DNS abuse.

ICANN's RDRS pilot was originally a two-year program. ICANN announced on 20 November 2025 that it had been extended while next steps are decided; as of the date of this guide, RDRS remains operational, but the long-term model is not yet settled – verify the current RDRS status before filing a request. Participation is not universal: a registrar that does not list in the RDRS portal will not process a request through that channel, and the fallback is a direct written request to the abuse contact.

What can the registrar abuse contact actually do? It can pass a disclosure request to an internal compliance or legal team. It cannot compel disclosure where data-protection law prohibits it. And it operates on the registrar's own response schedule, not yours. In our practice, the most effective abuse-contact requests are specific about the legal basis – a pending UDRP complaint number, a court filing reference, or a written demand that a specific transfer be reversed – rather than a general inquiry.

Does the timing of your request affect the outcome? Yes, materially. A disclosure request filed after a complaint is already lodged carries procedural weight it does not have in isolation. Where a UDRP is pending, WIPO's case-administration team contacts the registrar directly as part of the formal commencement process, which typically unlocks the registrar's legal team faster than an unsupported pre-complaint request.

For an assessment of your domain dispute – including whether the registrant data you have is sufficient to file – contact info@cognomenlaw.com.

What the checklist cannot tell you

The checklist confirms that each step was taken and documented. It does not interpret the data you receive, evaluate whether a disclosed identity is the actual beneficial controller of the domain, or determine whether the facts satisfy the legal elements of a UDRP complaint or a court claim.

Several limits are worth stating directly. First, registrar disclosure is never automatic – each request is assessed by the registrar, and refusal without explanation is common. Second, where the registrant used a reseller or a privacy-proxy service layered on top of the registrar's own systems, a single RDRS request may surface only the proxy operator's data, not the underlying registrant. A second-level request to the proxy operator, or a formal demand backed by legal proceedings, is then required.

Third, historical snapshot data shows what the WHOIS record said at a prior point in time, but it may not be legally authenticated. For a court proceeding or an arbitration that requires authenticated evidence of the registration history, a formal request to the registrar for certified records is the only reliable route. A screenshot of a public archive is a useful pointer; it is not a court-ready exhibit on its own.

Fourth – and this is the limit a brand owner most often underestimates – identifying the registrant is not the same as proving bad faith. The two steps are linked, but they are not the same step. You can identify the registrant perfectly and still face a contested case on the merits of whether the registration was in bad faith under Paragraph 4(a)(iii) of the UDRP, or the equivalent element in the applicable ccTLD procedure.

How to use the result: from investigation record to a filing decision

The output of a completed checklist is an investigation record: a dated, documented account of what you did, what you found, and what you could not obtain. That record has two functions. It supports a disclosure argument to a panel or court – showing that you made genuine attempts to identify the registrant before filing. And it tells you, clearly, whether the gaps in the record are tolerable or fatal.

A tolerable gap looks like this: the registrar did not respond to an RDRS request within a reasonable period, the RDAP data identifies the registrar and the creation date with precision, and the domain's conduct – a parking page with competing advertisements, a redirect to a competitor, or a ransom demand – is fully documented by independent screenshots. A panel assessing a UDRP complaint can work with this. The registration identity is less critical than the conduct evidence where bad faith is demonstrable from the use pattern alone.

A potentially fatal gap looks different: no registrar participation in RDRS, no response to the abuse contact, no historical data, and a domain that was registered recently through an offshore registrar with thin conduct evidence. In that situation, the investigation record does not yet support a filing. The next step is not a complaint – it is a registrar escalation, potentially a formal legal demand, or a court-ordered subpoena if the relevant jurisdiction supports that route.

In a recent matter (a stolen .com domain, spring 2026), we used RDAP data combined with a registrar abuse-channel disclosure to piece together the chain of unauthorized transfers across two privacy proxies. The registration data alone was insufficient; it was the audit log produced by the registrar in response to a formal demand letter – supported by a documented investigation record of the kind this checklist produces – that established the account compromise and enabled a transfer reversal.

When investigation leads to a legal procedure

Once the investigation record is assembled, the route to recovery depends on the zone, the conduct, and what the data shows. For a .com or other gTLD domain where the registrant is using the name in bad faith, a UDRP complaint before WIPO or the Forum is the standard path – with a filing fee starting at USD 1,500 for a single-member panel and a typical resolution period of about two months. Where the domain is a new gTLD and the only remedy needed is rapid suspension, URS is faster and lower cost.

Some disputes are not arbitration cases. If the domain was transferred without consent – a classic hijacking scenario – the UDRP is not always the right tool. The UDRP requires bad-faith registration; a hijacked domain may have been legitimately registered by the original owner and then stolen. That fact pattern typically requires direct registrar escalation, a registrar lock demand, and potentially court action in the registrar's jurisdiction. COGNOMEN handles both paths.

A court action is slower and more expensive than a UDRP for most disputes. But it is the only route that reaches damages and the only route available for zones like .de, where the UDRP does not apply and a DENIC DISPUTE entry blocks the domain while litigation proceeds. Some brand owners assume a court is always faster. The opposite is generally true for the majority of gTLD disputes, where arbitration resolves in weeks and litigation resolves in months or years.

The fees stated in this guide reflect published rates as of 2026-08-08; confirm current rates before filing.

To plan the recovery of a stolen or hijacked domain, contact info@cognomenlaw.com.

About COGNOMEN

COGNOMEN is an independent boutique focused exclusively on domain-name disputes. We recover, defend, and transact internet domains across generic and country-code zones, before WIPO, the Forum, CAC, ADNDRC, and national procedures, and in court where arbitration cannot reach. We act for brand owners, domain investors, and registrants – including respondent-side defense and reverse domain name hijacking. COGNOMEN focuses only on domain-name disputes: recovery, defense, and transactions, with transparent published fee ranges and a genuine practice on both sides of the dispute. To discuss a domain, contact info@cognomenlaw.com.

Related at COGNOMEN

Frequently asked questions

How accurate is this checklist?

The checklist is accurate as a procedural record: it reflects the investigation steps that RDAP, RDRS, and the registrar abuse channel actually support as of the date of this guide. It does not assess the legal strength of your facts or predict whether a registrar will disclose. Each step is drawn from ICANN's published rules and standard registrar practice; no step is invented. Where a step depends on registrar participation – particularly RDRS – the current list of participating registrars should be verified at the ICANN portal before submitting a request.

What is not included in the result?

The checklist does not interpret the data you collect, evaluate whether the identity disclosed is the beneficial controller of the domain, or determine whether your facts satisfy the three elements of a UDRP complaint. It also does not cover zone-specific procedures such as the Nominet DRS for .uk or EURid ADR for .eu, which have their own registrant-disclosure channels. For disputes in those zones, or where the domain was transferred without consent, the applicable national procedure and a direct legal assessment are both needed.

What should I do with the number it gives me?

This checklist does not produce a number. It produces a completed investigation record. That record supports two decisions: whether you have enough registrant data to name a respondent in a formal filing, and whether the gaps in the record require a further step – a formal demand letter, registrar escalation, or court-ordered disclosure – before a complaint can proceed. Once the record is assembled, share it with counsel for a case assessment. The registration data alone rarely tells the full story; the conduct evidence documented alongside it is what drives the merits of a dispute.

Author: — Court anticybersquatting and domain theft recovery. Meet the team.

Speak with Cognomen Law

For a scoped view of your domain matter, contact info@cognomenlaw.com. Discuss your matter

No obligation. Confidential. We reply within two hours in business hours.

This publication is general information and does not constitute legal advice. For advice on your situation, contact info@cognomenlaw.com.