RDAP

RDAP (Registration Data Access Protocol) is the JSON-over-HTTPS replacement for WHOIS. Instead of a free-text blob returned over port 43, an RDAP query returns a structured document with defined fields, real HTTP status codes and a discovery mechanism that tells you which server to ask. It sits alongside EPP, the protocol registrars use to change registration data, where RDAP only reads it.

Defined by RFC 7480 and 7481, with the query format in RFC 9082 and the JSON response format in RFC 9083. It has replaced WHOIS for generic TLDs almost completely. For country-code TLDs it has barely replaced it at all, and knowing which side of that line a domain falls on is the difference between a lookup that works and one that silently returns nothing.

Domainee is a custom domains API for SaaS with a native MCP server — 50 domains and 100 GB free.

Coverage is a gTLD story, not a global one

Measured against the IANA bootstrap file and the delegated-TLD list on 2026-08-26:

TLD group	Total delegated	Publish RDAP	No RDAP service
Non-country TLDs (gTLDs, brands, infrastructure)	1,039	1,036	3
Two-letter ccTLDs	248	70	178
IDN TLDs	151	94	57
All delegated TLDs	1,438	1,200	238

The three non-country gaps are arpa, edu and mil — special-purpose namespaces, not commercial ones. Among TLDs you can actually register a name in, generic coverage is effectively total.

Country codes are the opposite: 178 of 248 publish no RDAP service at all, including .io, .co, .me, .us, .de, .es, .it, .ch, .se, .dk, .sh and .gg.

The reason is contractual rather than technical. ICANN's agreements with gTLD registries obliged them to stand up RDAP; ICANN has no such contract with ccTLD operators, who run their namespaces under national authority and adopt it when they choose. So "RDAP replaced WHOIS" is true of the namespace ICANN governs and not of the rest.

The consequence: a 404 does not mean available

This is the bug the coverage gap actually produces, and it is common enough to be worth naming.

RDAP returns 404 for a name that is not registered. That makes a tempting availability check: query RDAP, treat 404 as free. But a general-purpose front end like rdap.org also returns 404 when the TLD has no RDAP service — there is nowhere to forward the query to. The two are indistinguishable from the status code alone.

So a checker written that way reports every .io, .co and .me name as available. github.io, google.co and about.me all come back registrable. We hit exactly this and fixed it by consulting the bootstrap first: only treat 404 as availability when the TLD is actually in the bootstrap, and otherwise fall back to a delegation check, since a name with nameservers is registered whatever RDAP says. The domain availability checker reports which method answered for that reason.

For .io specifically there is no comfortable fallback. It has no RDAP service, and whois.nic.io did not answer from this machine either, so DNS delegation is the only public signal left.

How discovery works

You do not hard-code a server per TLD. IANA publishes a bootstrap document at https://data.iana.org/rdap/dns.json mapping TLDs to RDAP base URLs:

{
  "services": [
    [["com", "net"], ["https://rdap.verisign.com/com/v1/"]],
    [["org"],        ["https://rdap.publicinterestregistry.org/rdap/"]],
    [["dev"],        ["https://www.registry.google/rdap/"]]
  ]
}

The 2026-07-23 publication carries 590 service entries covering 1,200 TLDs. Cache it — a day is the usual choice — and keep the previous copy, because a fetch failure should degrade to stale data rather than to no answers at all.

Then query <base>/domain/<name>. A TLD absent from the file has no RDAP, and that is a fact worth surfacing to the caller rather than papering over — a DNS record lookup is the fallback signal when RDAP has nothing to say.

What a response looks like

Live responses on 2026-08-26 from four different registries — Verisign for .com, PIR for .org, Google for .dev, CentralNic for .xyz — all declared the same conformance set: rdap_level_0, plus ICANN's response profile and technical implementation guide.

That uniformity is the real advantage over WHOIS. Same field names, same date format, same status vocabulary, across operators who share no code:

{
  "objectClassName": "domain",
  "ldhName": "example.com",
  "events": [
    { "eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z" },
    { "eventAction": "expiration",   "eventDate": "2026-08-13T04:00:00Z" }
  ],
  "nameservers": [{ "ldhName": "a.iana-servers.net" }],
  "status": ["client delete prohibited", "client transfer prohibited"]
}

No regular expressions, no per-registrar parsers, no guessing whether a date is dd-mmm-yyyy or ISO 8601.

Two fields carry most of the value. events gives you registration and expiration dates for expiry tracking. status gives you the EPP status codes, the same vocabulary behind a registrar lock — clientTransferProhibited, redemptionPeriod, pendingDelete — as a list rather than prose. Read them as a set, because that is what they are.

Worth knowing when interpreting status: a name in redemptionPeriod or pendingDelete still reports as registered. "Taken" is not permanent, and RDAP will not tell you a name is about to drop unless you read those codes.

Redaction, and what RDAP does better

RDAP is subject to the same privacy regime as WHOIS. Registrant contact details are widely withheld, and for individuals in the EU that is the norm rather than the exception. What survives is the operational data: nameservers, dates, statuses — enough to detect a dangling record or an imminent expiry, not enough to identify a person.

The difference is that RDAP can say so in a machine-readable way, through remarks entries that mark a field as redacted rather than simply omitting it. A parser can distinguish "this registry does not publish that" from "there is no such value," which WHOIS never allowed. RDAP also has a place for authenticated access, so a party with standing can be shown more, where WHOIS had no notion of an authenticated caller.

WHOIS did not actually go away

RDAP being the standard is not the same as WHOIS being switched off, and assuming otherwise produces a fallback path you never test.

Port-43 WHOIS still answered on 2026-08-26 at both registries checked: whois.verisign-grs.com returned a full record for google.com, and whois.pir.org returned one for wikipedia.org (with Registry Domain ID: REDACTED, where Verisign still publishes the ID). The old protocol is deprecated, not dead.

That leaves three practical regimes:

Namespace	RDAP	Port-43 WHOIS	What to query
gTLDs (.com, .org, .dev, .xyz)	Yes	Still answering	RDAP; it parses
ccTLDs with RDAP (70 of 248)	Yes	Usually	RDAP
ccTLDs without RDAP (178 of 248)	No	Varies by registry	WHOIS, if the registry runs one
.io specifically	No	Did not answer	Delegation check only

The last row is the awkward one. A transfer or expiry workflow that assumes it can always read a registration date will silently do nothing for a large slice of ccTLD names, so decide explicitly what your product does when the data is simply unavailable rather than treating absence as a zero.

Using it in a product

Two jobs come up repeatedly, and they want different things.

Availability checks. Query RDAP, treat 404 as available only after confirming the TLD is in the bootstrap, and fall back to a delegation lookup otherwise. Remember that available is not the same as registrable: premium pricing, registry-reserved strings and local-presence rules on many ccTLDs all produce names that look free and cannot be bought.

Expiry and status monitoring. Poll events and status per name. This is where RDAP earns its place, because the fields are stable enough to alert on. Note that the registration date resets if a name drops and is re-registered, so treat domain age as weaker evidence than it appears.

Abuse and reputation signals. Registration date and status feed fraud scoring far better than they feed anything else — a name registered yesterday behaves differently from one registered in 2009. This is a real use, unlike SEO: domain age is not a Google ranking factor, and treating it as one is a common misreading. It does bear on domain reputation and on spotting typosquatting around your own brand.

If you are already integrated with one registrar, its domain API will answer both questions for names it holds and will be faster. RDAP is for the cross-registrar case: names you do not manage, at registries you have no relationship with, and at registrars you are not integrated with. The WHOIS lookup tool runs this path, and RDAP versus WHOIS covers the older protocol.

FAQ

What is RDAP? The Registration Data Access Protocol: a JSON-over-HTTPS successor to WHOIS. It returns structured registration data with defined field names, uses real HTTP status codes, and publishes a bootstrap file so clients can find the right server for any TLD. The current specification set is RFC 7480 and 7481 with RFC 9082 (query format) and RFC 9083 (JSON responses), which obsoleted RFC 7482 and 7483 in June 2021 — plenty of documentation still cites the superseded pair.

Has RDAP replaced WHOIS? For generic TLDs, effectively yes — 1,036 of 1,039 non-country TLDs published an RDAP service as of 2026-08-26. For country-code TLDs, no: 178 of 248 have none, including .io, .co, .me and .de. ICANN could contractually require it of gTLD registries and cannot of ccTLD operators.

Why does RDAP say a registered domain is available? Because a 404 is ambiguous through a general front end. It means "no such domain" when the TLD has an RDAP service and "no server to ask" when it does not. Check the IANA bootstrap before reading a 404 as availability, and fall back to a nameserver-delegation check for TLDs that are missing.

Does .io support RDAP? No. .io is not in the IANA RDAP bootstrap, and its port-43 WHOIS did not answer from this machine either, so DNS delegation is the only public registration signal for .io names.

How do I find the RDAP server for a TLD? Fetch https://data.iana.org/rdap/dns.json, which maps TLDs to base URLs, and query <base>/domain/<name>. Cache it for about a day and fall back to your stale copy on a fetch failure rather than failing every lookup.

Does RDAP show registrant contact details? Usually not. The same privacy rules that emptied WHOIS apply, and personal contact data is generally withheld. RDAP's advantage is that it marks redactions explicitly in remarks instead of silently omitting fields, and it supports authenticated access for parties entitled to see more.