What is RDAP (Registration Data Access Protocol)?

RDAP (Registration Data Access Protocol) is the standardized, structured web protocol that replaced WHOIS as the official means of querying domain-name registration data held by registrars and registries.

As of 28 January 2025, ICANN no longer requires registrars to operate a WHOIS port-43 service; RDAP is now the baseline standard for accessing registration records. The protocol returns data in a machine-readable JSON format, supports authentication for tiered access, and reflects data-protection requirements by redacting personal registrant information for individuals by default. For anyone investigating a domain dispute, a domain theft, or an unauthorized transfer, RDAP is the first technical checkpoint – and understanding what it can and cannot tell you is the difference between a well-framed case and a misdirected one.

This page defines RDAP precisely, distinguishes it from the concepts readers most often confuse it with, traces it to its governing rules, and shows how it arises in three recognizable dispute situations.

What is RDAP and what does it actually do?

RDAP is a query-and-response protocol that lets any Internet user – or any automated system – look up the registration record for a domain name by sending a structured HTTPS request to the relevant registry or registrar server. The response is a JSON object containing fields such as the domain's status flags, the registrar of record, the registration and expiration dates, the sponsoring registrar's abuse contact, and, where disclosed, registrant contact details.

The critical phrase is where disclosed. Data-protection law – principally the EU's General Data Protection Regulation and comparable national legislation – has caused registrars to redact personal registrant data from the public RDAP response. What you see in a public lookup is therefore a partial record. You will typically find the registrar's name, the domain's status codes (such as clientTransferProhibited, which signals a registrar lock), nameserver assignments, and the dates of key events. You will rarely see the registrant's name, email, or postal address in a public response.

That limitation is deliberate and rule-based, not a system fault. Understanding it prevents the mistake of treating an incomplete RDAP response as evidence that a domain has no identifiable owner.

How does RDAP differ from WHOIS?

WHOIS is the term readers most often conflate with RDAP. The two perform the same underlying function – revealing registration data – but they are architecturally distinct. WHOIS is a plain-text, unstructured, port-43 TCP protocol dating from the early Internet. RDAP uses HTTPS, returns structured JSON, supports authentication, and is extensible by zone. Most importantly, RDAP is the system ICANN formally transitioned to on 28 January 2025.

In practice, the shift means that software and counsel querying registration data must now work with RDAP endpoints rather than relying on a WHOIS client. Many legacy monitoring tools and domain-dispute workflows were built around WHOIS; if they have not been updated, they may return stale or incomplete results. We regularly advise registrants and brand owners to confirm that their internal tools are querying current RDAP endpoints, particularly when the record they are reading will be presented as evidence in a dispute.

One procedural consequence of the WHOIS-to-RDAP transition: ICANN's Registration Data Request Service (RDRS), which is the designated channel for requesting non-public registrant data from participating registrars, extended its pilot beyond its original two-year window. As of 28 January 2025 – and reaffirmed by an ICANN announcement on 20 November 2025 – the RDRS remains operational while ICANN decides its long-term form. Readers should confirm the current status of the RDRS directly, as the position was still in motion as of the date this page was prepared.

Where does RDAP sit in the ICANN rules?

The obligation to implement RDAP flows from ICANN's Registrar Accreditation Agreement (RAA) and corresponding Registry Agreements, both of which were updated to make RDAP the baseline standard in place of WHOIS. The transition date – 28 January 2025 – is the operative benchmark; after that date, a registrar's failure to maintain a working RDAP endpoint is a contractual compliance issue, not merely a technical gap.

The same agreements govern the tiered-access model. A public RDAP query returns the redacted baseline record. An authenticated query – made by an accredited requestor such as law enforcement, an intellectual property rights holder with standing, or a party to an ICANN-recognized dispute procedure – may elicit more complete data. Whether the registrar discloses additional data through RDRS or an equivalent channel remains at the registrar's discretion; disclosure is not automatic, and the registrar's response time is outside the requester's control.

For domain-dispute purposes, the practical consequence is that identifying a registrant for a UDRP complaint or a domain-theft recovery action now typically requires an RDAP lookup followed by a formal disclosure request, with no guaranteed timeline on the registrar's response.

How does RDAP arise in domain disputes and theft recovery?

Three patterns appear consistently in our practice.

Pattern 1 – Pre-complaint registrant identification. A brand owner discovers that a domain confusingly similar to its trademark has been registered. The RDAP record reveals the registrar, the creation date, and the domain's status flags, but the registrant's identity is masked. The brand owner must file a disclosure request through the registrar's RDRS gateway or equivalent process. If the registrar responds and discloses the registrant's details, the UDRP complaint can be addressed to a named respondent. If the registrar does not respond within the UDRP filing window, the complaint proceeds against the proxy or privacy service – a complication that affects the bad-faith analysis but does not prevent filing.

Pattern 2 – Domain-theft investigation. A registrant's domain stops resolving. The RDAP record shows a changed registrar of record, altered nameservers, and a status flag that no longer matches the account the legitimate holder controls. Those RDAP fields – timestamped and retrieved contemporaneously – are the foundational evidence for a registrar-escalation complaint and, where needed, a court application for emergency relief. In a recent matter (a .com domain, spring 2026), the RDAP record's transfer-event timestamp was the decisive document establishing that an unauthorized outbound transfer had occurred within hours of a phishing event targeting the registrant's email account.

Pattern 3 – UDRP evidence and the registrar-lock status. In contested UDRP cases, both complainants and respondents rely on RDAP data to establish the timeline of registration, use, and any changes in status. A clientTransferProhibited flag visible in the RDAP record confirms a registrar lock is in place – relevant both to the bad-faith analysis under Paragraph 4(b) and to any interim relief request. A missing lock on a domain at the center of a dispute is, conversely, a risk signal that counsel should address at the outset of a case.

Why does RDAP matter to brand owners and registrants?

The shift from WHOIS to RDAP is not a cosmetic update. It changes the workflow for monitoring, investigation, and evidence gathering in every zone where ICANN's contracts apply – which covers all accredited registrars for gTLDs and many ccTLDs.

Brand owners running domain-monitoring programs need to confirm that their monitoring vendors have updated their query infrastructure to RDAP endpoints. A monitoring report generated from a WHOIS client that is no longer authoritative may miss status-flag changes, registrar transfers, or expiry warnings that an RDAP query would surface. Catching those events early is the difference between a preventive letter and an emergency UDRP filing.

Registrants facing a dispute or a theft scenario should understand that the RDAP record of their domain – its creation date, its current status flags, and the history of changes – will be read by the opposing party's counsel and by any panel or court. A registration held in a privacy service that has stopped responding to requests can look, on the RDAP record alone, like an uncontactable actor. That is a bad-faith inference the record alone creates; managing the RDAP footprint of a domain portfolio is part of sound defensive posture.

If your domain's RDAP record shows unexpected changes, or if you are preparing evidence for a UDRP complaint or a domain-theft recovery, a specialist read of the registration data is the correct starting point. For an assessment of a domain dispute or recovery matter, contact info@cognomenlaw.com.

COGNOMEN focuses only on domain-name disputes – recovery, defense, and transactions. We handle court action and domain-theft recovery across gTLDs and ccTLDs, and we act for brand owners, investors, and registrants in UDRP proceedings, ccTLD procedures, and court actions where arbitration cannot reach. To discuss a domain, contact info@cognomenlaw.com.

Related at COGNOMEN

• court recovery – court-based routes for domain theft and cybersquatting remedies
• What is Domain escrow? Definition and meaning – how escrow protects parties in domain name transactions
• enforce udrp decision tv – enforcing a UDRP transfer order through court where needed

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.