RDAP is a directory protocol, not a universal database
How RDAP finds a service, constructs a query, and returns policy-dependent registration data.
RDAP is the standards-based successor to WHOIS for internet registration data. It provides a structured HTTP interface, but it is not one central database and it does not create a single global statement of fact. Domain registries, regional internet registries, and other operators publish records for the resources they manage. The result of a lookup is therefore a response from one particular service, under that service’s current policy, at a particular time.
The protocol separates three jobs that are easy to conflate: finding the appropriate service, forming a request to that service, and interpreting the JSON it returns. Those jobs are specified in RFC 9224, RFC 9082, and RFC 9083, respectively.
Finding the right service
The first problem is discovery. RFC 9224 defines a method for finding the RDAP service designated to answer a query for a domain, IP address, or autonomous system number. It uses IANA’s RDAP bootstrap service registries rather than a hard-coded directory of providers.
IANA publishes separate machine-readable registries for domain names, IPv4 address space, IPv6 address space, and autonomous system numbers. The IANA RDAP bootstrap directory lists the current files. Each registry maps identifiers or ranges to one or more base RDAP URLs.
For a domain, a client compares labels from right to left and chooses the most specific matching suffix. A lookup for www.example.com, for example, can match com or a more specific delegated suffix if IANA has one. For an IP address, the client uses a longest-prefix match, much like IP routing. For an ASN, it finds the range containing the requested number. The outcome is a base URL for a service, not a copied registration record.
Bootstrap discovery identifies the service that IANA’s registry directs the client to for that scope. It does not promise that every field returned to an anonymous public client is complete, accurate for a legal purpose, or legally authoritative. It also does not cover every possible RDAP object: RFC 9224 does not provide a global bootstrap mechanism for entities, nameserver searches, or help queries.
Constructing a lookup
Once it has a base URL, a client applies the uniform query patterns in RFC 9082. Exact lookups use path segments such as:
/domain/example.com
/ip/192.0.2.1
/ip/2001:db8::1
/autnum/64496The service URL and path form the request URL. RFC 9082 also defines search paths for some object types, but a service may support only a subset of them and may apply its own access, rate, or privacy controls. A successful HTTP request is not a guarantee that two services will expose the same fields for comparable resources.
Reading a response
RFC 9083 defines the common JSON structures used in RDAP responses. It describes object classes for domains, IP networks, autonomous system numbers, entities, and nameservers, plus shared fields for status, events, links, notices, and remarks. It also permits extensions: clients are expected to tolerate members they do not recognize.
The standard deliberately leaves room for local policy. Some response members are optional, and services may omit or redact public data based on privacy rules, authorization, or their own operating policy. Notices and remarks are part of the response model, so they should be read alongside the fields they qualify.
For example, the Public Interest Registry response for rdaplookup.org says its RDAP service is provided for informational purposes, does not guarantee accuracy, and is not considered authoritative for registered domain objects. That qualification comes from the selected public service itself; it is a reminder that locating the designated RDAP endpoint and establishing the legal status of the response are different questions.
What this site shows
This site uses IANA bootstrap data to locate the designated RDAP service, then sends the request from your browser directly to that service. It displays a compact reading of common fields so that the response is easier to scan, while preserving the returned JSON and the service URL for inspection.
The raw response is the original record returned for this lookup. Read the service’s notices, remarks, linked policies, and terms when the data will be used for a consequential or legal purpose.