domaindetails.com
Knowledge Base/Technical Guides/RDAP Explained: The Modern WHOIS Replacement (2025)
Technical Guides

RDAP Explained: The Modern WHOIS Replacement (2025)

Learn what RDAP is, how it differs from WHOIS, and why it's the new standard for domain registration data. Complete guide to the Registration Data Access Protocol.

14 min
Published 2025-12-01
Updated 2025-12-01
By DomainDetails Team

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

  1. You make a request: Send an HTTPS GET request to an RDAP server
  2. Server processes: The RDAP server looks up the registration data
  3. JSON response: Server returns standardized JSON with the data
  4. 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:

  • .com domains → Query https://rdap.verisign.com/com/v1/
  • .org domains → Query https://rdap.publicinterestregistry.org/rdap/
  • .io domains → Query https://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.com
  • https://rdap.org/domain/wikipedia.org
  • https://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 active
  • client transfer prohibited - Registrar has locked transfers
  • server transfer prohibited - Registry has locked transfers
  • client delete prohibited - Cannot be deleted
  • pending delete - Scheduled for deletion
  • redemption 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

  1. Get the bootstrap file:
curl -s "https://data.iana.org/rdap/dns.json" | jq .
  1. Find your TLD in the services array
  2. 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:

  1. Update your WHOIS code: Migrate to RDAP APIs for more reliable data
  2. Learn the response format: RDAP Query Format (RFC 7482)
  3. Implement proper caching: Respect rate limits and cache responses

If You're Researching Domains:

  1. Use modern lookup tools: DomainDetails uses RDAP for all queries
  2. Understand the data: Learn what information is public vs. redacted
  3. Monitor domains effectively: Track changes to registration data over time

Research Sources

This article was researched using current information from authoritative sources: