Registration Data Access Protocol (RDAP) Query Format
obsoleted by
- rfc-9082 — Registration Data Access Protocol (RDAP) Query Format
Extracted elements (27)
For server-side string matching, NFKC (Normalization Form KC) with case folding is used rather than NFC to maximize predictability and the number of matches. This differs from the NFC used by clients when submitting queries, a deliberate choice to broaden server-side matching.
RDAP query URLs are restricted to HTTP GET and HEAD methods only, reflecting that WHOIS services are inherently read-only. Resource management, provisioning, and update functions are explicitly out of scope because registries have divergent methods for these functions and uniform interoperability is not needed.
The bootstrap registry (RFC 7484) does not contain information for query objects outside a global namespace (such as entities and help), because a base URL for an associated service is required to construct a meaningful query for these objects. Clients must derive the base URL from a related service lookup.
A server receiving a domain query with a mixture of A-labels and U-labels MAY convert all U-labels to A-labels and perform IDNA processing for exact-match lookup, though the response may not match the original input form; alternatively the server MAY refuse to process the query.
RDAP query results may include associated records (such as IDN variants) beyond exact matches, filtered by server privacy and data-release policies. Client identity and authorization may determine the breadth of returned data, meaning different clients may receive different response sets for the same query.
An RDAP client submitting a query string containing non-US-ASCII characters converts such strings into Unicode in UTF-8 encoding, normalizes using NFC (Normalization Form C), then percent-encodes per RFC 3986. Storage of strings as Unicode is RECOMMENDED.
Clients that support queries for internationalized domain and nameserver names MUST accept service provider responses that describe variants as specified in RFC 7483 (JSON Responses for RDAP).
IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels in domain queries; all internationalized labels in an IDN SHOULD be either all A-labels or all U-labels to avoid ambiguity when assembling queries from multiple data sources.
If a server cannot process a search request because it does not support a particular style of partial match searching, it SHOULD return an HTTP 422 (Unprocessable Entity) response, optionally with an error response body per RFC 7483.
Servers MUST return an appropriate failure status code for requests with unrecognized path segments, including unrecognized custom extension path segments.
Servers MUST return an HTTP 501 (Not Implemented) response to inform clients of unsupported query types. This allows partial server implementations that support only a subset of RDAP query features.
Servers SHOULD NOT partially match combinations of Unicode characters where a legal combination is possible, because Unicode characters can be combined with each other in many ways, making partial matching unreliable.
The IPv6 zone_id (RFC 4007) MUST NOT be used in IP network path segments, as it is not appropriate in this context; servers are to ignore it if possible. RFC 5952 text representation rules for IPv6 addresses are RECOMMENDED.
URLs MUST be properly encoded according to the rules of RFC 3986. For example, spaces in entity search patterns must be percent-encoded (e.g., 'Bobby Joe*' becomes 'Bobby%20Joe*').
Autonomous System number lookup syntax is 'autnum/<autonomous system number>', where the AS number is in asplain format per RFC 5396. If a number falls within a registered block, the query targets the block; individual registrations are treated as blocks of size 1.
Custom path segments for non-standard objects are created by prefixing the segment with a unique identifier followed by an underscore (0x5F), for example 'custom_entity'. This namespacing prevents conflicts with current and future IETF-defined RDAP path segments.
Domain lookup syntax is 'domain/<domain name>', accepting fully qualified domain names in in-addr.arpa or ip6.arpa zones (for RIRs) or zones administered by the server (for DNRs). IDNs in either A-label or U-label format per RFC 5890 are also valid.
Domain search supports three query parameters: 'name' (match by domain name LDH pattern), 'nsLdhName' (match by delegated nameserver name), and 'nsIp' (match by nameserver IP address). U-label format is also accepted for name-based searches.
Entity lookup syntax is 'entity/<handle>', where the handle is a registration-provider-specific identifier for contacts, registrants, or registrars. For some DNRs, contact identifiers follow RFC 5730/5733 (EPP).
Entity search supports two query parameters: 'fn' (match by entity full name, the 'FN' property per RFC 7483 Section 5.1) and 'handle' (match by entity handle/identifier). Example: 'entities?fn=Bobby%20Joe*'.
IP network lookup syntax is 'ip/<IP address>' or 'ip/<CIDR prefix>/<CIDR length>', supporting both IPv4 dotted-decimal and IPv6 (RFC 5952) formats. The query targets the most-specific IP network that completely encompasses the given address or CIDR block.
Nameserver search supports two query parameters: 'name' (match by nameserver host name in LDH or U-label format) and 'ip' (match by IPv4 or IPv6 address). Search syntax follows 'nameservers?name=XXXX' or 'nameservers?ip=YYYY'.
Partial string searching uses the asterisk ('*', 0x002A) character to match zero or more trailing characters. A character string representing multiple domain name labels MAY be concatenated to the end of the search pattern to limit scope (e.g., 'exam*.com' matches 'example.com').
RDAP defines five lookup path segments for exact-match queries: 'ip' (IP networks), 'autnum' (Autonomous System numbers), 'domain' (reverse DNS or domain names), 'nameserver' (nameserver host names), and 'entity' (contact/registrant/registrar identifiers). A sixth segment 'help' retrieves server capability information.
RDAP defines three search path segments using plural forms: 'domains' (search domain names), 'nameservers' (search nameservers), and 'entities' (search entities). Search queries are formed as HTTP query strings appended to the plural segment, e.g., 'domains?name=example*.com'.
Search functionality increases privacy risk by potentially disclosing object relationships not otherwise obvious, such as returning IDN variants (RFC 6927) that do not explicitly match a client's search pattern. Implementers must consider policy and privacy implications of returning information not explicitly requested.
Search functionality requires significantly more server resources than basic lookup (memory, CPU, bandwidth), increasing denial-of-service risk. Mitigations include restricting search to authorized clients, suspending or revoking search privileges for misbehaving clients, rate limiting per RFC 7480 Section 5.5, and restricting the amount of information returned.