WHOIS vs RDAP
WHOIS and RDAP both provide domain registration data, but RDAP is the modern standard with structured JSON responses, authentication support, and better internationalization. This guide compares the two protocols and offers practical guidance on when to use each.
3 min read
What they share#
Both WHOIS and RDAP serve the same fundamental purpose, querying registration data for domain names, IP addresses, and autonomous system numbers. Both return information about registrants, registrars, registration dates, name servers, and status codes. For many routine lookups, the data returned from either protocol is substantively identical.
Protocol differences#
| Aspect | WHOIS | RDAP |
|---|---|---|
| Transport | TCP port 43 | HTTP/HTTPS |
| Response format | Freeform text | Structured JSON |
| Discovery | Manual server lookup | IANA bootstrap registry |
| Authentication | None | HTTP-based (OAuth, API keys) |
| Internationalization | Limited | Native Unicode support |
| Referencing | None | Links to related objects |
WHOIS sends a plain-text query and receives a plain-text response with no defined schema. Each registrar and registry formats responses differently, requiring custom parsing logic. RDAP returns JSON with a standardized structure, making responses machine-readable across all registries.
Data access and privacy#
WHOIS has no authentication mechanism, every query receives the same response regardless of who asks. Post-GDPR, this means everyone gets redacted data with no way to request more through the protocol itself.
RDAP's design supports differentiated access, so registries can return fuller data to authenticated, authorized requesters (e.g., law enforcement) while serving redacted responses to anonymous queries. While most registries have not yet implemented tiered access, the protocol foundation exists for it, and adoption is expected to grow.
Formatting consistency#
WHOIS responses vary significantly between registrars. A field called "Registrant Name" in one response might be "Holder" in another, and date formats are inconsistent. Automated tools that consume WHOIS data must maintain per-registrar parsing templates.
RDAP eliminates this problem with standardized JSON object types. A domain object always has the same structure whether it comes from Verisign, the .uk registry, or any other provider. This consistency reduces parsing errors and simplifies integration into automated enrichment pipelines used in threat intelligence workflows.
Migration status#
ICANN mandated RDAP support for all gTLD registries and registrars by 2019, and most now have functioning RDAP endpoints. Some registrars have announced plans to sunset their WHOIS servers. ccTLD adoption is less uniform, some have deployed RDAP, while others still offer only WHOIS.
ICANN has signaled that WHOIS will eventually be deprecated for gTLDs, but no firm sunset date has been set. The transition is gradual.
Practical guidance#
For investigation and domain monitoring workflows, the recommended approach is:
- Use RDAP as the primary query method for gTLDs and any registry that supports it. The structured responses integrate cleanly with automated tools.
- Fall back to WHOIS for ccTLDs and registries that have not yet deployed RDAP.
- Cache and normalize responses from both protocols into a common internal format if your pipeline queries both.
- Monitor RDAP adoption for ccTLDs you frequently investigate, switching from WHOIS as endpoints become available.
Both WHOIS and RDAP are essential tools for domain investigations, providing registration context that informs risk scoring and triage. RDAP's structured format and authentication model make it the better choice for automated workflows, while WHOIS remains necessary for coverage gaps. Teams that implement both, with RDAP as the primary path, get the best combination of reliability, consistency, and data access.
Previous
What is Levenshtein distance?
Next
HTTP banner analysis
More from Threat intelligence
View allDomain threat intelligence
Domain threat intelligence is the collection and analysis of signals from domain registrations, DNS, certificates, and hosting to detect abuse. This guide covers core data sources, enrichment workflows, and how domain threat intelligence supports incident response.
Malicious domain detection
Malicious domain detection combines registration signals, DNS behavior, content analysis, and reputation feeds to identify domains used for phishing, malware, or fraud. This guide covers detection approaches, scoring models, and false positive management.
What is certificate transparency?
Certificate Transparency (CT) is an ecosystem of public, append-only logs of issued certificates. Originally created to catch rogue certificates after high-profile CA compromises, CT logs have become an important source of threat intelligence for domain and subdomain monitoring.