rdap.org answers 404 for registered .me domains

Last updated 2026-09-26

Conclusion. A 404 from rdap.org for a .me name does not mean the name is free. The .me back-end operator runs an RDAP server, but it is not listed in IANA's RDAP bootstrap file, so rdap.org has no server to forward the query to and answers 404 itself — the same status code a genuinely unregistered name gets. You can tell the two apart by whether rdap.org redirected. For .me, check WHOIS, the back-end operator's RDAP server directly, or a registrar's search instead. This holds as of September 2026 (dns.json edition 2026-09-16) and ends if .me is added to that file.

Evidence

Measured 2026-09-25 and 2026-09-26.

Query	Result
`rdap.org` → `hibiki.me`	`404`, no redirect
`rdap.org` → `hibiki.dev`	`302` → `pubapi.registry.google` → `200`
`rdap.org` → `hibiki.app`	`302` → `pubapi.registry.google` → `200`
`rdap.org` → `hibikihata.com`	`302` → `rdap.verisign.com` → `200`
.me operator RDAP → `hibiki.me`	`200`
.me operator RDAP → an unregistered `.me` name	`404`

All four names are registered. WHOIS for hibiki.me shows a creation date of 2023-05-06, registrar GMO Internet Group d/b/a Onamae.com, and nameservers at Cloudflare; the RDAP server run by the .me back-end operator, Identity Digital (rdap.identitydigital.services), returns the same nameservers. So the 404 from rdap.org is a false negative, and the operator's server answers correctly.

Why it happens

RDAP clients find the right server through IANA's bootstrap file, https://data.iana.org/rdap/dns.json. In the edition published 2026-09-16, dev and app map to https://pubapi.registry.google/rdap/ and com maps to https://rdap.verisign.com/com/v1/. There is no entry for me. .me is a country-code domain (Montenegro), and country-code registries are not obliged to register an RDAP server with IANA the way generic ones are.

rdap.org only knows the servers listed in that file. When a TLD has no entry, it answers 404, which its own documentation gives as the response when it knows of no RDAP service for the name. RFC 9224 says a client in that situation should report an error; rdap.org uses 404 instead, and 404 is also what RDAP returns when a registry has no record of a name (RFC 7480 §5.3).

How to tell the two apart

Do not follow redirects on the first request. rdap.org documents 302 as its response when it knows an authoritative server. A 404 without a redirect means "no known server", not "not registered".
If you follow redirects, look at where you ended up. A 404 from the registry's own host is a real answer; a 404 from rdap.org is not.
Or check dns.json for the TLD before querying.
Treat anything other than 200 and a registry-issued 404 as unknown. rdap.org also answers 403 and 429 when it limits requests.

Even a real 404 means "not registered", not "available to register": reserved and blocked names can return 404 too. Confirm with a registrar before counting on a name.

A second trap: local `whois` on macOS

The obvious fallback has its own hole. The macOS whois command first asks whois.iana.org and then follows the WHOIS server it names for the TLD. For .me that is whois.nic.me, so whois hibiki.me works. For .dev and .app, IANA lists no WHOIS server, so there is nothing to follow, and you get the record for the top-level domain itself. (ICANN dropped the WHOIS requirement for generic TLDs on 28 January 2025, and many registries now offer RDAP only.) For .dev and .app, use RDAP; for .me, use WHOIS. Pick the tool per TLD.

Method