BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
RDAP: The Successor to WHOIS, and How to Read a Domain’s Registration Data After the 2025 Sunset
RDAP, the Registration Data Access Protocol, is the modern replacement for WHOIS. It answers the same question, who registered a domain and under what terms, but it returns the answer as structured JSON over HTTPS instead of a wall of plain text on a 1980s port. As of 28 January 2025, ICANN made RDAP the definitive source for generic top-level domain registration data, sunsetting the WHOIS requirement.
This guide explains the protocol and the data together. It covers why WHOIS needed a successor, the RFC stack and the dated timeline behind the switch, the field-by-field difference between the two, and how to run an RDAP lookup end to end, with the redaction and rate-limit gotchas that trip people up.
It also reads that data through a lens the registrar and API guides skip: a registration record is the diligence layer for buying an aged or expired domain. The creation date, the status codes, and the registrant block are the same fields that reveal age, transfer-readiness, and history before money moves. SEO Domains reads that data across its curated catalogue before a domain is ever listed.
What is RDAP, and why is it the successor to WHOIS?
RDAP, the Registration Data Access Protocol, is an IETF-standardised protocol that returns registration data for a domain name, IP address block, or autonomous system number as structured JSON delivered over HTTPS. It is the designated successor to WHOIS, the plain-text protocol it replaced as the authoritative source for generic top-level domain data on 28 January 2025.
RDAP and WHOIS answer the same question and draw on the same underlying records. The difference is entirely in how the answer is fetched and formatted. WHOIS sends a name and gets back a block of free text with no fixed structure. RDAP sends a web request and gets back a defined JSON object whose field names do not change from one registry to the next. The data is the same; its presentation is a generation apart.
The protocol, not just a tool
RDAP is a protocol, the agreed rules for a client and server to exchange registration data, not a single website or company. The Internet Engineering Task Force, the body that standardises core internet protocols, developed it and published it across a set of RFCs. ICANN then required every accredited registrar and gTLD registry to operate an RDAP service, which is why a lookup on a .com and a lookup on a .org now return the same shape of answer from different operators.
WHOIS (the predecessor)
A plain-text query-and-response protocol over TCP port 43, defined in RFC 3912 (2004) with roots in RFC 812 (1982). No encryption, no fixed format, no access control. Now sunsetted as the required gTLD source.
RDAP (the successor)
A RESTful protocol over HTTPS returning structured JSON, defined across IETF RFCs 7480-7484, 9082, and 9083. Encrypted, standardised, internationalised, and capable of tiered access. Authoritative for gTLDs since 28 January 2025.
Why WHOIS needed a successor: the four limitations
WHOIS was replaced because four structural limitations made it unfit for the modern internet: no standardised response format, no encryption or authentication, an all-or-nothing access model incompatible with data-protection law, and no support for internationalised characters. RDAP was designed specifically to close each of these gaps.
WHOIS served for four decades, and that longevity is the point. A protocol documented in 1982 and last revised in 2004 predates HTTPS as a default, the GDPR, and the scale of automated data collection that registries now field. Each limitation below is a reason the system was rebuilt instead of patched.
No standard format
WHOIS returns free text. Every registry and registrar can label and order its fields differently, so a creation date reads Creation Date, Registered On, or created depending on who answers. Reading the record reliably meant maintaining brittle text parsers for hundreds of formats. RDAP returns the same JSON field names every time, which is the single change that does the greatest amount for reliability.
No encryption or access control
A WHOIS query and its answer travelled in plain text on port 43, readable by anything on the path. The protocol had no way to tell a law-enforcement investigator from an anonymous scraper, so personally identifiable data was either exposed to everyone or withheld from everyone. RDAP runs over HTTPS, encrypting every query, and supports authentication so a registry can return different data to different requesters.
Incompatibility with data-protection law
When the GDPR took effect on 25 May 2018, registries redacted registrant contact data from public gTLD records because WHOIS had no way to grant tiered access. The all-or-nothing model forced blanket redaction. RDAP’s differentiated access is the structural answer: public requesters see a limited record, while accredited requesters can be served a fuller one through a defined request path.
No internationalisation
The original protocol assumed ASCII. As domains and registrants spread across non-Latin scripts, WHOIS had no reliable way to carry them. RDAP supports Unicode and internationalised domain names, so a registrant name in Cyrillic or a domain in Arabic script returns intact instead of mangled.
The timeline: from RFC 3912 to the January 2025 sunset
The path to RDAP runs from the 1982 WHOIS specification through the 2015 RFC suite that defined RDAP, the 2019 requirement that accredited registrars and gTLD registries operate it, the 2023 contract amendments that removed the WHOIS obligation, and the 28 January 2025 sunset that made RDAP definitive. WHOIS port 43 is being switched off gradually, not all at once.
The switch was a decade-long migration, not a flip. Reading it as a dated sequence makes the current state legible: RDAP has existed alongside WHOIS for years, the contractual change is recent, and the old port has not vanished everywhere.
The NICNAME/WHOIS protocol is documented in RFC 812, with origins in the early-1970s ARPANET directory. Source: IETF RFC record.
RFC 3912 publishes the current WHOIS specification: a TCP transaction on port 43, plain text, no encryption or fixed format. Source: IETF RFC 3912.
The IETF publishes the core RDAP suite, RFCs 7480 to 7484, defining HTTP usage, security, and bootstrap discovery. Source: IETF RFC record.
ICANN requires accredited registrars and gTLD registries to operate an RDAP service, so RDAP runs in parallel with WHOIS. Source: ICANN.
RFCs 9082 and 9083 update the RDAP query format and JSON response structure, refining the standard. Source: IETF RFC record.
Global Amendments to the base gTLD Registry Agreement and the 2013 Registrar Accreditation Agreement remove the contractual obligation to run WHOIS port 43. Source: ICANN.
RDAP becomes the definitive source for gTLD registration data, sunsetting the WHOIS requirement. Port 43 is then switched off gradually, registry by registry. Source: ICANN announcement.
What the sunset actually changed
The 28 January 2025 sunset removed the requirement that gTLD registries and registrars maintain WHOIS. It did not order an immediate shutdown of port 43. Because the 2023 amendments made WHOIS optional instead of forbidden, a large share of registries keep the old port open while RDAP carries the authoritative load. The practical reading is that RDAP is now the source of record, and any tooling still pointed only at port 43 is living on borrowed time.
RDAP versus WHOIS, point by point
RDAP differs from WHOIS on transport, format, encryption, access model, routing, and scope. It is a RESTful protocol over HTTPS returning standardised JSON, with tiered access, automatic server discovery through a bootstrap registry, internationalisation, and a single model that also covers IP addresses and autonomous system numbers. WHOIS is plain text on TCP port 43 with none of these.
The comparison matters in practice because the format change is what lets a lookup be automated, audited, and trusted to mean the same thing every time. The table consolidates the differences the registrar and API guides scatter across separate posts.
| Dimension | WHOIS | RDAP |
|---|---|---|
| Transport | TCP, port 43 | HTTPS, RESTful (standard web request) |
| Response format | Unstructured plain text, varies by operator | Standardised JSON, identical field names everywhere |
| Encryption | None, queries and answers in clear | HTTPS encrypts every query and response |
| Access model | All-or-nothing, same data to everyone | Tiered, public versus authenticated requesters |
| Server discovery | You must know the right server in advance | Bootstrap registry routes the query automatically |
| Internationalisation | ASCII-centric, non-Latin scripts unreliable | Unicode and internationalised domain names supported |
| Scope | Domains, plus separate IP and ASN lookups | Domains, IP networks, and ASNs in one model |
| Standard | RFC 3912 (2004) | RFCs 7480-7484, 9082, 9083, 9224 |
Inside an RDAP response: the JSON, field by field
An RDAP domain response is a JSON object built from six repeating structures: an events array carrying the registration and expiration dates, an entities array holding contacts and their roles, a nameservers array, a status array of EPP codes, a secureDNS object for DNSSEC, and a vcardArray for contact details. Knowing these field names turns the response from a wall of JSON into a readable record.
The guides that show RDAP JSON show a fragment. The value is in the consolidated map, because once the half-dozen container fields are familiar, every RDAP response on the internet reads the same way.
The containers that hold the data
A domain object names the domain in its ldhName field, the letters-digits-hyphens form. The events array is where the dates live, each entry pairing an eventAction such as registration or expiration with an eventDate. The entities array holds the parties, each tagged with a roles value such as registrant, registrar, administrative, or technical. The nameservers array lists the authoritative DNS servers, the status array carries the EPP status codes, and secureDNS reports whether the domain is DNSSEC-signed.
The vcardArray, where contacts hide
Contact details inside an entity use the vCard 4.0 format from RFC 6350, carried in a field called vcardArray. It is a nested array where each inner entry names a property and its value: a fn entry for the full name, an org for the organisation, an adr for the address, a tel for phone, and an email. Reading a contact means walking that inner array and matching the property name, which is more work than a labelled field but fully deterministic, unlike WHOIS free text.
| What you want | WHOIS line (old) | RDAP JSON location (new) |
|---|---|---|
| The domain name | Domain Name: | ldhName |
| Creation date | Creation Date: | events[] where eventAction is registration, read eventDate |
| Expiry date | Registry Expiry Date: | events[] where eventAction is expiration, read eventDate |
| Registrar | Registrar: | entities[] where roles include registrar |
| Registrant | Registrant Name: | entities[] where roles include registrant, then vcardArray |
| Nameservers | Name Server: | nameservers[] read ldhName |
| Status codes | Domain Status: | status[] |
| DNSSEC state | DNSSEC: | secureDNS, the delegationSigned flag |
The thin-registry two-hop
For .com and .net, the registry RDAP response carries the dates, status, and nameservers but not the registrant contact, because those are thin registries that hold the bare record. The response includes a links array with a registrar reference, identified by its rel and href. A complete lookup follows that link to the registrar’s RDAP server and merges the second response. Missing this two-hop is the commonest reason a .com lookup looks emptier than expected.
Redaction, GDPR, and tiered access
Public RDAP records for gTLD domains routinely have their registrant contact fields redacted, a direct consequence of the GDPR in force since 25 May 2018. A redacted field signals a withheld value, not an absent owner. ICANN provides a Registration Data Request Service for accredited requesters to seek the non-public data through a defined channel, which is RDAP’s tiered access in practice.
Redaction is the single biggest source of misreadings in a modern registration record, and reading a blank registrant as a domain with no owner, or as a red flag, is a beginner error that this section exists to prevent.
Why the fields are blank
Before 2018, public gTLD records exposed registrant names, emails, and addresses. The GDPR made publishing that personal data without a lawful basis a violation, and because WHOIS had no way to grant selective access, registries redacted the personal fields from public output across the board. RDAP carries that same redaction in its JSON, marking the omitted data through the redaction extension defined in RFC 9537, so a parser can tell a redacted field from a genuinely empty one.
RDDS and RDRS: the two access paths
ICANN runs the public registration data through the Registration Data Directory Services, the standard lookup that returns the redacted record anyone can see. For the non-public fields, accredited parties such as law enforcement or rights holders use the Registration Data Request Service, a separate channel that processes a request for the withheld data. Together they are what RDAP’s differentiated-access design enables: a public tier and an accredited tier, in place of WHOIS’s single exposed view.
How to run an RDAP lookup, end to end
An RDAP lookup runs in six steps: pick a lookup interface, submit the domain, let the bootstrap registry route the query, follow the thin-registry link if the registrant is needed, read the events and status arrays, and handle redaction and rate limits. The procedure is the same whether you use a web tool or query an RDAP server directly with a standard web request.
Two routes exist. The simple route is a hosted interface such as ICANN’s official lookup at lookup.icann.org, or a client at client.rdap.org or rdap.org, which hides the routing and returns a readable record. The direct route is a plain HTTPS GET to an RDAP server, useful when the lookup is automated. The steps below cover both, with the specific mistake that derails each.
-
Choose the lookup interface
For a one-off check, use ICANN’s lookup at lookup.icann.org or a hosted client such as rdap.org or client.rdap.org, which present the JSON as a readable record. For automation, plan to query an RDAP server directly over HTTPS.
The mistake: reaching for an old WHOIS-only tool. If it queries port 43 alone, it can return stale or empty gTLD data now that RDAP is the authoritative source.
-
Submit the domain and let the bootstrap route it
Enter the domain. Behind a direct query, the client first reads IANA’s bootstrap registry at data.iana.org/rdap/dns.json, matches the TLD to the correct RDAP base URL, and sends the query there, for example a GET to rdap.verisign.com for a .com. Hosted tools do this for you.
The mistake: hardcoding one RDAP server for every TLD. Each TLD has its own authoritative server, and only the bootstrap registry maps them correctly.
-
Follow the thin-registry link if you need the registrant
For .com and .net, the registry response carries dates, status, and nameservers but not contacts. Follow the registrar reference in the response links array to the registrar’s RDAP server, then merge that second response for the registrant block.
The mistake: stopping at the registry response and concluding the record is incomplete. The two-hop is by design for thin registries, not a fault in the lookup.
-
Read the events array for the dates
Open the events array. Find the entry whose eventAction is registration and read its eventDate for the creation date, the primary age signal. The expiration entry gives the renewal deadline. These two dates carry the bulk of the diligence value in the record.
The mistake: reading the last-changed or last-update event as the creation date. Match the eventAction label, never the position in the array.
-
Read the status array for transfer-readiness
Open the status array and read the EPP codes. A clientTransferProhibited or serverTransferProhibited lock means the domain cannot move today. A pendingDelete or redemptionPeriod status means it is in the drop cycle. These codes tell you whether and when a domain can change hands.
The mistake: ignoring status codes and assuming any listed domain is buyable now. A locked or pending-delete status changes the entire acquisition picture.
-
Handle redaction and rate limits
Expect the registrant contact to be redacted on gTLDs and read that as normal. For automated lookups, respect each server’s rate limit: an HTTP 429 response means the query rate was too fast, and the Retry-After header tells you how long to wait before retrying.
The mistake: hammering an RDAP server and getting silently throttled. Each operator sets its own limit with no central documentation, so back off on the first 429 instead of retrying immediately.
Common RDAP misreads: the consolidated checklist
The mistakes that produce a wrong reading of an RDAP record are a short, repeatable list. Each has a one-line correction, and the corrections converge on the same habit: read the labelled JSON fields for what they mean, follow the thin-registry hop, and treat redaction as policy instead of absence. Use this as the scannable reference for reading a record correctly.
| The misread | Why it is wrong | The correct reading |
|---|---|---|
| Treating the registrar as the owner | The registrar is the entity with the registrar role, the seller, not the registrant | Read the entity whose roles include registrant for the real owner |
| Reading a redacted field as no owner | GDPR redaction withholds the value; the owner exists | Treat a redacted registrant on a gTLD as normal, not a red flag |
| Stopping at the registry response | Thin registries hold no contacts at the registry level | Follow the registrar link in the links array and merge the second response |
| Misreading the creation date | The events array carries several dated actions | Match eventAction registration, then read its eventDate |
| Ignoring the status array | EPP codes decide whether a domain can transfer today | Read status[] for locks, pendingDelete, and redemptionPeriod |
| Hardcoding one RDAP server | Each TLD has its own authoritative server | Use the IANA bootstrap registry to route every TLD correctly |
| Hitting rate limits blind | Servers throttle fast querying with HTTP 429 | Honour the Retry-After header and back off on the first 429 |
| Assuming ccTLDs moved to RDAP | Most country-code registries still answer over WHOIS | Keep a WHOIS path for ccTLDs in a mixed portfolio |
RDAP and ccTLDs: what has not changed
The 28 January 2025 sunset applies to generic top-level domains under ICANN contract, not to country-code domains. The bulk of ccTLD registries, which set their own policies, still answer over WHOIS, and each decides individually whether to adopt RDAP. A mixed portfolio of gTLDs and ccTLDs therefore needs both lookup paths.
This is the caveat the headline framing of the switch buries. RDAP is now authoritative for the gTLD space, but the country-code space is governed registry by registry, and adoption there is uneven.
Why ccTLDs are governed separately
A ccTLD such as .uk, .de, or .cn is run by a national registry operator that sits outside ICANN’s gTLD contracts. Those operators choose their own registration-data systems. A portion have deployed RDAP, a portion still rely on WHOIS, and a portion run both. The American Registry for Internet Numbers and its regional peers, meanwhile, already serve IP-address and ASN registration data through RDAP, which is why the protocol is broader than the domain conversation alone.
The practical workflow for a mixed portfolio
For an investor or SEO holding both, the rule is simple. Query gTLDs over RDAP, where the structured JSON and reliable field names make diligence cleaner. Keep a WHOIS path for ccTLDs that have not migrated, accepting the older plain-text format there. Good hosted tools already fall back automatically, which is why a single lookup interface remains the surest way to read any domain regardless of its TLD.
RDAP frequently asked questions
The five questions investors and SEOs raise when they search for RDAP as the successor to WHOIS, answered against the ICANN policy record and the IETF specification.
Q1Is WHOIS dead now that RDAP exists?
For gTLDs, the requirement to run WHOIS ended with the 28 January 2025 sunset, and RDAP is the definitive source. WHOIS port 43 is being switched off gradually, not all at once, so a large share of registries still answer there for now. For ccTLDs, WHOIS is frequently still the only protocol available. WHOIS is being retired in the gTLD space, not universally dead.
Q2Do domain owners need to do anything because of the switch?
No. RDAP is implemented by registries and registrars, not by domain owners, and the registration data already on file is unchanged. The switch is server-side: only the way the data is accessed has modernised. An owner who never runs a lookup is unaffected.
Q3Why is the registrant blank in an RDAP lookup?
Because of GDPR redaction, in force since 25 May 2018. Public gTLD records withhold registrant contact data, and RDAP carries that redaction in its JSON. The owner exists; the personal fields are hidden by policy. Accredited requesters can seek the non-public data through ICANN’s Registration Data Request Service.
Q4How do I run an RDAP lookup?
Use a hosted interface such as ICANN’s lookup at lookup.icann.org, or a client at rdap.org or client.rdap.org, which return a readable record. For automation, send an HTTPS GET to the correct RDAP server, found through IANA’s bootstrap registry at data.iana.org/rdap/dns.json. For a .com or .net, follow the registrar link to retrieve the registrant block.
Q5What can RDAP data tell me before I buy a domain?
The creation date in the events array is the closest proxy for domain age. The status array shows whether the domain is locked, transferable, or in the drop cycle. The nameservers reveal whether it is in active use or parked. Read together, those fields establish age, transfer-readiness, and prior-use signals before any money changes hands.
Reading RDAP data as domain diligence
Registration data is the diligence layer for acquiring an aged or expired domain. The same RDAP fields that identify an owner also reveal a domain’s age, its transfer-readiness, and its history, and reading them correctly separates a sound acquisition from a guess. SEO Domains reads that data across its curated catalogue before a domain is listed, so the record is verified once, properly, before money moves.
The fields that are buy signals
Every section of this guide converges on a handful of fields that decide a purchase. The creation date is the age signal that distinguishes an aged domain from a freshly registered one. The status codes establish whether a domain can be transferred today or is locked or dropping. The nameservers indicate active use versus a parked shell. The redaction state is neutral on a gTLD and tells you nothing adverse. Read in that order, an RDAP record is a pre-purchase report.
From a record to a decision
A registration record only earns its value when it is read against the decision in front of you. For an investor, the question is whether the age, status, and history justify the price. A creation date a decade back, a transferable status, and a clean prior use are the marks of a domain worth acquiring; a near expiry inside a lock, or a status mid-drop, changes the calculation entirely. This is the reading that turns RDAP from a technical curiosity into a sourcing tool.
| RDAP field | What it reveals | How it reads as a buy signal |
|---|---|---|
| events[] registration date | When the domain was first created | The primary age signal. An older date indicates a genuinely aged domain. |
| events[] expiration date | The renewal deadline | A near date can mean an imminent drop or a short runway for the owner. |
| status[] | EPP lock and lifecycle codes | Whether the domain is transferable now, locked, or already in the drop cycle. |
| nameservers[] | The authoritative DNS servers | Default registrar nameservers often signal a parked or unused domain. |
| secureDNS | DNSSEC signed or unsigned | A signed domain reflects more deliberate prior management. |
| entities[] registrant | The owner, redacted on most gTLDs | Redaction is neutral; a public registrant can reveal prior use or ownership history. |
Source domains whose records are read before you see them
The legitimate demand behind every RDAP and WHOIS lookup, for a buyer, is confidence that a domain’s age, status, and history check out before money moves. That is the product SEO Domains operates: a curated marketplace where aged and expired domains are screened across their registration data and backlink profiles before they are listed and priced, so the diligence this guide describes is already done on every name in the catalogue.
