Registration Data Access Protocol (RDAP) Query Format
Extracted elements (31)
Base URLs are maintained in an IANA bootstrap registry (RFC 7484), and RDAP queries are formed by retrieving the appropriate base URL and appending a path segment. This separates the discovery of service endpoints from the query syntax.
Custom extensions use a namespacing scheme of prefixing path segments with a unique identifier and underscore to avoid interference with IETF-defined patterns both current and future.
RDAP was designed to address well-known WHOIS deficiencies: lack of standardized command structures and output formats, lack of internationalization and localization support, and lack of user identification, authentication, and access control.
The IP lookup semantics target the 'most-specific' or smallest IP network that completely encompasses the queried address or CIDR. A single address is treated as a /32 (IPv4) or /128 (IPv6) CIDR block for consistency.
The bootstrap registry does not contain information for query objects outside a global namespace (entities and help). For entities, the base URL must be retrieved from the service associated with the entity; RFC 8521 object tagging can overcome this limitation.
After parsing percent-encoding, an RDAP server treats each query string as Unicode in UTF-8 encoding. If a string is not valid UTF-8, the server can immediately return HTTP 400 (Bad Request).
An RDAP client submitting a query string with non-US-ASCII characters must convert to Unicode UTF-8 encoding, normalize using NFC, and then percent-encode the result for the query URL.
Clients SHOULD NOT submit a partial match search of Unicode characters where a Unicode character may be legally combined with another Unicode character or characters.
Clients that support queries for internationalized domain and nameserver names MUST accept service provider responses that describe variants as specified in RFC 9083.
For non-DNS string matching, servers use case-folded NFKC normalization (not NFC) to maximize predictability and number of matches. Storage of strings as Unicode is RECOMMENDED.
IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels in a domain query. A server receiving a mixed-label query MAY convert all U-labels to A-labels and proceed, or MAY refuse to process the query.
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 to indicate search is supported but this specific query cannot be processed.
Partial string searching uses an asterisk ('*') to match zero or more trailing characters. A partial string search MUST NOT include more than one asterisk.
Servers MUST return an appropriate failure status code for a request with an unrecognized path segment. Custom path segments are created by prefixing with a unique identifier followed by an underscore (0x5F).
Servers MUST return an HTTP 501 (Not Implemented) response to inform clients of unsupported query types. Server implementations are free to support only a subset of query features depending on local requirements.
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 ways that make partial matching unreliable.
The IPv6 zone_id (RFC 4007) is not appropriate in RDAP query context; the corresponding syntax extension in RFC 6874 MUST NOT be used, and servers SHOULD ignore it if present.
URL patterns specified in this document are only applicable to the HTTP GET and HEAD methods, because WHOIS services are read-only. No write or update operations are in scope.
URLs MUST be properly encoded according to the rules of RFC 3986. For example, spaces in search patterns must be percent-encoded (e.g., 'Bobby Joe*' becomes 'Bobby%20Joe*').
When constructing search responses involving associated records (e.g., IDN variants), the response must be filtered by privacy and data-releasing policies. There may not be a single static policy for all clients; client identity and authorization can determine the breadth of returned data.
Domain search supports three query forms: domains?name=<pattern> for name pattern matching, domains?nsLdhName=<pattern> for matching by delegated nameserver name, and domains?nsIp=<IP address> for matching by nameserver IP address.
Entity search supports two query forms: entities?fn=<name pattern> to match the entity 'fn' (full name) property, and entities?handle=<handle pattern> to match entity handle identifiers.
Nameserver search supports two query forms: nameservers?name=<pattern> for host name pattern matching and nameservers?ip=<IP address> for matching by resolved IP address.
The 'autnum' path segment looks up Autonomous System number registrations. Syntax is /autnum/<asplain AS number>; if the number falls within a registered block, the block registration is the target.
The 'domain' path segment queries domain information. Syntax is /domain/<fully qualified domain name> and supports both DNS reverse-zone names (in-addr.arpa, ip6.arpa) for RIRs and forward names for DNRs; IDNs in A-label or U-label format are valid.
The 'entity' path segment queries entity information (contacts, registrants, registrars) by handle identifier. Syntax is /entity/<handle>, where the handle syntax is specific to the registration provider.
The 'help' path segment requests server help information such as command syntax, terms of service, privacy policy, rate-limiting policy, supported authentication methods, and supported extensions. Syntax is simply /help.
The 'ip' path segment is used to look up IP networks and associated data. Syntax is /ip/<IP address> or /ip/<CIDR prefix>/<CIDR length>; the query targets the most-specific network completely encompassing the given address or block.
The 'nameserver' path segment queries nameserver information by fully qualified host name. Syntax is /nameserver/<nameserver name>; internationalized names in A-label or U-label format are accepted, following domain IDN processing rules.
Search functionality increases the privacy risk of disclosing object relationships not otherwise obvious; for example, returning IDN variants that do not explicitly match the search pattern can reveal information about registered domain names. Implementers must consider policy and privacy implications of returning unrequested information.
Search functionality requires significantly more server resources (memory, CPU, bandwidth) than basic lookup, increasing the risk of resource exhaustion and denial-of-service abuse. Mitigation includes restricting search to authenticated/authorized clients and rate limiting as described in RFC 7480.