Stealth RDAP: Finding the RDAP Server for .io, .de, and 40 More

The RDAP server for .io works perfectly. Ask the official system that is supposed to tell you where it is, and you get a 404.

# The server is right here, and it answers:
curl -s https://rdap.identitydigital.services/rdap/domain/git.io | jq '.ldhName'
# "git.io"

# Ask bootstrap — the standard way to find it — and it shrugs:
curl -s -o /dev/null -w '%{http_code}\n' https://rdap.org/domain/example.io
# 404

That contradiction has a name. The RDAP deployment tracker calls servers like this stealth RDAP: live, standards-compliant, answering queries all day — and completely invisible to any client that discovers servers the correct way. .io is the famous one, but it is not alone. More than forty TLDs run stealth RDAP, including .de — the single largest country-code registry on the internet.

If you have ever wondered why "rdap server for .io" is a question people keep asking and rarely get a straight answer to, this is why. Here is what is actually going on, and where the hidden servers live.

Why a working server goes missing

RDAP was built so no client ever has to hardcode a server URL. IANA publishes a machine-readable map — the bootstrap registry, defined in RFC 9224 — from every TLD to its authoritative RDAP base URL. A well-behaved client fetches that map, looks up the TLD, and follows it. The public rdap.org service does exactly this and answers with a 302 redirect. It is the right way to do discovery, and it is what almost every RDAP library does under the hood.

The catch is in how the map gets filled. For generic TLDs (.com, .app, .xyz), RDAP is an ICANN contractual requirement and the bootstrap entry is mandatory — so gTLD coverage is effectively complete. For country-code TLDs, RDAP is voluntary. A ccTLD operator has to stand up an RDAP server and submit its URL to IANA. Plenty have done the first and skipped the second.

.io is the textbook case. Its registry back-end runs RDAP on the same Identity Digital host that serves .ai — but where .ai is registered in dns.json, .io is not:

curl -s https://data.iana.org/rdap/dns.json | grep -o '"ai"'   # -> "ai"
curl -s https://data.iana.org/rdap/dns.json | grep -o '"io"'   # -> (nothing)

Same operator, same working server, one TLD listed and one not. There is no technical reason — just an entry nobody added. Until someone does, every bootstrap-based tool on earth will 404 on .io.

The stealth roster

Here are the recognizable ones, with the server each actually answers on. Every row below was checked against the live server and against dns.json in July 2026: all of them respond, none of them are in bootstrap.

TLD	RDAP base URL
`.io`	`https://rdap.identitydigital.services/rdap/domain/{d}`
`.me`	`https://rdap.identitydigital.services/rdap/domain/{d}`
`.sh`	`https://rdap.identitydigital.services/rdap/domain/{d}`
`.co`	`https://rdap.registry.co/co/domain/{d}`
`.us`	`https://rdap.nic.us/domain/{d}`
`.ch`	`https://rdap.nic.ch/domain/{d}`
`.li`	`https://rdap.nic.li/domain/{d}`
`.ru`	`https://cctld.ru/tci-ripn-rdap/domain/{d}`
`.de`	`https://rdap.denic.de/domain/{d}`

A dozen of these — .io, .me, .sh, and other Identity Digital ccTLDs — share the one rdap.identitydigital.services host. The rest are individual national registries, each on its own hostname and, of course, its own path shape.

.de deserves its own note. DENIC, the German registry, runs the largest ccTLD in the world and does operate a public RDAP service — it just isn't in bootstrap either:

curl -s https://rdap.denic.de/domain/denic.de | jq -c '.rdapConformance'
# ["rdap_level_0","denic_version_0"]

Note what you don't get back: DENIC returns the domain's technical record but, citing German data-protection law, withholds the holder entirely. Stealth does not mean unrestricted — a hidden server can still be a redacted one.

This roster is a snapshot, not a spec. Servers move, and IANA can add an entry tomorrow that turns a stealth TLD into a normal one. The authoritative, always-current view of which TLDs are covered — and which run stealth servers — is the deployment dashboard itself.

Handling stealth RDAP without hating your code

Here is the uncomfortable part. RDAP's whole promise is "never hardcode a server." Stealth TLDs break that promise, because the only way to reach them is to know their hostname out of band. So any client that wants to resolve .io ends up doing the exact thing the protocol was designed to avoid: keeping a hand-maintained map of servers bootstrap forgot.

There is no clever way around it. A production RDAP client needs three layers:

Bootstrap first. Fetch dns.json, cache it to its Expires header (IANA sends max-age=86400), and use it for everything it covers — which is most of the internet.
A stealth supplement. A small override table for the TLDs bootstrap misses: .io, .de, .co, and the rest. Yes, it is hardcoded hostnames. There is no alternative that reaches these domains.
A way to find new ones. Stealth servers appear without announcement, so both bootstrap and a static list go stale. The only way to keep up is to periodically probe uncovered TLDs at their likely hostnames and see what answers — which is exactly how .aw (Aruba) turned up on a live RDAP server that no public registry points to.

And one rule that falls out of all this: a 404 from a bootstrap redirector does not mean a domain is available. It might mean the TLD runs a stealth server, or has no RDAP at all. Treating every bootstrap miss as "unregistered" is a classic way to get availability checks wrong.

Or let it just answer

Maintaining a bootstrap cache, a growing stealth supplement, and a probe job for new hidden servers is exactly the kind of plumbing you would rather not own. It is the plumbing RDAP API owns for you: a map of 43 stealth TLDs — 42 verified by hand and one (.aw) the probe found on its own — a discovery job that keeps scanning for more, and normalization so .io comes back shaped identically to .com.

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://rdapapi.io/api/v1/domain/git.io?follow=true"

.io resolves like any gTLD — no special-casing on your side, no 404 surprises, no stealth map to keep current. See the API docs for the schema, or the supported TLDs for everything it covers. And if you want the mirror image of this problem — a registry that is in bootstrap but answers 404 for reasons of its own — read the Verisign .com walkthrough.