RDAP lookup: build the query, then read the answer

What RDAP is

ICANN's glossary defines the Registration Data Access Protocol as "An HTTP-based protocol that provides access to information about current domain name registrations and Internet Protocol address allocations." It adds: "RDAP was designed as a replacement for the WHOIS protocol." The IETF finished the RDAP standards in March 2015, and ICANN told gTLD registries and registrars to run an RDAP service by 26 August 2019. ICANN lists what it gains over WHOIS: "Advantages of RDAP include secure data transmission via HTTPS, support for internationalization, and the ability to limit access to certain information about a registration."

Since 2025 it is the required channel for gTLDs: "All gTLD registries and registrars are required to provide RDAP services using the gTLD RDAP Profile, but as of 28 January 2025 they are no longer required to provide WHOIS services (except for .com, .name, and .post)." The WHOIS servers page lists the WHOIS and RDAP server of every TLD and counts which ones dropped WHOIS.

RDAP is not a website you visit. "RDAP is a protocol, not a website an entity can visit to access registration data." You use a client: a browser address bar, curl, a command-line tool, or ICANN's own, since "ICANN org maintains a publicly available RDAP client that runs inside a user's web browser." It is at lookup.icann.org. The tool below covers the two steps around a lookup, building the query and reading the answer, without sending anything: the builder uses copies of IANA's bootstrap files, and the reader works on JSON you paste.

How an RDAP query is built

RFC 9082 defines the paths. For domains it is "domain/<domain name>"; the others are "nameserver/<nameserver name>", "entity/<handle>", "ip/<IP address> or ip/<CIDR prefix>/<CIDR length>" and "autnum/<autonomous system number>". Internationalized names can be sent in either form, but "IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels;" the builder always sends the ASCII form. The path goes after a base URL, and "Base RDAP URLs MUST have a trailing "/" character because they are concatenated to the various segments defined in [RFC9082]."

The base URL comes from IANA's bootstrap files. For names, "The domain name's authoritative registration data service is found by doing the label-wise longest match of the target domain name with the domain values in the Entry Arrays" of the DNS file; for addresses, "The longest match is done the same way as in packet forwarding". When an entry lists both kinds of URL, "if the base RDAP URLs array contains both HTTPS and HTTP URLs, the bootstrap client SHOULD try the HTTPS version first". The DNS file published September 16, 2026 lists 1,202 TLDs under 591 services. ICANN's FAQ explains the point of this design: "Instead of returning a result such as "not available," a query will route to the authoritative server to return the relevant data."

Servers may pass you on. RFC 7480 says a server that knows where the data lives "will return a redirection response (3xx) with the Location header field containing an HTTP(S) URL pointing to the information or another server known to have knowledge of the location of the information", and a server that "does not have knowledge of where the information can be found, it returns a 404 response". The commands below add curl's -L option, which, per the curl manual, "makes curl redo the request to the new place". Registrar servers answer only for their own names: "A Registrar RDAP service MUST return an HTTP 404 response to a domain name request when the Registrar is not the Sponsoring Registrar for the domain name." And RFC 7480 is firm on transport: "Clients and servers MUST support HTTPS to support security services."

curl -L https://rdap.verisign.com/com/v1/domain/example.com
curl -L https://rdap.arin.net/registry/ip/192.0.2.1
curl -L https://rdap.db.ripe.net/autnum/3333

Reading an RDAP response

A domain answer is one JSON object, and the values in it come from IANA's RDAP JSON Values registry, updated June 4, 2025, which lists 36 status values, 12 event actions and 11 roles. Status values are the EPP codes in RDAP spelling, explained on the domain status codes page. Events carry the dates. IANA defines registration as "The object instance was initially registered." and expiration as "The object instance has been removed or will be removed at a predetermined date and time from the registry." Entities are the parties, each with a role; for the registrar role IANA writes "The entity object instance represents the authority responsible for the registration in the registry."

For generic TLDs, ICANN's RDAP Response Profile fixes the minimum, and "All gTLD registries and registrars are required to implement this version of the profile as of 21 August 2025." A domain answer needs registration and expiration events, an event for the last RDAP database update, a registrar entity whose handle is its IANA Registrar ID, an abuse contact with phone and email, a secureDNS member with at least a delegationSigned value, and two notices, "Status Codes" and "RDDS Inaccuracy Complaint Form". The reader checks each item. Registrar IDs are listed on the ICANN accredited registrars page.

Much of the registrant data is withheld, and RDAP says so in the answer. RFC 9537 "describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields"; IANA's registry names 17 such fields, including Registrant Name and Tech Email. The reader lists any it finds.

The example.com answer Verisign returned on September 27, 2026 shows what a gTLD record looks like: registrar RESERVED-Internet Assigned Numbers Authority with IANA ID 376, registered August 14, 1995, expiring August 13, 2027, the statuses client delete prohibited, client transfer prohibited and client update prohibited, two name servers and a signed delegation. Load it in the reader to see each field explained.

Sources and method

• IANA RDAP bootstrap files dns.json, ipv4.json, ipv6.json and asn.json, IANA RDAP JSON Values registry and IANA number resources, fetched September 27, 2026.
• ICANN: RDAP overview, RDAP FAQs, information for RDAP users, RDAP timeline, gTLD RDAP profile and its RDAP Response Profile; ICANN glossary: RDAP, fetched September 27, 2026.
• RFC 9082 (queries), RFC 9083 (responses), RFC 9224 (bootstrap), RFC 7480 (HTTP use), RFC 9537 (redaction) and RFC 8056 (status mapping).
• Example: Verisign RDAP answer for example.com, fetched September 27, 2026 and published here unchanged as rdap-example-com-20260927.json.
• Method: bootstrap matching follows RFC 9224 (label-wise longest match for names, longest prefix for addresses, range match for AS numbers, HTTPS first); each Regional Internet Registry is matched to its RDAP server by the web domain IANA lists for it. Every count is computed by script from the saved files.