RDAP, the Registration Data Access Protocol, is the standardized service for querying registration data about domain names, IP address blocks and autonomous system numbers over HTTPS, with answers returned as structured JSON. In the world of domain names on the Internet, it is the designated successor to WHOIS: it answers the same questions, such as who registered a domain, through which registrar, and when it expires, but in a machine-readable and access-controlled form.
The protocol is defined by a family of IETF specifications, chiefly RFC 9082 for queries and RFC 9083 for the JSON responses, with RFC 7480 and RFC 7481 covering HTTP usage and security. Registries and registrars of generic top-level domains are contractually required to operate RDAP, and the regional internet registries have offered it for IP and AS data for years.
How RDAP queries work
An RDAP query is an ordinary HTTPS GET request to a well-defined URL path. A client asking about a domain requests a path such as /domain/example.com from the correct server; for an IP address it uses /ip/192.0.2.1, and for an autonomous system /autnum/64500. The server replies with a JSON document and an HTTP status code, so a missing object returns 404 rather than free text.
The difficult part is knowing which server to ask. RDAP solves this with bootstrap registries published by IANA: JSON files that map each top-level domain, each IPv4 and IPv6 block and each AS number range to the base URL of the authoritative RDAP service. A client downloads these files, finds the longest matching entry, and sends the query there.
For domains, the lookup is often two-tiered. The registry response for a gTLD contains a related link to the registrar’s RDAP server, which may hold additional contact details. Well-behaved clients follow that link and merge both answers.
| Query path | Object returned | Typical authoritative server |
|---|---|---|
| `/domain/<name>` | Domain registration record | TLD registry, then registrar |
| `/ip/<address or prefix>` | IP network allocation | Regional internet registry |
| `/autnum/<number>` | Autonomous system record | Regional internet registry |
| `/nameserver/<name>` | Name server object | TLD registry |
| `/entity/<handle>` | Contact or organization | Registry or registrar |
| `/help` | Server capabilities and notices | Any RDAP server |
What an RDAP response contains
Every RDAP response follows a common JSON structure so that one client can read data from thousands of servers. A domain object carries the ldhName and, for internationalized names, the unicodeName, along with status values, events and entities.
| JSON member | Content | Practical use |
|---|---|---|
| `status` | Values such as client transfer prohibited | Shows locks and pending operations |
| `events` | Registration, expiration, last changed dates | Renewal tracking and domain age checks |
| `entities` | Registrar, registrant, abuse contacts with roles | Finding who to contact |
| `nameservers` | Delegated name server objects | Verifying DNS delegation |
| `secureDNS` | DS data and delegation signed flag | Checking DNSSEC chain setup |
| `notices` and `remarks` | Terms of use and redaction notes | Understanding data limits |
Contact information inside entities uses jCard, a JSON form of the vCard standard, and is moving toward the simpler JSContact format. Dates are in ISO 8601 with time zones, which removes the guesswork that plagued WHOIS parsers, where every registry formatted dates differently.
Because privacy rules such as the GDPR restrict personal data, many responses redact registrant details. A redaction extension lets servers state explicitly which fields were removed and why, instead of silently printing placeholders.
RDAP compared with WHOIS
RDAP was designed to fix the structural weaknesses of WHOIS rather than to change what registration data means. WHOIS runs over plain TCP port 43, returns unstructured text whose layout varies per registry, and has no notion of authentication, internationalization or standard error codes.
| Property | RDAP | WHOIS |
|---|---|---|
| Transport | HTTPS on port 443 | Plain TCP on port 43 |
| Response format | Standardized JSON | Free-form text per server |
| Server discovery | IANA bootstrap files | Hardcoded lists and referrals |
| Internationalization | Unicode names and contacts | Mostly ASCII, inconsistent |
| Access control | Differentiated access possible | Same answer for everyone |
| Errors | HTTP status codes | Ad hoc text messages |
| Status for gTLDs | Required service | Obligation ended in 2025 |
The most important conceptual difference is differentiated access. An RDAP server can return a redacted record to anonymous users and a fuller record to an authenticated requester with a legitimate purpose, for example a law enforcement agency or a trademark investigator, using standard HTTP authentication schemes.
Using RDAP in practice
RDAP is most useful wherever registration data must be processed by software. Security teams use it to check domain age in phishing analysis, operators use it to find the abuse contact of an IP range, and registrars and portfolio managers use it to monitor expiration dates and status locks.
- Command-line and library clients handle bootstrap discovery, registrar referrals and caching automatically.
- Direct HTTPS calls with any HTTP tool work well for quick checks, provided the correct server is known.
- Rate limits apply on most servers; a 429 status means the client must slow down and retry later.
- Caching bootstrap files for hours or days avoids unnecessary load, since they change infrequently.
The decision table below helps choose the right approach.
| Need | Recommended approach | Reason |
|---|---|---|
| One-off domain check | Web or command-line RDAP client | Handles discovery and referrals |
| Bulk monitoring of a portfolio | Library with caching and backoff | Respects rate limits |
| Abuse report for an IP | Query /ip/ and read the abuse entity | RIR data names the responsible network |
| Full registrant identity | Request authenticated access | Public responses are usually redacted |
Limitations and common misconceptions
RDAP does not create more data than WHOIS had. If a registry redacts the registrant, switching protocols will not reveal it. Many users expect RDAP to restore the detailed ownership records of the past, but its gain lies in structure and consistency, not disclosure.
Coverage is also uneven outside the gTLD space. Country-code registries are not bound by the same contracts, so some ccTLDs offer full RDAP, some partial service and a few none at all. Clients should handle a missing bootstrap entry gracefully and fall back to other sources where policy allows.
Finally, RDAP data is only as accurate as the registration behind it. Registrars verify some contact fields, but false or outdated data still exists, and a response describes registration, not who actually operates a website.
In plain words
Every website address is registered with someone, much like a car is registered with a licensing office. RDAP is the modern public lookup counter for that register. You ask about a domain name or an IP address, and it tells you which company registered it, when it was created and when it expires.
The older system, WHOIS, answered in loosely formatted text that each office wrote differently. RDAP answers in one consistent format that computers can read reliably, and it can show more details to people who prove they have a valid reason to see them.
A real-world example
A security analyst at a mid-sized retailer receives reports of an email that imitates the company’s login page and links to a lookalike domain. She runs an RDAP query for the domain and receives a JSON record whose events member shows a registration date only three days earlier, a strong phishing signal.
The same response lists the registrar entity with its abuse email and phone number, and the status member shows no locks. She also queries /ip/ for the hosting address and obtains the abuse contact of the hosting network from the regional registry.
Within an hour she files reports with both the registrar and the hosting provider, attaching the RDAP output as evidence. Because the data is structured, her team later adds an automated rule that flags any newly registered domain resembling the brand, using the same queries.