WHOIS to RDAP Migration: Lessons from Monitoring 2,000+ Domains

October 15, 2025 • By haveibeenexpired team • 9 min read

Why upgrading from WHOIS to RDAP revealed more about domain monitoring than we expected

When you need to check if a domain is registered or when it expires, you probably think it's as simple as running a WHOIS query. But after monitoring 2,000+ domains across 180+ different TLDs, we learned that domain registration data is far more fragmented and inconsistent than anyone expects. This is the story of migrating from WHOIS to RDAP, and the surprising lessons about how registries around the world actually publish (or don't publish) expiration data.

The WHOIS Protocol: 40 Years of Legacy

WHOIS has been the internet's phonebook since 1982. The protocol evolved through RFC 812 (1982), RFC 954 (1985), and was standardized in RFC 3912 (2004). It's a simple text-based protocol that returns domain registration information. The beauty was its simplicity – send a domain name over TCP port 43, get back registration details.

A typical WHOIS record includes:

Registrant information: Domain owner name, organization, email, phone, and postal address
Administrative and technical contacts: Contact details for domain management
Registrar details: The company that registered the domain
Domain status: Active, locked, pending transfer, etc.
Critical dates: Domain creation date, expiration date, and last update timestamp
Name servers: DNS servers authoritative for the domain

This data made WHOIS invaluable for domain ownership verification, technical troubleshooting, and expiration monitoring.

But that simplicity came with significant problems:

Inconsistent Data Formats: Each registry returns data in its own format. There's no standard schema, even for simple data such as the expiration date – some registries use Expiry Date:, others use Expiration Date:, expires:, Domain expires:, or validity:.

Rate Limiting: Registries aggressively rate-limit WHOIS queries to prevent abuse, making bulk monitoring challenging or impossible.

No Machine-Readable Structure: WHOIS returns plain text meant for human consumption, not structured data for automated systems.

Privacy Redaction: GDPR and privacy regulations led to aggressive redaction of WHOIS data, sometimes removing fields entirely including expiration dates.

Enter RDAP: The Modern Replacement

The Registration Data Access Protocol (RDAP), standardized in RFCs 7480-7484 (2015), was designed to replace WHOIS with a modern, standardized approach:

JSON-based responses: Machine-readable structured data
Standardized schemas: Consistent field names across registries
Better rate limiting: More sophisticated quota systems
Built-in authentication: Support for authenticated queries when needed
Internationalization: Native support for Unicode and non-ASCII domains

As of 2025, ICANN requires all gTLD registries to support RDAP. It should be the perfect solution.

The Reality: Migrating 2,000+ Domains from WHOIS to RDAP

When we began migrating our domain monitoring infrastructure from WHOIS to RDAP, we expected a straightforward upgrade. Instead, we discovered a complex landscape of registry behaviors that challenged every assumption.

Discovery #1: Some TLDs Don't Publish Expiration Dates By Design

This was the biggest surprise. After analyzing failures across our monitored domains, we discovered that nearly one-third of top-level domains simply don't publish expiration dates via WHOIS or RDAP:

Country Code TLDs That Don't Publish Expiration:

.uk and all subdomains (.co.uk, .sch.uk, etc.) - Managed by Nominet
.nl - Managed by SIDN
.kz - Kazakhstan registry
.ch - Swiss registry (actively blocks automated queries)
.eu - European Union registry

Why This Happens: These registries made policy decisions not to publish expiration dates publicly, often citing privacy concerns or business model reasons. For .uk domains, Nominet only provides creation and modification dates. The .ch registry goes further, explicitly blocking automated WHOIS queries with "Requests of this client are not permitted."

Real-World Impact: If your organization has significant presence in Europe or uses .uk domains heavily, you cannot rely on WHOIS/RDAP for expiration monitoring. You need alternative notification systems directly from your registrar.

Discovery #2: RDAP Works 67% of the Time, WHOIS Still Required

After implementing RDAP as our primary lookup method with WHOIS fallback, we analyzed success rates:

RDAP Success Rate: 67%

Fully structured data
Proper date parsing
Standard field names
Fast response times

WHOIS Fallback Required: 33%

RDAP not implemented for TLD
RDAP returns incomplete data
Registry-specific quirks
Non-standard TLD configurations

Why RDAP Isn't Universal Yet:

The gap in RDAP adoption comes down to governance and economics:

Country Code TLDs Not Mandated: ICANN's RDAP requirement only applies to generic TLDs (.com, .org, .net, etc.). Country code TLDs (.uk, .de, .jp, etc.) are governed by their respective national registries with independent policies. Many ccTLD operators see no compelling reason to invest in RDAP implementation.
Legacy Infrastructure Costs: Implementing RDAP requires significant engineering resources. Registries running stable WHOIS systems for decades face the challenge of building parallel RDAP infrastructure while maintaining backward compatibility. For smaller national registries with limited budgets, this is a substantial undertaking.
Fragmented Governance: Unlike gTLDs which fall under ICANN's centralized governance, ccTLDs operate under diverse governance models – some governmental, some private, some academic. This fragmentation means no single authority can mandate RDAP adoption across all TLDs.

This 67/33 split means any production domain monitoring system must implement both protocols. RDAP alone is not sufficient.

Discovery #3: Data Format Variations Are Worse Than Expected

Even with RDAP's standardization, WHOIS implementations exhibit extreme field name variations. Beyond the inconsistent field names mentioned earlier, the date and timestamp formats are scattered across WHOIS implementations with no standardization:

ISO 8601: 2026-03-13T19:54:07Z
With timezone: 2026-03-13 21:54:07+02
European format: 13-03-2026
US format: 03-13-2026
Numeric: 20260313
Hybrid: before Aug-1996

Our date parser handles 7 different format patterns, and we still encounter edge cases.

Discovery #4: Some TLDs Require Manual WHOIS Server Hints

This was the most unexpected discovery: some TLD registries require you to specify the correct WHOIS server manually, as automatic server discovery fails.

The Problem: Automatic WHOIS server discovery uses the domain's top-level extension to determine which WHOIS server to query. For second-level or regional TLDs like .co.ua and .spb.ru, this discovery fails because default RDAP/WHOIS requests route to the global .ua or .ru registry, which don't manage these regional subdomains. The global registries reject these queries, but provide no indication of which WHOIS server actually manages these domains.

The Solution: Manually specify the correct WHOIS server for problematic domains. For .co.ua domains, the correct WHOIS server is whois.co.ua. For .spb.ru domains, it's whois.nic.ru. Users must discover and configure these WHOIS server hints on a per-TLD basis.

The only sustainable solution is maintaining a manual mapping of problematic TLDs to their correct WHOIS servers.

The Hybrid Solution: RDAP-First with Intelligent Fallback

After encountering these challenges, we implemented a layered approach:

Layer 1: RDAP Primary Lookup

Attempt RDAP query first for fast, structured, standardized data
Extract expiration and creation dates when available

Layer 2: WHOIS Fallback with Flexible Parsing

When RDAP fails or returns incomplete data, fall back to WHOIS
Try standard field names first (Expiry Date, Domain expires, validity, etc.)
Use fuzzy matching to find any field ending with "expires" to handle variations
Apply flexible date parsing to handle multiple timestamp formats

This layered approach achieves a 94% success rate for domains with expiration data—a significant improvement from the 67% success rate of RDAP alone.

Lessons for Production Domain Monitoring

After migrating 2,000+ domains through this process, here are the critical lessons:

1. Implement Both RDAP and WHOIS

RDAP alone covers 67% of cases. You need WHOIS fallback for the remaining 33%. Any monitoring system that depends solely on RDAP will fail on significant portions of your domain portfolio.

2. Accept That Some Domains Can't Be Monitored via Registry Data

For domains under .uk, .nl, .ch, .kz, and other TLDs that don't publish expiration dates, you cannot monitor expiration via WHOIS/RDAP. Alternative approaches are required:

Registrar notifications: Enable automatic renewal warnings from your registrar
Manual tracking: Maintain separate spreadsheets for these domains
Business process: Make expiration dates part of procurement/renewal workflows

3. Build TLD-Specific Logic for Edge Cases

Maintain a list of problematic TLDs and their WHOIS server hints:

const WHOIS_HINTS = {
  'co.ua': 'whois.co.ua',
  'spb.ru': 'whois.nic.ru'
  // there are surely others!
};

Build configuration systems that allow per-domain overrides when automatic discovery fails.

4. Implement Flexible Field Parsing

Don't rely on exact field name matches. Implement fuzzy matching for common patterns:

Keys ending with "expires", "expiry", "expiration"
Keys ending with "created", "registered"
Keys containing "status" for domain state

This catches 95% of variations without maintaining hundreds of regex patterns.

5. Plan for Registry Outages and Rate Limits

Both RDAP and WHOIS servers experience:

Scheduled maintenance windows
Aggressive rate limiting (especially WHOIS)
Geographic blocking
Temporary outages

Implement:

Exponential backoff for retries
Caching of successful responses (1 hour TTL minimum)
Stale-but-valid data preservation: Keep last known expiration date even if current query fails
Rate limit awareness: Spread queries across time, respect registry limits

6. Monitor Your Monitoring

Track metrics on your domain monitoring:

RDAP success rate by TLD
WHOIS fallback frequency
Unmonitorable domain percentage
Query latencies by registry

This reveals which registries are problematic and helps prioritize WHOIS hint configurations.

The Future: RDAP Adoption Is Accelerating

Despite current challenges, RDAP adoption is improving:

Generic TLD Progress:

2023: 45% of gTLDs support RDAP
2024: 67% of gTLDs support RDAP
2025: ICANN mandates RDAP for all new gTLDs

Country Code TLD Progress:

.de (Germany): Fully migrated to RDAP in 2024
.fr (France) and .jp (Japan): RDAP deployment in progress

However, the core challenge remains: registries that don't publish expiration dates won't change this policy even with RDAP. The .uk registry's policy decision isn't technical – it's business and privacy policy that RDAP can't solve.

Conclusion: Embrace the Complexity

Domain registration data is far messier than it should be. After 40 years of WHOIS and a decade of RDAP development, we still face:

TLDs not publishing expiration dates
Inconsistent field naming even with RDAP standardization
Registry-specific quirks requiring manual WHOIS server hints
Fundamental differences between country code TLDs and generic TLDs

The solution isn't to wait for perfect standardization – it won't come. Instead:

Accept the hybrid reality: Implement both RDAP and WHOIS, with intelligent fallback logic and TLD-specific handling.

Communicate limitations clearly: Tell users which domains can't be monitored and why. Don't fail silently.

Build flexible parsers: Use fuzzy field matching rather than rigid schemas. The variations will surprise you.

Preserve stale data: When a query fails but you have previous successful data, use it. Temporary registry outages shouldn't erase known expiration dates.

Learn from scale: Every 1,000 domains monitored reveals new edge cases. Build systems that adapt rather than systems that assume uniformity.

The internet's domain registration infrastructure is a patchwork of 180+ registries, each with unique behaviors, policies, and technical implementations. Production-grade domain monitoring embraces this complexity rather than fighting it.

Building production domain monitoring across global TLD infrastructure? We learned these lessons by monitoring 2,000+ domains across 180+ TLDs. Our hybrid RDAP+WHOIS approach with intelligent fallback achieves 94% success rates while gracefully handling domains that can't be monitored via registry data. Stop fighting the inconsistency – build systems that embrace it.