RDAP is the Registration Data Access Protocol, the HTTPS and JSON service through which registries publish domain, IP address and AS number registration records. It replaced WHOIS for generic top-level domains, which were no longer required to run WHOIS after 28 January 2025.

how do i read an rdap record

Start with events for the registration date, then status for what the registry currently allows, then entities for the registrar and its abuse contact, then nameservers for the delegation. Expect no registrant contact details, because they are redacted by default.

does an rdap 404 mean the domain is available

No. A 404 means this registry returned no object for that name, which also happens for reserved, premium and blocked names and for endings served by a registry the bootstrap file does not list. Only a registrar's availability check confirms a name can be bought.

why is the registrant redacted in rdap

Since ICANN's Temporary Specification took effect on 25 May 2018, registrars and registries must treat the registrant's name and contact fields as redacted unless the holder consents to publication. Redaction is the normal state of a record, not a sign of bad faith.

what is the difference between rdap and whois

WHOIS returned unstructured text on port 43 in a layout each registry chose. RDAP returns JSON over HTTPS with named fields, a published way to find the right server, real HTTP error codes and support for authenticated access. The facts inside are largely the same.

which rdap lookup tool should i use

lookup.icann.org is ICANN's own client for generic domains. client.rdap.org sends the query from your browser directly to the registry and handles domains, IP addresses and AS numbers. For scripts, use the registry base URL from the IANA bootstrap file, or rdap.org, which redirects to it.

TECHNICAL

RDAP Explained: How to Read a Domain Registration Record

The registration record is where a domain investigation starts, and it is more often silent than people expect.

by Typosquatting.ai Research16 September 2026updated 23 September 202612 min read

RDAP, the Registration Data Access Protocol, is the standard HTTPS service through which a registry returns a domain's registration record as structured JSON.

This guide covers how a lookup finds the right server, what each field in a real record means, how to read the status codes, why contact details are redacted, why a 404 does not mean a name is available, how RDAP works for IP addresses, and how to run a lookup yourself.

What RDAP is, and what it replaced

For most of the internet's history the way to ask who held a domain was WHOIS, a text protocol on port 43 whose answers had no fixed layout. RDAP replaced it for generic endings by contract. ICANN's announcement set 28 January 2025 as the date from which RDAP became the definitive source for gTLD registration data and registrars and registries were no longer required to run WHOIS at all.

The practical difference is that a field now has a name. A parser reading WHOIS text was guessing which line meant the creation date, in a layout that could change without notice. A parser reading RDAP asks for the registration event and either gets one or does not.

How a lookup finds the right server

There is no single registration database. Each registry runs its own service, so the first job of any lookup is to work out which one is authoritative for the ending in question. That is done with a bootstrap file published by IANA at data.iana.org/rdap/dns.json, which maps each ending to the base address of its RDAP service. The file lists top-level domains only, so example.co.uk is served by the entry for uk.

A client reads the bootstrap, selects the service for the ending, and requests the domain object over HTTPS. The response is JSON with a defined structure, so a program can read it without guessing at a layout that varied by registry.

You do not have to do the bootstrap step by hand. lookup.icann.org is ICANN's own web client. client.rdap.org sends the query straight from your browser to the registry and can look up domains, IP addresses and autonomous system numbers. rdap.org runs a redirecting endpoint, so a request to rdap.org/domain/example.com is bounced to the authoritative server, which is useful in scripts.

One wrinkle matters for lookalike work, because a variation frequently sits under a different ending and therefore a different registry. Some registries run an RDAP service that is not listed in the IANA file. DENIC serves .de records at rdap.denic.de and describes the service as test operation, and SWITCH serves .ch and .li at rdap.nic.ch. A client that trusts the bootstrap alone will report those endings as having no RDAP when a record was there.

What the record contains

A domain object carries status codes, events such as registration, expiration and last changed, nameservers, and entities with roles such as registrar and registrant. The registrar entity usually includes a name, an IANA registrar identifier and an abuse contact. The registration date lets you calculate domain age, which is one of the stronger signals for review priority.

Field	What it holds	What it is worth in review
ldhName	The domain in its ASCII form; xn-- for internationalised names	Confirms which name the registry actually answered about
events	Registration, expiration, last changed, transfer	Age, and whether the name changed hands recently
status	EPP status codes	Whether the name is delegated, held, or on its way out
nameservers	The delegated servers	Shared nameservers can group related registrations
entities	Registrar, abuse contact, and roles that survive redaction	Where a report goes, and who is accountable for acting on it

A real record: example.com

Below is the record the .com registry returned for example.com when this guide was written, trimmed to the four parts that carry the useful information. The real response also carries links, notices and an rdapConformance array. Note that the registry writes status values with spaces, so the WHOIS code clientTransferProhibited appears here as client transfer prohibited.

GET https://rdap.verisign.com/com/v1/domain/example.com: { "objectClassName": "domain", "ldhName": "EXAMPLE.COM", "status": ["client delete prohibited", "client transfer prohibited", "client update prohibited"], "events": [{"eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z"}, {"eventAction": "expiration", "eventDate": "2027-08-13T04:00:00Z"}, {"eventAction": "last changed", "eventDate": "2026-08-14T08:01:43Z"}], "entities": [{"objectClassName": "entity", "handle": "376", "roles": ["registrar"], "publicIds": [{"type": "IANA Registrar ID", "identifier": "376"}], "vcardArray": ["vcard", [["fn", {}, "text", "RESERVED-Internet Assigned Numbers Authority"]]], "entities": [{"objectClassName": "entity", "roles": ["abuse"]}]}], "nameservers": [{"objectClassName": "nameserver", "ldhName": "ELLIOTT.NS.CLOUDFLARE.COM"}, {"objectClassName": "nameserver", "ldhName": "HERA.NS.CLOUDFLARE.COM"}] }
How to read it: The registration event says the current registration began on 14 August 1995. The three status values are locks the registrar set, which is normal for a name its holder cares about. The registrar entity carries IANA ID 376, and its nested abuse entity is where a report would go. There is no registrant entity at all, which is the usual case.

Status codes are the part most people skip

The status array is the shortest field and frequently the most informative, because it describes what the registry will currently allow. A name can be registered and still be switched off, or registered and already on its way to deletion. ICANN publishes the full list of EPP status codes; these are the ones that change a reading.

ok: Registered, delegated, and with nothing pending. ICANN calls this the standard status for a domain.
inactive: No nameservers are delegated, so the name resolves nowhere regardless of who holds it.
clientHold: The registrar has told the registry not to activate the name in DNS, so it does not resolve. Frequently the result of an abuse report that was acted on, or of unverified contact details.
serverHold: The registry itself has done the same thing, which is a heavier intervention.
clientTransferProhibited: The registrar blocks transfers to another registrar. On your own domains this is a defence, not a warning.
redemptionPeriod: The registrar has asked the registry to delete the name. ICANN's page says the name is held in this status for 30 days, during which the holder can restore it.
pendingDelete: Past redemption and on its way out of the registry, after which it becomes available to register again.

Reading the creation date properly

Registration age does more work in any triage than every other field combined, because abusive use of a lookalike overwhelmingly happens close to registration. A name created eleven days ago that resolves and holds a certificate is a different object from the same name created in 2014.

Two cautions. The creation date is the date of the current registration, so a name that lapsed and was re-registered shows the newer date and its earlier history is invisible here. And a date that is missing is not a young registration; it is an absent field, and the record is incomplete rather than old or new.

Why the contact details are usually missing

A record that tells you when a name was registered and through which registrar, but not who registered it, is the normal case rather than a broken one. Registration data was widely published until data-protection law made blanket publication of personal data untenable. ICANN's Temporary Specification for gTLD Registration Data took effect on 25 May 2018 and required registrars and registries to treat the registrant's name, street, city, postcode, phone and fax as redacted unless the holder consented to publication.

What survives publication is the part that is not personal: dates, statuses, the registrar, the nameservers. That is enough for most investigative purposes, because the questions that matter operationally are when this name appeared and what it is connected to, not whose name is on it.

Where identity genuinely matters, the route is a disclosure request through the registrar, not a lookup. Treating redaction itself as suspicious would flag most of the internet.

A 404 is not 'available'

RDAP uses ordinary HTTP status codes, and RFC 7480 is precise about what they mean. A 404 means the server has an empty result set for the query: this registry has no object for this name. A 429 means the server declined to answer because of rate limits. A 5xx means the server failed. Treating these three as one case is the most common error in domain tooling, and it produces confident wrong answers in both directions.

The server answers 404. This registry has no record of this name. It does not mean the name is available to buy: it may be reserved, premium, blocked by the registry, in a state the registry does not expose, or handled by a service the bootstrap pointed away from. Only a registrar's availability check confirms that a name can be bought.
The server answers 429, or times out. This is an absence of information. A tool that records it as not registered has invented a fact. Unknown has to stay unknown.
The ending has no RDAP service in the bootstrap. Some country endings publish none, and some publish one outside the IANA file, as .de and .ch do. That is a gap in coverage, not a property of the name.

The inverse error is the dangerous one in a review: reading a 404 as proof that nobody has the name. A registry that answered nothing has told you nothing.

RDAP for IP addresses and ASNs

Many people searching for RDAP mean the other half of it. The same protocol serves the regional internet registries, so an IP address or an autonomous system number has an RDAP record too, and the query paths are defined alongside the domain path in RFC 9082: /domain/ for a name, /ip/ for an address or CIDR block, and /autnum/ for an AS number.

ARIN answers at rdap.arin.net/registry, so rdap.arin.net/registry/ip/192.0.2.1 returns the network object for that address, and APNIC runs the same service on rdap.apnic.net. What comes back is the allocation, the organisation it was allocated to and its abuse contact, not the domain that happens to resolve to it.

For lookalike work this is the record you read after DNS has given you an address. It tells you which hosting provider to report to, and several findings sitting in one allocation is one of the cheaper ways to group them.

Reading one yourself

Nothing here requires a product. The bootstrap file is public and the endpoints answer ordinary HTTPS requests, so a single lookup is a matter of two fetches.

Fetch https://data.iana.org/rdap/dns.json and find the entry whose service list contains your top-level domain. For com the base is https://rdap.verisign.com/com/v1/.
Request domain/<name> from that base, sending an Accept header of application/rdap+json. From a terminal: curl -H 'accept: application/rdap+json' https://rdap.verisign.com/com/v1/domain/example.com
Read events for the registration date, status for what the registry will allow, entities for the registrar and its abuse contact, and nameservers for the delegation.
Record the response and the time you made it, because the record you are reading can change tomorrow.

How the checker treats gaps

The checker on this site requests registration data through RDAP for its highest-priority findings and applies the reading above. A 404 is recorded as no registry record; a timeout, rate limit or non-RDAP registry is recorded as Unknown, and Unknown never contributes to a Low signal rating, so a provider outage cannot make a registered domain look safe.

What a registration record cannot tell you

It cannot tell you what a name is being used for. A record describes an entry in a registry, not a website, and the two are frequently unrelated: names sit registered and unused for years, and a name with a spotless record can serve a phishing page an hour after it resolves.

It also cannot tell you about intent. A registrar, a creation date and a set of statuses are administrative facts. Combined with DNS answers, certificate records and passive observations they give you a shape. Deciding what that shape means is a human judgement, and a risk label built from these facts is a review priority, never a finding of phishing.

Common questions

what is rdap: RDAP is the Registration Data Access Protocol, the HTTPS and JSON service through which registries publish domain, IP address and AS number registration records. It replaced WHOIS for generic top-level domains, which were no longer required to run WHOIS after 28 January 2025.
how do i read an rdap record: Start with events for the registration date, then status for what the registry currently allows, then entities for the registrar and its abuse contact, then nameservers for the delegation. Expect no registrant contact details, because they are redacted by default.
does an rdap 404 mean the domain is available: No. A 404 means this registry returned no object for that name, which also happens for reserved, premium and blocked names and for endings served by a registry the bootstrap file does not list. Only a registrar's availability check confirms a name can be bought.
why is the registrant redacted in rdap: Since ICANN's Temporary Specification took effect on 25 May 2018, registrars and registries must treat the registrant's name and contact fields as redacted unless the holder consents to publication. Redaction is the normal state of a record, not a sign of bad faith.
what is the difference between rdap and whois: WHOIS returned unstructured text on port 43 in a layout each registry chose. RDAP returns JSON over HTTPS with named fields, a published way to find the right server, real HTTP error codes and support for authenticated access. The facts inside are largely the same.
which rdap lookup tool should i use: lookup.icann.org is ICANN's own client for generic domains. client.rdap.org sends the query from your browser directly to the registry and handles domains, IP addresses and AS numbers. For scripts, use the registry base URL from the IANA bootstrap file, or rdap.org, which redirects to it.