RDAP Lookup

RDAP is the new standard for domain lookups. It's designed to fix the inconsistencies that have plagued the WHOIS system for (40) years. No more parsing nightmares because every registry has decided to reinvent the contact field. Instead of plain text, RDAP returns structured JSON responses over HTTPS. It can include additional details like entity relationships, role definitions, and event timelines – making it much more reliable for automation. Think of it as WHOIS revamped as a modern API – it's mostly the same source data but with a more user-friendly format.

Not really. It's usually the same source data, just in a better format. Some registrars may provide slightly different sets of data through each protocol, but the core registration data should be identical. Privacy protection still redacts the same fields. As RDAP adoption grows, it will become the primary source for this information across all registries.

Nope. RDAP follows the same privacy rules as WHOIS. If the domain is using privacy protection, RDAP will return the same redacted or proxy information that you'd see in a WHOIS record.

In an official sense, yes. ICANN considers WHOIS deprecated since Jan. 2025, and RDAP is mandatory for new gTLDs. In reality both systems are still in use but the level of support varies. Some registries have already shutdown their WHOIS servers, while others are sending deprecation notices with each response. Who knows, WHOIS may just outlive us all.

Coverage is growing steadily and most major TLD registries now support RDAP, including .com, .net, .org, and many country-code TLDs. ICANN required new gTLD registries to support RDAP starting in 2019, but ccTLDs live by their own rules. These registries are often run by small government departments or academic institutions, which can mean slower progress. You can track the progress of RDAP support amongst registries on RDAP.ORG.

RDAP outputs all contact info using jCard, which is an overly complex JSON version of vCard. Each contact field is a typed array element, so it's an array of arrays, because a simple object would be too easy. It's like they asked "how can we make contact data as unreadable as possible" and jCard was born. Here's a great resource on jCard and everything else you might want to know about RDAP.

Yes, RDAP is not just for domains. You can also look up IP addresses or ASNs (Autonomous System Numbers). Each major RIR (Regional Internet Registry), e.g. ARIN, RIPE, or APNIC, runs its own RDAP service. An Autonomous System Number may sound like dystopian jargon, but it's just a unique identifier for large ISPs and other network operators on the global internet routing table.

RDAP servers sometimes use HTTP redirects (3xx) to send clients to a different authority, especially after a domain has been transferred.

Referrals are a way to link to other servers or resources, usually pointing from the registry (who owns the domain) to the registrar (who manages it). Starting from one of the bootstrap servers, you will get referral links that lead to the correct authoritative endpoint. Follow the yellow brick road (referral chain) and you'll eventually find the Wizard (authoritative data). It's like how nameserver delegation works in DNS, but for registration/ownership info.

Domain status codes (aka EPP status) describe a domain's current state and any security locks. They control whether a domain can be transferred, updated, deleted, or resolved in DNS. Multiple codes can apply at once, and some are set by the registrar ("client") while others are enforced by the registry ("server").

• ok – No restrictions, domain is active, nameservers are configured. Can be updated, transferred, or deleted.
• active – Registered and nameservers configured; may have other restrictions.
• inactive – Registered but not resolving due to no nameservers or hold.
• clientTransferProhibited – Registrar lock blocking transfers. Must be removed before transfer.
• serverTransferProhibited – Registry-applied lock blocking transfers. Requires registry approval to remove.
• clientDeleteProhibited – Registrar-applied lock preventing deletion (including transfer to another registrar). Used to protect important domains.
• serverDeleteProhibited – Registry-applied lock preventing deletion; cannot be removed by the registrar alone.
• clientHold – Registrar suspension that removes the domain from DNS. Common causes: unpaid renewal, invalid/expired WHOIS data, abuse complaints.
• serverHold – Registry suspension that removes the domain from DNS. Common causes: abuse or policy violations, legal disputes.
• redemptionPeriod – (30-45 days) Domain has expired and been removed from DNS, but can be restored by the original owner (for a fee).
• pendingDelete – (5 days) Final deletion stage after redemption. Cannot be restored by owner.
• pendingTransfer – Transfer in progress; no modifications allowed.
• pendingRestore – Restoration requested after redemption; not yet complete.
• renewPeriod – Automatic renewal grace period after successful renewal.
• pendingUpdate – A change (e.g., contact info, nameservers) is in progress; not yet finalized in the registry.