Quick Answer
RDAP (Registration Data Access Protocol) is the modern replacement for WHOIS, officially becoming the standard for accessing domain registration data on January 28, 2025. Unlike WHOIS's plain-text format over port 43, RDAP uses RESTful APIs with standardized JSON responses over HTTPS. RDAP provides better security, internationalization support, and GDPR-compliant access controls—letting registries provide different data based on who's asking. If you've been using WHOIS, the switch to RDAP is mostly transparent, but understanding the differences helps you access registration data more effectively.
Table of Contents
What is RDAP?
RDAP stands for Registration Data Access Protocol. It's a standardized protocol for querying registration data about domain names, IP addresses, and autonomous system numbers (ASNs).
The Simple Explanation
Think of RDAP as the next-generation "phone book" for the internet. When you want to know who owns a domain, when it was registered, or which nameservers it uses, RDAP is the system that provides this information.
Before RDAP, everyone used WHOIS—a protocol created in 1982 when the internet was a much simpler place. WHOIS served its purpose for over 40 years, but its limitations became increasingly problematic as the internet evolved.
What RDAP Provides
When you query RDAP for a domain, you can receive:
- Domain registration status (active, pending delete, etc.)
- Creation, expiration, and last-modified dates
- Registrar information (who manages the domain)
- Nameserver details
- Contact information (when permitted by privacy regulations)
- EPP status codes (transfer locks, etc.)
- DNSSEC information
Who Created RDAP?
RDAP was developed by the Internet Engineering Task Force (IETF) through a series of RFCs (Request for Comments documents) published between 2015 and 2019:
- RFC 7480 - HTTP usage for RDAP queries
- RFC 7481 - Security services for RDAP
- RFC 7482 - RDAP query format
- RFC 7483 - JSON responses for RDAP
- RFC 7484 - Finding the right RDAP server
ICANN (Internet Corporation for Assigned Names and Numbers) mandated RDAP adoption for all generic top-level domains (gTLDs), leading to the official sunset of WHOIS in January 2025.
Why Was RDAP Created?
WHOIS worked fine in 1982 when there were only a few hundred computers on the internet. But the modern internet has over 350 million domain names, operates across 200+ countries, and must comply with privacy regulations like GDPR. WHOIS simply couldn't keep up.
WHOIS Limitations
1. No Standard Format
Every WHOIS server returned data in its own format. A query to Verisign's WHOIS looked completely different from GoDaddy's WHOIS. This made parsing and automating WHOIS data extremely difficult.
# Example: Different WHOIS formats
# Verisign format:
Domain Name: EXAMPLE.COM
Registry Domain ID: 2336799_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.registrar.com
# Different registrar format:
domain: example.com
registrant: John Doe
created: 1997-09-15
2. No Security
WHOIS transmitted everything in plain text over port 43. No encryption, no authentication, no verification. Anyone could intercept WHOIS queries or spoof responses.
3. No Access Control
WHOIS was all-or-nothing. Either everyone saw all the data, or no one saw it. There was no way to provide more information to legitimate requesters (like law enforcement) while protecting registrant privacy from random queries.
4. No Internationalization
WHOIS was designed for ASCII text only. Domain names and contact information using non-Latin characters (Chinese, Arabic, Cyrillic, etc.) couldn't be properly represented.
5. Privacy Regulation Conflicts
When GDPR went into effect in 2018, WHOIS had no mechanism to comply. The protocol simply couldn't distinguish between queries that should receive full data versus redacted data. This led to a messy period where different registrars handled GDPR differently.
RDAP Solutions
RDAP was designed from the ground up to solve these problems:
| WHOIS Problem | RDAP Solution |
|---|---|
| Inconsistent format | Standardized JSON responses |
| No encryption | HTTPS required |
| No access control | Differentiated access based on requestor |
| ASCII only | Full Unicode/internationalization support |
| Privacy conflicts | Built-in data redaction mechanisms |
RDAP vs WHOIS: Key Differences
At a Glance
| Feature | WHOIS | RDAP |
|---|---|---|
| Protocol | Port 43, plain text | HTTPS, RESTful API |
| Data Format | Unstructured text | Structured JSON |
| Security | None | TLS encryption |
| Authentication | None | Supports OAuth, API keys |
| Access Control | All-or-nothing | Differentiated access levels |
| Internationalization | ASCII only | Full Unicode support |
| Error Handling | Inconsistent | Standard HTTP status codes |
| Service Discovery | Manual lookup | Bootstrap file auto-discovery |
Detailed Comparison
Data Format
WHOIS returns free-form text that varies by server:
Domain Name: EXAMPLE.COM
Registrar: Example Registrar, Inc.
Creation Date: 1997-09-15T04:00:00Z
Registry Expiry Date: 2025-09-14T04:00:00Z
RDAP returns standardized JSON:
{
"objectClassName": "domain",
"handle": "EXAMPLE-VRSN",
"ldhName": "example.com",
"events": [
{
"eventAction": "registration",
"eventDate": "1997-09-15T04:00:00Z"
},
{
"eventAction": "expiration",
"eventDate": "2025-09-14T04:00:00Z"
}
]
}
Security
WHOIS: Any data transmitted can be intercepted. Man-in-the-middle attacks are trivial. Responses can be spoofed.
RDAP: All communication is encrypted via TLS. Server certificates can be verified. Data integrity is ensured.
Access Control
WHOIS: Everyone gets the same data (or no data if privacy-protected).
RDAP: Different access levels are possible:
- Anonymous users: Basic domain info (status, dates, nameservers)
- Authenticated users: More details based on legitimate interest
- Law enforcement: Full contact information through proper channels
Internationalization
WHOIS: Cannot properly represent domain names like 例え.jp or contact information in non-Latin scripts.
RDAP: Full Unicode support allows proper representation of internationalized domain names (IDNs) and contact data in any language.
How RDAP Works
The Query Process
- You make a request: Send an HTTPS GET request to an RDAP server
- Server processes: The RDAP server looks up the registration data
- JSON response: Server returns standardized JSON with the data
- Access control applied: Response may be filtered based on your access level
Finding the Right RDAP Server
Unlike WHOIS where you needed to know which server to query, RDAP uses a bootstrap file maintained by IANA that maps domain extensions to their RDAP servers.
Bootstrap file location: https://data.iana.org/rdap/dns.json
This file tells you:
.comdomains → Queryhttps://rdap.verisign.com/com/v1/.orgdomains → Queryhttps://rdap.publicinterestregistry.org/rdap/.iodomains → Queryhttps://rdap.nic.io/
Query URL Structure
RDAP queries follow a simple URL pattern:
https://{rdap-server}/domain/{domain-name}
Examples:
https://rdap.verisign.com/com/v1/domain/example.comhttps://rdap.org/domain/wikipedia.orghttps://rdap.nic.io/domain/github.io
Other RDAP Query Types
Beyond domains, RDAP can query:
- IP addresses:
/ip/{ip-address} - ASNs:
/autnum/{asn} - Nameservers:
/nameserver/{nameserver} - Entities:
/entity/{handle}
RDAP Response Structure
RDAP responses follow a well-defined JSON structure. Here's what a typical domain query returns:
Example Response
{
"objectClassName": "domain",
"handle": "2336799_DOMAIN_COM-VRSN",
"ldhName": "example.com",
"status": ["client delete prohibited", "client transfer prohibited"],
"events": [
{
"eventAction": "registration",
"eventDate": "1995-08-14T04:00:00Z"
},
{
"eventAction": "expiration",
"eventDate": "2025-08-13T04:00:00Z"
},
{
"eventAction": "last changed",
"eventDate": "2024-08-14T07:01:44Z"
}
],
"nameservers": [
{
"objectClassName": "nameserver",
"ldhName": "a.iana-servers.net"
},
{
"objectClassName": "nameserver",
"ldhName": "b.iana-servers.net"
}
],
"entities": [
{
"objectClassName": "entity",
"roles": ["registrar"],
"publicIds": [
{
"type": "IANA Registrar ID",
"identifier": "376"
}
],
"vcardArray": [
"vcard",
[
["fn", {}, "text", "Example Registrar, Inc."]
]
]
}
],
"links": [
{
"rel": "self",
"href": "https://rdap.verisign.com/com/v1/domain/example.com",
"type": "application/rdap+json"
}
]
}
Key Response Fields
| Field | Description |
|---|---|
objectClassName |
Type of object (domain, nameserver, entity) |
handle |
Unique identifier in the registry |
ldhName |
Domain name in LDH (letter-digit-hyphen) format |
unicodeName |
Internationalized domain name (if applicable) |
status |
Array of EPP status codes |
events |
Registration, expiration, and update dates |
nameservers |
DNS servers for the domain |
entities |
Registrar and contact information |
secureDNS |
DNSSEC configuration |
links |
Related RDAP resources |
notices |
Terms of use, disclaimers |
Understanding Status Codes
The status array contains EPP (Extensible Provisioning Protocol) status codes:
active- Domain is registered and activeclient transfer prohibited- Registrar has locked transfersserver transfer prohibited- Registry has locked transfersclient delete prohibited- Cannot be deletedpending delete- Scheduled for deletionredemption period- In redemption after expiration
The WHOIS Sunset Timeline
Official Timeline
January 28, 2025: RDAP became the official, required protocol for accessing gTLD registration data. WHOIS is officially "sunset" for generic top-level domains under ICANN's authority.
What "Sunset" Means
- WHOIS isn't immediately disappearing: Many registries and registrars continue operating WHOIS servers for backward compatibility
- RDAP is now required: All ICANN-accredited registries must provide RDAP services
- New features are RDAP-only: Any new registration data access features will only be available via RDAP
- Legacy support varies: Some providers may maintain WHOIS indefinitely, others may phase it out
Country Code TLDs (ccTLDs)
Country code TLDs like .uk, .de, .ca, and .au are not under ICANN's direct authority. Their RDAP adoption varies:
- Many have already implemented RDAP
- Some continue with WHOIS only
- Adoption is ongoing but not mandated by ICANN
What This Means for You
For casual users: Most lookup tools (including DomainDetails) have already switched to RDAP behind the scenes. You may not notice any difference.
For developers: Update your code to use RDAP APIs. WHOIS parsing will become increasingly unreliable as servers are deprecated.
For domain professionals: RDAP provides more reliable, structured data for domain research and monitoring.
How to Use RDAP
Web-Based Lookups
The easiest way to use RDAP is through web tools that handle the protocol for you:
- ICANN Lookup: https://lookup.icann.org
- DomainDetails: Our tool uses RDAP for all domain lookups
- Registrar tools: Most registrars offer RDAP-powered lookup tools
Command Line
You can query RDAP directly using curl:
# Query a .com domain
curl -s "https://rdap.verisign.com/com/v1/domain/google.com" | jq .
# Query a .org domain
curl -s "https://rdap.publicinterestregistry.org/rdap/domain/wikipedia.org" | jq .
# Query an IP address (from ARIN)
curl -s "https://rdap.arin.net/registry/ip/8.8.8.8" | jq .
Finding the Correct RDAP Server
- Get the bootstrap file:
curl -s "https://data.iana.org/rdap/dns.json" | jq .
- Find your TLD in the
servicesarray - Use the corresponding RDAP base URL
Or use RDAP.org which handles this automatically:
curl -s "https://rdap.org/domain/example.com" | jq .
RDAP for Developers
Making RDAP Queries
Basic HTTP Request
// JavaScript example
async function queryRDAP(domain) {
// For .com domains
const response = await fetch(
`https://rdap.verisign.com/com/v1/domain/${domain}`
);
if (!response.ok) {
if (response.status === 404) {
return { available: true };
}
throw new Error(`RDAP query failed: ${response.status}`);
}
return await response.json();
}
// Usage
const data = await queryRDAP('example.com');
console.log(data.events); // Registration dates
console.log(data.nameservers); // DNS servers
Python Example
import requests
def query_rdap(domain: str) -> dict:
"""Query RDAP for domain information."""
# Use rdap.org for automatic server discovery
url = f"https://rdap.org/domain/{domain}"
response = requests.get(url, headers={
"Accept": "application/rdap+json"
})
if response.status_code == 404:
return {"available": True}
response.raise_for_status()
return response.json()
# Usage
data = query_rdap("example.com")
print(f"Registered: {data['events'][0]['eventDate']}")
Handling RDAP Responses
Extracting Common Fields
function parseRDAPResponse(data) {
return {
domain: data.ldhName,
status: data.status || [],
// Extract dates from events
registered: data.events?.find(e => e.eventAction === 'registration')?.eventDate,
expires: data.events?.find(e => e.eventAction === 'expiration')?.eventDate,
updated: data.events?.find(e => e.eventAction === 'last changed')?.eventDate,
// Extract nameservers
nameservers: data.nameservers?.map(ns => ns.ldhName) || [],
// Extract registrar
registrar: data.entities?.find(e => e.roles?.includes('registrar'))
?.vcardArray?.[1]?.find(v => v[0] === 'fn')?.[3]
};
}
Rate Limiting
RDAP servers implement rate limiting. Typical limits:
- Verisign (.com, .net): ~2 queries per second
- PIR (.org): ~1-2 queries per second
- Other registries: Varies
Best practices:
- Implement exponential backoff
- Cache responses (respect cache headers)
- Use bulk APIs if available for multiple queries
Error Handling
RDAP uses standard HTTP status codes:
| Code | Meaning |
|---|---|
| 200 | Success |
| 404 | Domain not found (available) |
| 400 | Bad request (malformed query) |
| 429 | Rate limited |
| 500 | Server error |
RDAP and Privacy
How RDAP Handles GDPR
RDAP was designed with privacy regulations in mind. Key features:
1. Differentiated Access
RDAP can provide different data to different requesters:
- Public: Domain status, dates, nameservers, registrar
- Verified: May include some contact information
- Authorized: Full registration data (law enforcement, trademark holders)
2. Redaction Notices
When data is redacted, RDAP responses include notices explaining what was removed and why:
{
"remarks": [
{
"title": "REDACTED FOR PRIVACY",
"description": [
"Personal data redacted in accordance with GDPR.",
"Contact the registrar for legitimate access requests."
]
}
]
}
3. Registrar Contact Methods
Instead of exposing registrant email addresses, RDAP responses can include:
- Web form URLs for contacting registrants
- Anonymized email addresses
- Registrar abuse contact information
What Data is Typically Public
Even with privacy protections, RDAP usually provides:
- Domain name and status
- Registration and expiration dates
- Nameservers
- Registrar name and IANA ID
- DNSSEC information
What Data is Typically Redacted
Under GDPR and similar regulations:
- Registrant name
- Registrant address
- Registrant phone number
- Registrant email (or anonymized)
- Technical contact details
- Admin contact details
Common RDAP Use Cases
1. Domain Availability Checking
Check if a domain is registered:
async function isDomainAvailable(domain) {
try {
await fetch(`https://rdap.org/domain/${domain}`);
return false; // Domain exists
} catch (error) {
if (error.status === 404) {
return true; // Domain available
}
throw error;
}
}
2. Expiration Monitoring
Track when domains expire for investment opportunities or renewal reminders:
function getExpirationDate(rdapData) {
const expirationEvent = rdapData.events?.find(
e => e.eventAction === 'expiration'
);
return expirationEvent ? new Date(expirationEvent.eventDate) : null;
}
3. Nameserver Tracking
Monitor nameserver changes for security or competitive intelligence:
function getNameservers(rdapData) {
return rdapData.nameservers?.map(ns => ns.ldhName.toLowerCase()) || [];
}
4. Registrar Identification
Identify which registrar manages a domain:
function getRegistrar(rdapData) {
const registrar = rdapData.entities?.find(
e => e.roles?.includes('registrar')
);
return registrar?.vcardArray?.[1]?.find(v => v[0] === 'fn')?.[3];
}
5. Transfer Lock Status
Check if a domain can be transferred:
function canTransfer(rdapData) {
const lockStatuses = [
'client transfer prohibited',
'server transfer prohibited'
];
return !rdapData.status?.some(s => lockStatuses.includes(s.toLowerCase()));
}
Frequently Asked Questions
Is WHOIS going away completely?
Not immediately. While RDAP is now the official standard for gTLDs, many registries and registrars continue operating WHOIS servers for backward compatibility. However, WHOIS will receive no new features and may be gradually deprecated. New applications should use RDAP.
Do I need to change how I look up domains?
For most users, no. Domain lookup tools like DomainDetails, ICANN Lookup, and registrar websites have already transitioned to RDAP behind the scenes. You'll get the same information through a familiar interface.
Is RDAP data more or less private than WHOIS?
RDAP is more privacy-friendly by design. It supports differentiated access, allowing registries to provide different data levels to different requesters. Public RDAP queries typically show the same information as GDPR-compliant WHOIS, but RDAP's structure makes privacy compliance easier to implement consistently.
Can I still use command-line WHOIS?
For now, yes. The whois command still works for many domains. However, RDAP provides more reliable, structured data. You can query RDAP from the command line using curl and parse JSON responses with jq.
How do I know which RDAP server to query?
Use the IANA bootstrap file at https://data.iana.org/rdap/dns.json or query through https://rdap.org which handles server discovery automatically.
Does RDAP work for all domain extensions?
RDAP is required for all gTLDs (.com, .org, .net, new gTLDs). Country code TLDs (ccTLDs) like .uk, .de, .ca have varying RDAP support—many have implemented it, but it's not universally mandated. Check the specific registry for ccTLD RDAP availability.
Is RDAP faster than WHOIS?
Generally yes. RDAP uses efficient HTTP/2 connections and JSON responses that are faster to parse than WHOIS text parsing. Connection reuse and modern web infrastructure make RDAP queries typically faster.
Can I use RDAP for bulk domain lookups?
Yes, but respect rate limits. Most RDAP servers limit queries to 1-2 per second. For bulk operations, implement rate limiting, caching, and exponential backoff. Some registries offer bulk data access programs for legitimate needs.
What happens if an RDAP server is down?
Unlike WHOIS where you might have no fallback, RDAP's structured approach makes it easier to implement redundancy. Some TLDs have multiple RDAP servers. The bootstrap file is updated if server locations change.
How does RDAP handle internationalized domain names (IDNs)?
RDAP fully supports Unicode. Responses include both the ASCII-compatible encoding (in ldhName) and the Unicode version (in unicodeName) for internationalized domains. Contact information can also use non-ASCII characters.
Key Takeaways
-
RDAP replaces WHOIS as the standard protocol for domain registration data, officially as of January 28, 2025
-
Key improvements: Standardized JSON format, HTTPS encryption, access control, and full internationalization support
-
For users: Most lookup tools have already transitioned to RDAP—you may not notice any difference in your daily workflow
-
For developers: Update your code to use RDAP APIs for more reliable, structured data; WHOIS parsing will become increasingly unreliable
-
Privacy-friendly: RDAP was designed with GDPR compliance in mind, supporting differentiated access levels
-
Server discovery: Use the IANA bootstrap file or rdap.org for automatic server routing
-
Rate limits apply: Implement proper rate limiting and caching when making programmatic queries
-
ccTLDs vary: Country code TLDs have varying RDAP adoption; check specific registries for support
Next Steps
Now that you understand RDAP, here's what to do next:
If You're a Developer:
- Update your WHOIS code: Migrate to RDAP APIs for more reliable data
- Learn the response format: RDAP Query Format (RFC 7482)
- Implement proper caching: Respect rate limits and cache responses
If You're Researching Domains:
- Use modern lookup tools: DomainDetails uses RDAP for all queries
- Understand the data: Learn what information is public vs. redacted
- Monitor domains effectively: Track changes to registration data over time
Related Articles:
- What is DNS? Domain Name System Explained
- Domain Privacy Protection: Complete Guide
- WHOIS Privacy After GDPR: What Changed?
- How Do Domain Names Work?
Research Sources
This article was researched using current information from authoritative sources: