WHOIS vs RDAP: Understanding the Protocol Transition for Domain Intelligence in 2026

For 40 years, WHOIS was the internet's domain registration database — a simple, unstructured query protocol that anyone could use to find who registered a domain. On January 28, 2025, ICANN officially replaced WHOIS with RDAP (Registration Data Access Protocol), marking the end of an era. Yet most security teams, investigators, and domain researchers still think of "WHOIS lookup" as their primary tool, not realizing the protocol they're using has fundamentally changed. In this guide, you'll learn exactly what the WHOIS-to-RDAP transition means for domain intelligence work, how the two protocols differ, why RDAP is technically superior, what data is actually available in each, and how to navigate a world where both protocols coexist during a long transition period.

## Key Takeaways

• ▸WHOIS is a 40-year-old unencrypted protocol that ran over TCP port 43 with inconsistent text formatting — it is now officially deprecated by ICANN in favor of RDAP as of January 28, 2025.
• ▸RDAP (Registration Data Access Protocol) is the new IETF standard that returns structured JSON over HTTPS — it provides consistent, parseable, encrypted domain registration data replacing WHOIS's fragile plaintext format.

• ▸RDAP is required for all generic top-level domains (gTLDs) as of January 2025, but country-code TLDs (ccTLDs) are not mandated by ICANN and many have not yet deployed RDAP servers.
• ▸Approximately 85% of gTLD registrations are covered by reliable RDAP endpoints as of 2026, while ccTLD coverage remains below 40% — meaning WHOIS fallback is still necessary for many TLDs.
• ▸Both protocols return redacted registrant data under GDPR and similar privacy regulations — the difference is not in privacy but in structure, encryption, and automation capability.
• ▸RDAP provides bootstrapping discovery via IANA — the protocol automatically identifies which server to query for each TLD, eliminating the need for hardcoded server lists.
• ▸For modern domain intelligence work, RDAP is universally superior — but practical tools still need WHOIS fallback capability for ccTLDs and legacy systems.

## What Is WHOIS and How Did It Work?

WHOIS is a 40-year-old query-response protocol that runs over unencrypted TCP connections on port 43, returning plaintext domain registration data in inconsistent formats determined by each registrar. It was designed in the early days of the internet when security concerns were minimal and no one anticipated billions of domains requiring centralized querying.

The WHOIS protocol was elegantly simple: connect to a registrar's WHOIS server on port 43, send a domain name in plaintext, and receive the registrant's name, email, phone, address, registrar details, name servers, and registration/expiry dates — all in plaintext, separated by newlines or tabs, with no standard formatting across different registrars.

The Structural Problems with WHOIS

The simplicity that made WHOIS accessible also made it fundamentally broken for modern use.

Unencrypted transmission. Every WHOIS query sent over port 43 was transmitted in plaintext over the internet. Anyone capturing network traffic could see which domains were being queried and what contact information was retrieved. No authentication, no encryption, no access controls — just raw data flowing across the network.

Inconsistent formatting. Each registrar returned data in their own format. Some used colons as delimiters, some used spaces, some used custom layouts. Automated parsing required fragile regex patterns that broke when registrars changed their output format. A script that worked for one registrar frequently failed for another.

No rate limiting. While ICANN recommended rate limits on WHOIS queries, enforcement was inconsistent or absent. Some registrars had aggressive rate limits; others had none. This made bulk domain intelligence collection unpredictable — a query that worked yesterday might be rate-limited today.

Poor scalability for automation. The plaintext format meant developers had to write regex parsers for each registrar's quirks. Bulk processing of domain data required complex conditional logic and error handling. Parsing was the hard part of WHOIS automation, not the querying.

Privacy redaction gradually eliminated the data. Starting around 2018, GDPR enforcement and similar privacy regulations led registrars to redact most registrant contact information from WHOIS responses. By 2024, most domains showed only redacted privacy proxy contacts, not the actual registrant. The protocol became less useful as privacy protection increased.

## What Is RDAP and Why Was It Created?

RDAP (Registration Data Access Protocol) is a modern HTTP-based protocol that returns structured JSON over HTTPS, designed to replace WHOIS with a standardized, secure, parseable, and scalable alternative. RDAP was standardized by the IETF (RFC 7480–7484) and mandated by ICANN for all gTLD registries starting January 28, 2025.

The core innovations of RDAP address WHOIS's fundamental limitations:

HTTPS encryption. All RDAP queries run over standard HTTPS (port 443), providing encryption, authentication, and the standard security properties expected of modern web protocols.

Structured JSON responses. Instead of plaintext with inconsistent formatting, RDAP returns structured JSON with well-defined fields. A domain query always returns the same fields in the same structure, regardless of which registry you're querying.

RESTful API design. RDAP uses standard HTTP methods and URLs. Querying a domain is as simple as GET https://rdap.registry.example/domain/example.com — familiar REST patterns instead of TCP port 43 connections.

Bootstrap discovery. ICANN maintains an authoritative IANA bootstrap file listing which RDAP server serves each TLD. Tools no longer need hardcoded lists of registrar servers — the bootstrap file provides the authoritative endpoint for each TLD.

Consistent rate limiting. While individual registries can implement rate limiting, RDAP's HTTP foundation means standard HTTP caching, load balancing, and rate-limiting mechanisms apply. Rate limits are predictable and uniform.

Links to related resources. RDAP responses include links to related resources — e.g., a domain response includes links to its registrant, registrar, and name server contacts. This enables follow-up queries without manual URL construction.

## WHOIS vs RDAP: Direct Protocol Comparison

The differences between WHOIS and RDAP span protocol design, data format, security, and operational characteristics.

Protocol Layer

WHOIS uses TCP on port 43 with plaintext commands and responses. Query: domain example.com. Response: plaintext data separated by newlines.

RDAP uses HTTP/HTTPS on standard web ports with RESTful URL patterns. Query: GET https://rdap.registry.tld/domain/example.com. Response: structured JSON.

The protocol difference is fundamental: WHOIS is a custom protocol designed in the 1980s. RDAP is built on HTTP, which provides encryption, authentication, caching, load balancing, and all the infrastructure security expects of modern web APIs.

Data Format

WHOIS returns plaintext in registrar-specific formats. The same data field might be labeled "Registrant Name:" on one registrar and "Owner:" on another. Developers parse using regex — fragile and registrar-specific.

RDAP returns JSON with standardized field names and nesting. The response for every domain, across every registry, includes the same top-level keys. No regex parsing necessary — deserialize the JSON and access fields programmatically.

Example RDAP response structure:

json

{ "domain": "example.com", "status": ["client transfer prohibited"], "registrar": { "name": "Example Registrar", "iana_id": "123" }, "dates": { "registered": "1997-09-15T04:00:00Z", "expires": "2028-09-14T04:00:00Z" }, "nameservers": ["ns1.example.com", "ns2.example.com"], "entities": { "registrant": { "organization": "Example Inc" } } }

The structure is flat and predictable. No conditional parsing logic. No registry-specific formatting.

Security and Encryption

WHOIS transmits all data in plaintext. Network captures reveal domain queries and all returned registrant data. No authentication. No access controls. No encryption.

RDAP transmits over HTTPS, providing encryption in transit. RDAP servers can require authentication for accessing sensitive data. Access controls can limit which queries require authentication vs. are publicly available.

For domain intelligence work, the encryption alone represents a massive security improvement — queries are no longer visible to passive network monitoring.

Scalability for Automation

WHOIS requires:

Connect to registrar's server (hard-coded list of 1000+ servers)

Send plaintext query

Parse response with registrar-specific regex

Handle inconsistent formatting errors

Deal with inconsistent rate limits

RDAP requires:

Look up TLD in IANA bootstrap file

Send HTTP GET request

Deserialize JSON

Access fields programmatically

Handle HTTP standard rate limiting (Retry-After headers, 429 responses)

The RDAP workflow is simpler, more predictable, and scales to bulk operations far more easily.

## Coverage: WHOIS vs RDAP in 2026

RDAP is mandatory for gTLDs (.com, .net, .org, .io, etc.), but ccTLDs (country-code top-level domains) are not mandated by ICANN and many have not deployed RDAP.

gTLD Coverage

As of 2026, approximately 85% of gTLD registrations are covered by reliable RDAP endpoints. All major registries (.com, .net, .org, .biz, .info, .cc, .tv, .co, .io, etc.) have deployed RDAP servers. Some registrars have incomplete implementations or data parity issues, but functional RDAP service is available.

WHOIS for gTLDs still works but is officially deprecated. ICANN has committed to eventual shutdown of WHOIS port 43 for gTLDs, though no hard deadline has been announced.

ccTLD Coverage

Country-code TLDs are not bound by ICANN's gTLD policies. Each ccTLD operates independently. Coverage is estimated at under 40% as of early 2026. Some major ccTLDs (.uk, .de, .fr, .jp, .cn) have deployed RDAP or committed to deployment. Many others have no RDAP server and no timeline to deploy one.

For ccTLDs without RDAP, WHOIS remains the only option.

Practical Implications

For any domain intelligence tool querying across all TLDs (not just gTLDs), WHOIS fallback is still required in 2026. Tools must:

Try RDAP first (faster, more reliable, encrypted)

Fall back to WHOIS for ccTLDs without RDAP

Handle mixed responses (some TLDs return RDAP, others return WHOIS)

The best practice is abstraction: use a unified API that handles protocol negotiation automatically, returning consistent output regardless of whether the response came from RDAP or WHOIS.

## Privacy and Registrant Data Redaction

Both WHOIS and RDAP return redacted registrant contact information for most domains registered after mid-2018 — this is not a protocol difference but a regulatory requirement.

GDPR (in EU) and similar privacy regulations worldwide require registrars to redact personal contact information from public registration records. This redaction applies to:

• ▸Registrant name
• ▸Registrant email
• ▸Registrant phone number
• ▸Registrant mailing address

The redaction is the same in both WHOIS and RDAP. A domain's WHOIS response and RDAP response will return identical registrant information — usually "Privacy Proxy Service" or similar placeholder.

For investigation purposes, this means reverse WHOIS queries based on newer domain registrations frequently yield no results if the registrant enabled privacy protection. Historical data pre-dating privacy regulation enforcement remains valuable for mapping older infrastructure.

## Querying WHOIS vs RDAP in Practice

WHOIS Query Example (Legacy)

bash

whois example.com

Returns plaintext data from the WHOIS server. Formatting varies by registrar. Manual parsing or regex required to extract structured data.

RDAP Query Example (Modern)

bash

curl https://rdap.icann.org/domain/example.com

Or via IANA bootstrap to find the authoritative server:

bash

# Bootstrap provides the endpoint for .com domains curl https://rdap.verisign.com/com/v1/domain/example.com

Returns structured JSON. Deserialize and access fields programmatically.

Using ReconShield's WHOIS Tool

ReconShield's WHOIS domain intelligence tool abstracts the protocol complexity entirely. The tool queries RDAP when available, falls back to WHOIS when necessary, and returns consistent structured output regardless of protocol:

json

{ "domain": "example.com", "registrar": "Example Registrar", "created": "1997-09-15", "expires": "2028-09-14", "nameservers": ["ns1.example.com", "ns2.example.com"], "status": "clientTransferProhibited" }

Same output format, works across all TLDs, handles protocol negotiation automatically.

## Building Domain Intelligence Tools in the RDAP Era

For organizations building domain intelligence workflows, the right approach is an abstraction layer that queries RDAP when available and falls back to WHOIS for unsupported TLDs.

Best Practices

Use RDAP as the default. RDAP is faster, more reliable, and more secure. Try RDAP queries first.

Maintain WHOIS fallback. Until all TLDs deploy RDAP (potentially years away), WHOIS fallback is essential. Not every domain can be queried via RDAP.

Normalize the output. Return consistent JSON regardless of protocol. Consumers of your API should not need to know whether data came from RDAP or WHOIS.

Handle bootstrap discovery. Use IANA's bootstrap file to map TLDs to RDAP endpoints. Don't hardcode server lists — bootstrap discovery is more reliable.

Implement standard rate limiting. Respect Retry-After headers from RDAP servers. Implement exponential backoff for rate-limited responses.

Cache results appropriately. RDAP responses are static (domain registration data doesn't change in real-time). Cache aggressively. WHOIS data can be stale, so refresh more frequently.

## Conclusion

WHOIS and RDAP represent the transition from a 1980s protocol designed for a simple internet to a modern web API designed for today's security, privacy, and automation requirements. RDAP is unambiguously superior from every technical perspective: encrypted, structured, standardized, scalable, and designed for automation.

However, the transition is incomplete in 2026. Many ccTLDs still use WHOIS only. Practical tools must support both protocols during the transition period, with RDAP as the default and WHOIS as the reliable fallback.

For domain investigators, security researchers, and teams building domain intelligence workflows, the key lesson is: understand both protocols, but default to tools and APIs that handle the protocol negotiation automatically. This insulates you from the complexity of protocol transitions while ensuring you have access to domain registration data across all TLDs.

Use ReconShield's WHOIS domain intelligence tool to query domain registration data — it handles the WHOIS-to-RDAP transition automatically, returning consistent structured output regardless of which protocol the registrar supports.

Written by Surendra Reddy Cybersecurity Researcher & Founder, ReconShield. Surendra is a cybersecurity engineer specializing in Open Source Intelligence (OSINT), exposure intelligence, and AI-driven threat analysis. He built ReconShield to democratize access to enterprise-grade infrastructure visibility tools and secure digital internet-facing assets.

Reviewed by ReconShield Editorial Team

Articles:
Microsoft Patch Tuesday June 2026: The Definitive Guide to Record 200+ Vulnerabilities and AI-Driven Bug Discovery

June 2026 Cybersecurity Review: Top Cyber Attacks, Data Breaches & Critical Vulnerabilities