WHOIS is gone: RDAP became the standard in January 2025

On 28 January 2025, ICANN's requirement that registrars operate a public WHOIS service expired. RDAP – the Registration Data Access Protocol – became the single standard source of domain registration data. For anyone who routinely queried a domain's owner before filing a complaint, initiating a recovery, or investigating a theft, that transition changed the starting point for nearly every investigation.

As of 28 January 2025, registrars are no longer obliged to maintain WHOIS. RDAP, the successor protocol, returns structured machine-readable registration data at the same endpoint, but registration data for individuals is redacted by default under data-protection law. Identifying a registrant now requires an RDAP lookup followed by a separate disclosure request through ICANN's Registration Data Request Service (RDRS), and the registrar decides whether to respond.

This page explains what RDAP returns, what is withheld, how the RDRS works, and what the change means if you are pursuing a domain dispute, a recovery after theft, or a UDRP complaint.

What is RDAP, and how does it differ from WHOIS?

RDAP is a web-based protocol that returns domain registration data in structured JSON format, replacing the plain-text WHOIS query-response system that dated to the 1980s. The information categories are broadly the same – registrar, registration date, expiry date, nameservers, and registrant contact fields – but the delivery mechanism and the access-control layer are fundamentally different.

WHOIS was a single open channel. Anyone with a command-line tool could query any domain and receive whatever the registrar published. RDAP builds in tiered access from the start: public queries return a standardized set of fields, while sensitive fields – including registrant name, email address, and postal address for natural persons – are withheld in most public responses. The redaction follows data-protection obligations under GDPR and comparable national laws. It is not optional for registrars to fill those fields for individuals; the default is redacted, and a requester who needs the data must go through a separate channel.

The practical effect: querying a domain through RDAP today often returns the registrar's name, the domain's status flags, the creation and expiry dates, and nameserver records, but a blank or anonymized contact block. That was true under WHOIS for privacy-proxy registrations. Under RDAP, it is the default for every individual registrant.

How do you obtain registration data that is now redacted?

ICANN's Registration Data Request Service (RDRS) is the designated channel for requesting non-public registration data from participating registrars. A requester submits the domain and states a purpose – most commonly an intellectual-property dispute, an investigation of domain abuse, or a legal proceeding. The registrar then assesses the request and decides whether to disclose.

Several points matter for domain disputes and court recovery actions. First, participation in the RDRS is not universal: not every registrar has joined the service. Second, disclosure is not automatic or guaranteed; the registrar exercises discretion, and the response timeline is outside the requester's control. Third, ICANN announced on 20 November 2025 that the RDRS pilot was extended while next steps are determined – as of the date of this article, that pilot status is in effect; verify the current position before relying on it for case strategy. Fourth, where a registrar declines or does not respond, the remaining routes include a subpoena in a court action, a data-disclosure request through the relevant privacy regulator, or a request made within a pending domain-dispute proceeding itself.

The UDRP process does not provide a formal mechanism to compel registrar disclosure before a complaint is filed. Panels cannot order discovery. If the registrant's identity matters to establishing a pattern of bad-faith registrations – one of the Paragraph 4(b) factors under the UDRP – a complainant may need to rely on whatever the RDAP record and the RDRS produce before drafting the complaint.

Who is affected by the WHOIS-to-RDAP transition?

The transition touches every category of domain-dispute participant. Brand owners investigating cybersquatting, domain investors assessing a counterpart's history, registrants challenging a transfer they did not authorize, and lawyers preparing a complaint or a response all start with the registration record. That record is now accessed differently and returns less by default.

For brand protection teams running monitoring programs, the workflow change is significant. Automated WHOIS polling was a standard component of alert systems. RDAP endpoints exist and are publicly documented, but the data returned for newly registered look-alike domains will frequently omit the registrant identity. A brand owner who spots a confusingly similar registration may see the registrar and the creation date but not the registrant's name or contact information – exactly the data needed to evaluate whether the domain was registered with the mark in mind.

For domain theft and hijacking matters, the impact is sharper. When a domain is transferred without the legitimate owner's consent, the first question is who the registration record now shows. Under the old system, that query was instant. Under RDAP with redaction, verifying a fraudulent transfer may require an RDRS request and a wait. In those cases, speed matters: every day the fraudulent registrant controls the domain is a day the name can be pointed elsewhere, sold on, or used to intercept communications. We regularly advise registrants in this situation to pursue registrar-level escalation – a registrar lock and a theft complaint – in parallel with any data-disclosure request, not after it.

What does RDAP mean for UDRP complaints and domain disputes?

In most UDRP proceedings, the registrant's identity is not the primary obstacle. The complainant does not need to know the registrant's full name to file; the complaint is directed to the domain itself, and the forum serves the respondent using the contact data it holds. Where the registrant used a privacy service, ICANN rules require the registrar or the privacy provider to forward the complaint. That mechanism is unchanged.

What changes is the evidentiary preparation before filing. Establishing a pattern of abusive registrations – relevant under Paragraph 4(b)(ii) of the UDRP – typically involves linking the disputed domain to other registrations held by the same entity. Under WHOIS, shared registrant names or email addresses were sometimes visible across multiple domains. Under RDAP with default redaction, that linking exercise is harder unless the registrant has been careless with contact data or unless RDRS disclosure is obtained.

Passive holding cases – where a domain is registered and parked with no active use – still turn on circumstantial evidence of bad faith. The RDAP record's creation date, the registrar's location relative to the mark owner's market, and the absence of any identifiable legitimate use all remain relevant. The registration date is one of the fields RDAP returns publicly. In our practice, that date is often one of the most important data points in a bad-faith analysis, and it is still available.

For an assessment of how the RDAP transition affects your ability to pursue or defend a domain claim, contact info@cognomenlaw.com.

What happened to the RDRS pilot, and what comes next?

ICANN launched the RDRS as a temporary structure after WHOIS redaction became the norm. The two-year pilot was extended beyond its original term; as of 27 September 2026, ICANN has not yet announced a permanent replacement structure. The RDRS continues to operate. Verify the current status directly with ICANN before building a workflow that depends on it.

The broader question – how a legitimate requester with a real dispute interest obtains non-public registration data from a reluctant registrar – remains open. ICANN's contracted parties obligations cover DNS abuse responses (under the 2024 amendments to the Registrar Accreditation Agreement that took effect on 5 April 2024) but do not directly compel data disclosure in trademark or cybersquatting disputes. Some in the policy community have pushed for a tiered-access system that would give verified IP-rights holders faster access to redacted data; that proposal is under discussion, not adopted.

Meanwhile, the practical advice is unchanged: document everything visible at the time of discovery. Cache the RDAP response, the RDNS record, and any visible content of the disputed domain at the point you identify the problem. That contemporaneous evidence often carries more weight in a UDRP complaint or a court filing than a later-obtained registration record, because it shows the domain's use at the moment the dispute crystallized.

The The 'true cancellation' proposal explained – another development from the UDRP policy review – is a separate but related change worth reading alongside this one. Both affect how domain disputes are investigated and resolved going forward.

Practical steps for brand owners and registrants now

Whether you are a brand owner monitoring for abuse or a registrant protecting a name you legitimately hold, the RDAP transition calls for three adjustments to standard practice.

First, update your monitoring tools. Any system that polled WHOIS directly needs to be reconfigured to query RDAP endpoints. The data returned is structured differently; automated parsers built for WHOIS plain-text output will not work without modification. Several monitoring services have already made this transition; verify your provider's current output against an RDAP query on a known domain to confirm accuracy.

Second, submit RDRS requests early. If you identify a suspicious registration and intend to file a dispute, submit the RDRS disclosure request as soon as you decide to investigate – before drafting the complaint. The registrar's response time is unpredictable. Starting that clock early gives you the best chance of having the data before your filing deadline or before a UDRP response is due.

Third, if your domain stops resolving and the registration record shows a change you did not authorize, treat it as a theft and escalate to the registrar immediately. Do not wait for RDAP data to confirm the picture. A registrar lock, an account-compromise report, and a request to reverse the transfer are the first actions. An RDRS request and a dispute filing follow, but the registrar escalation must come first to stop the clock on unauthorized use.

For matters where the registrant's identity is genuinely unascertainable through RDAP and the RDRS, and where the stakes justify it, a court action can produce compelled disclosure through a subpoena – something no UDRP panel can order. See our case recover stolen domain finance for a worked example of how court action and registrar escalation worked together in a theft scenario.

To plan recovery of a stolen or hijacked domain, or to assess how the RDAP transition affects a pending UDRP filing, contact info@cognomenlaw.com.

COGNOMEN focuses only on domain-name disputes – recovery, defense, and transactions. We handle Court Action and domain theft matters across gTLDs and ccTLDs, including registrar escalation, UDRP complaints, and court action where arbitration cannot reach. We act for brand owners and registrants, including respondent-side defense. To discuss a domain matter, contact info@cognomenlaw.com.

Related at COGNOMEN

• court recovery – when arbitration falls short and court action is the right route
• The 'true cancellation' proposal explained – what the proposed new UDRP remedy would mean in practice
• case recover stolen domain finance – how registrar escalation and court action recovered a hijacked domain

Author: Adrian Harland — 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

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