What is RDAP?
RDAP (Registration Data Access Protocol) is the modern, IETF-standardized protocol for accessing domain name registration data. Developed as the successor to WHOIS, RDAP provides structured, machine-readable responses in JSON format, making it significantly easier for developers to integrate domain lookup functionality into their applications.
Why RDAP Matters for Developers
If you've ever tried to parse WHOIS data, you know the pain. Each registrar formats their responses differently, uses inconsistent field names, and returns unstructured plain text that requires complex regex patterns to extract useful information. RDAP solves these problems with a standardized JSON schema that works consistently across all RDAP-compliant servers.
Key Technical Advantages
Structured JSON Responses: RDAP responses use the standardized JSON data model defined by RFC 9083. This gives clients a consistent structure to parse, although a service may omit or redact fields according to its access policy. RESTful Architecture: RDAP uses standard HTTP methods and status codes. A GET request returns domain information when the server finds a matching object. A 404 response means the queried object was not found at that service; it does not by itself prove that the domain can be registered. HTTPS by Default: Unlike WHOIS which transmits data in plain text over port 43, RDAP uses HTTPS, ensuring encrypted communication between your application and the RDAP server. Internationalization Support: RDAP properly handles IDN (Internationalized Domain Names) and Unicode characters, essential for global applications.How RDAP Works
When you query a domain through RDAP, the process follows these steps:
1. Bootstrap Discovery: Your client queries the IANA RDAP Bootstrap registry to find the authoritative RDAP server for the TLD
2. HTTP Request: A GET request is made to the RDAP server URL (e.g., https://rdap.verisign.com/com/v1/domain/example.com)
3. JSON Response: The server returns a structured JSON object containing registration data, status codes, and events
Example RDAP Response Structure
{
"objectClassName": "domain",
"handle": "example.com",
"ldhName": "example.com",
"status": ["client transfer prohibited"],
"events": [
{"eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z"},
{"eventAction": "expiration", "eventDate": "2025-08-13T04:00:00Z"}
]
}
RDAP vs WHOIS Comparison
| Feature | RDAP | WHOIS |
|---|---|---|
| Data Format | Structured JSON | Unstructured text |
| Transport | HTTPS (encrypted) | Plain text (port 43) |
| Standardization | RFC 9082 and RFC 9083 | Inconsistent |
| IDN Support | Native | Limited |
| Query Type | RESTful HTTP | Custom protocol |
Implementing RDAP in Your Applications
For developers building domain tools, RDAP is the recommended approach. Most modern domain availability checkers, including DomScan, use RDAP as their primary data source because it provides:
- Availability evidence: A 404 response means the queried RDAP server did not find a matching object. It does not by itself prove that the domain is available to register
- Rich metadata: Access to registration dates, expiration dates, and status codes
- Consistent parsing: One codebase handles all TLDs
RDAP Adoption Status
For gTLDs, ICANN says RDAP became the definitive source for registration information on 28 January 2025, and gTLD registries and registrars are no longer generally required to provide WHOIS services, with exceptions for .com, .name, and .post. ccTLD policies and RDAP adoption vary. The IANA Bootstrap file at https://data.iana.org/rdap/dns.json provides current RDAP server mappings for all supported TLDs.
Best Practices
When implementing RDAP queries, cache responses appropriately to respect rate limits, implement the IANA bootstrap for server discovery, and treat not-found, redirection, and policy-related error responses separately. A not-found response is evidence about the queried service, not proof of registrability.