RDAP lookup

What an RDAP lookup gives you

An RDAP lookup returns a domain's registration record as structured JSON, straight from the registry that runs the domain's extension (the part after the last dot, such as .com). RDAP stands for Registration Data Access Protocol. It does the same job as WHOIS, but over ordinary HTTPS, with fixed field names, real HTTP status codes and a standard way to mark data as redacted.

This page runs the query and shows its working. Besides the readable summary, you get the server that answered, the exact request URL, the time each step took and the raw JSON. That helps when you are scripting against RDAP, debugging a registry, or checking that what another site told you matches the registry. If you only want the finished record in plain English, the WHOIS lookup is the shorter route.

How to run a query

1. Enter a domainAny registered domain works. Names with accents or non-Latin letters are converted to their xn-- form (called Punycode) before the query goes out.
2. Open the Raw tabThe Raw tab holds the registry's JSON exactly as it arrived. When the registry points to the registrar's own RDAP server, a second block shows the registrar's JSON too.
3. Check how we got itThe How we got this tab lists each step with its status code and timing, plus the request URL and the server list entry that matched. To see the registry's answer alone, switch off the registrar option under More options.
4. Repeat it yourselfCopy the request URL into curl to get the same JSON. An AI assistant can do the same through the MCP server: ask it to call the whois_lookup tool with includeRaw turned on.

# Through the public bootstrap redirector
curl -sL https://rdap.org/domain/example.com | jq .

# Straight from a registry (Verisign handles .com)
curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '.entities[].roles'

How to read the JSON

An RDAP response is one JSON object. Most of what you need sits in a handful of members.

Errors and what they mean

The HTTP status code usually tells you most of the story.

• HTTP 404. The registry has no such domain. For most extensions that means it is unregistered, and the domain availability checker can confirm it.
• HTTP 429. The registry's rate limit was hit, because registries limit how often one client may ask. The Retry-After header, when there is one, says how long to wait.
• HTTP 403 or 501. The server refuses automated queries, or does not support that kind of lookup.
• No RDAP server for the extension. Many country-code registries (the two-letter ones) have not set up RDAP yet. LookupOwl falls back to WHOIS on port 43 where it can, and labels the result as WHOIS.
• A thin answer. Some registries, such as Verisign for .com, hold only basic data. Contact details live at the registrar, which is why the second request matters.
• Odd JSON. Some servers send the wrong content type, leave out the conformance list or return an HTML error page. We show the problem and don't hide it.

How the right server is found

There is no single RDAP server, so a client has to find the right one. IANA, the body that coordinates the internet's names and numbers, publishes a bootstrap file at data.iana.org/rdap/dns.json. It maps each domain extension to one or more RDAP base URLs. The client takes the entry for the domain's last label, adds domain/<name> and sends the request over HTTPS. Separate bootstrap files cover IPv4, IPv6 and AS numbers.

LookupOwl keeps a fresh copy of those files, adds a small checked list for registries that run RDAP without being listed, and follows redirects only to servers it expects, never to private or reserved addresses.

Standards and specifications

• RFC 7480: how RDAP uses HTTP, including status codes and CORS.
• RFC 7481: security services for RDAP.
• RFC 9082: query URL formats. RFC 9083: JSON response objects.
• RFC 9224: the IANA bootstrap registry (replaces RFC 7484).
• RFC 7095: jCard, the JSON form of vCard used for contacts.
• RFC 9537: redacted fields. RFC 8605: ICANN vCard extensions for RDAP.