RDAP

On this page 7

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 pathObject returnedTypical authoritative server
`/domain/<name>`Domain registration recordTLD registry, then registrar
`/ip/<address or prefix>`IP network allocationRegional internet registry
`/autnum/<number>`Autonomous system recordRegional internet registry
`/nameserver/<name>`Name server objectTLD registry
`/entity/<handle>`Contact or organizationRegistry or registrar
`/help`Server capabilities and noticesAny RDAP server
Main RDAP query types

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 memberContentPractical use
`status`Values such as client transfer prohibitedShows locks and pending operations
`events`Registration, expiration, last changed datesRenewal tracking and domain age checks
`entities`Registrar, registrant, abuse contacts with rolesFinding who to contact
`nameservers`Delegated name server objectsVerifying DNS delegation
`secureDNS`DS data and delegation signed flagChecking DNSSEC chain setup
`notices` and `remarks`Terms of use and redaction notesUnderstanding data limits
Key members of a domain response

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.

PropertyRDAPWHOIS
TransportHTTPS on port 443Plain TCP on port 43
Response formatStandardized JSONFree-form text per server
Server discoveryIANA bootstrap filesHardcoded lists and referrals
InternationalizationUnicode names and contactsMostly ASCII, inconsistent
Access controlDifferentiated access possibleSame answer for everyone
ErrorsHTTP status codesAd hoc text messages
Status for gTLDsRequired serviceObligation ended in 2025
RDAP and WHOIS side by side

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.

NeedRecommended approachReason
One-off domain checkWeb or command-line RDAP clientHandles discovery and referrals
Bulk monitoring of a portfolioLibrary with caching and backoffRespects rate limits
Abuse report for an IPQuery /ip/ and read the abuse entityRIR data names the responsible network
Full registrant identityRequest authenticated accessPublic responses are usually redacted
Choosing an RDAP approach

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.