What Is RDAP? The Registration Data Access Protocol Explained

What RDAP is

The Registration Data Access Protocol (RDAP) is an IETF standard for asking an Internet registry what it knows about a resource it manages. Domain name registries (Verisign for .com, for example) and registrars run RDAP servers. A client sends an ordinary HTTPS request for a domain name, a name server or a contact, and the server answers with a JSON document: who the domain is registered through, when it was created and when it expires, which status codes apply, and which contacts and name servers are attached. The same protocol is also used by the five Regional Internet Registries to publish IP address and AS number registrations.

RDAP was designed by the IETF's WEIRDS working group as the successor to WHOIS, and the first RDAP RFCs were published in March 2015. It answers the same question WHOIS always has — who is behind this domain name? — but in a form that both people and software can rely on.

Why RDAP replaced WHOIS

WHOIS (RFC 3912) dates from the early days of the Internet. A client opens a TCP connection to port 43, sends a line of text and gets free-form text back. The specification defines nothing else: not the query syntax, not the field names, not the character encoding, not how to report errors. Every registry filled those gaps differently, so WHOIS clients need a separate parser for almost every registry. RDAP fixes this:

• Structured JSON. Every response uses the same members — events, entities, status, nameservers — so an expiry date is always an event with eventAction "expiration", whether the registry's WHOIS calls it “Registry Expiry Date”, “paid-till” or “Expiration Time”.
• Standard queries and errors. Lookups are plain URLs such as /domain/example.com, and errors use HTTP status codes: 404 when the object does not exist, 429 when you are sending too many requests.
• HTTPS. Queries and answers are encrypted, the server proves its identity with a TLS certificate, and ordinary web infrastructure such as caches and redirects just works.
• Internationalization. Responses are UTF-8 JSON, and internationalized domain names are returned in both their ASCII form (ldhName) and their Unicode form (unicodeName).
• Differentiated access. A server can authenticate a client and decide how much to return: anonymous users get a redacted record, an authorized party can be shown more.
• Bootstrapping. IANA publishes a machine-readable file that maps each TLD to the right RDAP server. WHOIS has no standardized, machine-readable way to find the right server: clients hard-code server lists or follow referrals from whois.iana.org.

For a point-by-point comparison, see RDAP vs WHOIS.

The RDAP standards (RFCs)

RDAP is defined by a small set of IETF documents. RFC 7480, 7481, 9082, 9083 and 9224 together form Internet Standard STD 95. RFC 9082, 9083 and 9224 (2021–2022) replaced the original 2015 documents, so read those if you are implementing RDAP.

How an RDAP query works

Here is what happens when you look up google.com, step by step.

1. Find the TLD. The top-level domain of google.com is .com.
2. Find the server in the IANA bootstrap file. IANA publishes https://data.iana.org/rdap/dns.json (RFC 9224). Its services array pairs lists of TLDs with the base URLs of their RDAP servers; the entry for .com points to Verisign. Clients cache this file and refresh it now and then.
3. Build the URL. Append domain/ and the domain name to the base URL: https://rdap.verisign.com/com/v1/domain/google.com. Internationalized names are converted to their ASCII “A-label” form first, so bücher.example becomes xn--bcher-kva.example.
4. Send an HTTPS GET request with the header Accept: application/rdap+json.
5. Read the answer. 200 carries the JSON record; 404 means the registry has no such object, usually because the name is not registered; 429 means slow down; a 3xx redirect points to another server that holds the data.

An excerpt of the bootstrap file, trimmed to the two Verisign entries:

{
  "version": "1.0",
  "services": [
    [["com"], ["https://rdap.verisign.com/com/v1/"]],
    [["net"], ["https://rdap.verisign.com/net/v1/"]]
  ]
}

W.is skips step 2 at lookup time: it keeps a built-in list of registry RDAP endpoints generated from IANA's data (the RDAP server list) and converts internationalized names to A-labels for you.

Reading an RDAP response

Below is a trimmed version of the registry's response for google.com, with notices, links and several fields removed. Values change over time, so run the lookup to see the live record.

{
  "objectClassName": "domain",
  "handle": "2138514_DOMAIN_COM-VRSN",
  "ldhName": "GOOGLE.COM",
  "status": [
    "client delete prohibited",
    "client transfer prohibited",
    "client update prohibited",
    "server delete prohibited",
    "server transfer prohibited",
    "server update prohibited"
  ],
  "events": [
    { "eventAction": "registration", "eventDate": "1997-09-15T04:00:00Z" },
    { "eventAction": "expiration", "eventDate": "2028-09-14T04:00:00Z" },
    { "eventAction": "last changed", "eventDate": "2019-09-09T15:39:04Z" }
  ],
  "entities": [
    {
      "objectClassName": "entity",
      "handle": "292",
      "roles": ["registrar"],
      "publicIds": [{ "type": "IANA Registrar ID", "identifier": "292" }],
      "vcardArray": ["vcard", [
        ["version", {}, "text", "4.0"],
        ["fn", {}, "text", "MarkMonitor Inc."]
      ]],
      "entities": [
        {
          "objectClassName": "entity",
          "roles": ["abuse"],
          "vcardArray": ["vcard", [
            ["version", {}, "text", "4.0"],
            ["fn", {}, "text", ""],
            ["email", {}, "text", "[email protected]"]
          ]]
        }
      ]
    }
  ],
  "nameservers": [
    { "objectClassName": "nameserver", "ldhName": "NS1.GOOGLE.COM" },
    { "objectClassName": "nameserver", "ldhName": "NS2.GOOGLE.COM" }
  ],
  "secureDNS": { "delegationSigned": false },
  "rdapConformance": ["rdap_level_0"]
}

• objectClassName says what kind of object this is, such as domain, nameserver or entity.
• handle is the registry's internal ID; ldhName is the ASCII (“letters, digits, hyphen”) name, and IDNs add a unicodeName.
• status lists the domain's status values. RDAP writes them as words (“client transfer prohibited”) where EPP and WHOIS use camelCase (clientTransferProhibited); RFC 8056 defines the mapping. Every value is explained in our domain status code reference.
• events is the timeline: registration, expiration, last changed and often last update of RDAP database, all in UTC. See how to check a domain's expiration date.
• entities are the contacts, each with one or more roles: registrar, registrant, administrative, technical, abuse. Details are encoded as jCard (RFC 7095), a JSON form of vCard; the registrar carries its IANA ID in publicIds and nests its abuse contact.
• nameservers lists the delegated name servers, and secureDNS shows whether the delegation is signed with DNSSEC.
• rdapConformance lists the specifications and extensions the response follows; notices (removed above) carry the terms of use.

Registry and registrar records can differ. For .com and .net, the registry does not hold registrant contact data at all; its response usually links (with rel "related") to the registrar's own RDAP record for the domain, which is where any published registrant details appear. Our guide on finding a domain owner covers what you can expect to see there.

RDAP and ICANN: key dates

• March 2015 — the first RDAP RFCs (7480 to 7484) are published.
• August 26, 2019 — ICANN requires all generic TLD registries and registrars to operate RDAP.
• June 2021 and March 2022 — the revised RFC 9082, 9083 and 9224 are published, and RDAP becomes Internet Standard STD 95.
• January 28, 2025 — gTLD registrars and most gTLD registry operators are no longer contractually required to run WHOIS. RDAP becomes the definitive source of gTLD registration data, and many operators have since switched their WHOIS servers off.

Country-code TLDs are not bound by ICANN's gTLD contracts and decide for themselves. W.is currently has RDAP endpoints for 1,207 of 1,435 active TLDs — 1,126 of 1,128 generic TLDs and 81 of 306 country-code TLDs. The TLD list shows what each one supports.

How to run an RDAP lookup

With W.is

Type a domain name into the search box at the top of this page, or go straight to an address such as w.is/google.com. W.is picks the registry's RDAP server, falls back to WHOIS when needed, and shows a readable summary with the raw response underneath, labeled with its source.

From the command line

Any HTTP client works, including a browser tab. With curl:

curl -s -H "Accept: application/rdap+json" \
  https://rdap.verisign.com/com/v1/domain/google.com

Add jq to pull out a single value, such as the expiration date:

curl -s -H "Accept: application/rdap+json" \
  https://rdap.verisign.com/com/v1/domain/google.com \
  | jq -r '.events[] | select(.eventAction == "expiration") | .eventDate'

In scripts, cache the bootstrap file, send names as A-labels and back off on HTTP 429.

Frequently asked questions

Is RDAP free to use?

Yes. Public RDAP servers run by domain registries and registrars answer anonymous HTTPS requests without an account or API key. They do apply rate limits, so automated tools should cache results and slow down when a server returns HTTP 429 (Too Many Requests).

Does RDAP show who owns a domain?

Usually not in full. Most generic TLD records redact the registrant's name, email address, phone number and street address for privacy. You will normally see the registrar, the key dates, status codes and name servers, and often the registrant's state or province and country.

Does every top-level domain support RDAP?

All generic TLDs under contract with ICANN must provide RDAP. Country-code TLDs set their own rules, and many still offer only WHOIS. W.is currently has RDAP endpoints for 1,126 of 1,128 active generic TLDs and 81 of 306 country-code TLDs, and uses WHOIS where it has no RDAP endpoint or the RDAP server fails.

Why does an RDAP server return 404 for a domain?

HTTP 404 Not Found means the registry has no record of that name, which usually means it is not registered. Reserved or blocked names can also return 404 even though they cannot be registered, and you will get 404 if you ask a server that does not handle that TLD.

Related guides

• RDAP vs WHOIS — a side-by-side comparison and when you still need WHOIS.
• RDAP server list — every registry RDAP endpoint W.is queries, grouped by server.
• Domain status codes — what each EPP and RDAP status value means.
• TLD list — all top-level domains with their RDAP and WHOIS servers.
• Find a domain owner — what registration data reveals and how to reach the owner.
• WHOIS server list — the port-43 server for every TLD, used where RDAP is not available.