Compare WHOIS and RDAP outputs, transport, status handling, referrals, redaction notices, and automation reliability.
What matters first
- RDAP uses HTTPS and structured JSON; WHOIS usually returns free-form text over port 43.
- RDAP entity roles and event actions prevent several common parsing errors.
- Neither protocol guarantees that every field is public or current.
- For current gTLD workflows, RDAP should be the default source.
The practical difference
WHOIS normally returns free-form text over TCP port 43. RDAP returns JSON over HTTPS with defined object classes for domains, nameservers, entities, networks, autnums, events, notices, links, and remarks. That structure makes RDAP safer to automate and easier to internationalize.
Run the RDAP lookup when the investigation needs typed events, notices and a source URL instead of parsed free-form labels.
How equivalent fields line up
A WHOIS creation-date line typically maps to an RDAP event whose eventAction is registration. WHOIS registrar text maps to a registrar entity identified by a role. Domain statuses map to a standardized status array. RDAP links identify related or authoritative resources instead of relying on human-readable referral lines.
Prefer RDAP for applications
Use RDAP when you need typed JSON, HTTPS, bootstrapping, explicit notices, or consistent network and ASN queries. Retain WHOIS as a diagnostic fallback where a registry has not completed a transition or where comparing the legacy presentation is itself useful.
The RDAP bootstrap guide shows how the client finds the correct service without guessing an endpoint.
Do not flatten away evidence
A parser should retain eventAction, entity roles, notices, remarks, redaction explanations, and source links. Turning all of that into one owner/date table creates false certainty and loses the reason a field may be absent.
Evidence-to-decision table
| Evidence | What it means | Responsible next step |
|---|---|---|
| Transport | WHOIS: TCP/43; RDAP: HTTPS | Prefer RDAP for authenticated web transport |
| Dates | Text labels versus typed events | Store eventAction with eventDate |
| Contacts | Ad-hoc blocks versus role-bearing entities | Keep roles and redaction notices |
| Discovery | Referral conventions versus IANA bootstrap | Use bootstrap for deterministic routing |
Illustrative migration of a registration parser
This is an illustrative example, not a claimed real-world test.
Capture real legacy field variants before changing the production mapping.
Model RDAP events, entities, links, notices and remarks as repeatable objects rather than one flat row.
Run both sources during a limited comparison window and log semantic differences, not just blank fields.
Defensible outcome: The result is not a forced one-to-one conversion. It is a source-aware model that can explain which protocol supplied each fact and why a value may be absent.
Action checklist
- Use IANA bootstrap
- Validate HTTP status and media type
- Retain self and related links
- Keep entity roles
- Keep every event action
- Display notices and remarks
- Cache responsibly without hiding freshness
Edge cases that change the answer
Rate limiting
Honor HTTP status, Retry-After and service terms; a blank application screen must not be presented as an empty registration record.
Redacted entity
Preserve the entity role and redaction notice even when contact fields are absent.
Unsupported suffix
Do not silently route an unknown TLD to a convenient third-party endpoint; report that bootstrap did not select a service.
Questions this guide should settle
Does RDAP replace DNS?
No. RDAP describes registration objects; DNS publishes operational naming data.
Can RDAP be cached?
Yes, with HTTP caching signals and freshness disclosure appropriate to the application.
Is JSON automatically accurate?
No. Structure reduces ambiguity, but accuracy still depends on the source data and correct interpretation.