Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search
Extracted elements (25)
For single-result link relations ('rdap-up', 'rdap-top'), a server may substitute a direct lookup URL for the search URL because both yield the same result at response generation time. However, if the database changes between response generation and client resolution, the results may differ; server operators should consider which approach best serves their clients.
'rdap-active' is defined only as a link relation, not as a URL <relation> value, because the only known use cases for status filtering involve 'rdap-up'/'rdap-top' combined with 'active' status. No other status link relations are defined.
The 'rirSearch1' path segment was introduced to provide a single namespace for all relation searches so that other searches can be independently defined under the top-level resource type path segments. The '1' suffix denotes version 1; new versions will use different identifiers. The remaining identifiers (ips, autnums, etc.) omit version suffixes for consistency with other core object classes.
Any document extending RDAP by using IP networks or ASNs as the searchable resource type in reverse searches must also implement the full functionality described in this document, because a given RDAP extension identifier must correspond to a single extension.
A server supporting this specification MUST include additional rdapConformance string literals in responses. Specifically: 'rirSearch1' and 'ips' for any IP network search link or request; 'ipSearchResults' for IP network search responses; 'rirSearch1' and 'autnums' for ASN searches; 'autnumSearchResults' for ASN search responses; and a /help response includes all five literals.
Server operators MAY opt not to support 'status' filtering for 'rdap-down' and 'rdap-bottom' relations, or for non-'active' status values for 'rdap-up' and 'rdap-top' relations. In those cases, the server MUST respond with HTTP 501 (Not Implemented).
Use of link relations (rdap-up, rdap-down, rdap-top, rdap-bottom, rdap-active) in responses is OPTIONAL. The absence of a link for a specific relation does not imply the corresponding search will return no results.
When constructing link objects for the defined relations, the server MUST use the corresponding search URL for the link target, or a URL that yields the same response as the corresponding search at the time of the request.
The search functionality defined in this document may affect the privacy of entities in the registry. Server operators should consult RFC 6973 and RFC 7481 for privacy threats specific to registration data. Many jurisdictions restrict use of Personal Data, and operators should ascertain whether their regulatory environment permits implementation of this functionality.
An optional 'status' query parameter filters relation search results as if objects without the specified status were removed from the database before processing. This is useful for finding active delegations while ignoring inactive or IANA-level allocations.
Autonomous system number search is performed via 'autnums?handle=<pattern>' or 'autnums?name=<pattern>'. Handle syntax is registration-provider-specific; name is assigned by the registration holder. Example: autnums?handle=AS1*.
IP network search is performed via 'ips?handle=<pattern>' or 'ips?name=<pattern>'. Handle is a registration-provider-specific identifier; name is assigned by the registration holder. Example: ips?handle=NET-199*.
Multiple-result searches ('rdap-down', 'rdap-bottom') return results in an array: 'ipSearchResults' for /ips searches containing ip network object instances, and 'autnumSearchResults' for /autnums searches containing autnum object instances, per RFC 9083.
Relation search URLs use the form '<resource type search path segment>/rirSearch1/<relation>/<object value>[?status=<status>]'. The 'rirSearch1' path segment provides a single namespace for relation searches, allowing other searches to be defined under the top-level path segments.
Reverse search (RFC 9536) is extended to cover IP networks and ASNs. A reverse search with searchable resource type 'ips' operates on IP network objects; resource type 'autnums' operates on autonomous system number objects.
The hierarchy model defines four relations for INR objects: 'parent' (next-least-specific covering object), 'child' (next-most-specific objects), 'top' (least-specific covering object), and 'bottom' (most-specific objects that entirely cover the INR value). Bottom objects may overlap and may be less specific than the queried value.
The 'rdap-active' link relation denotes a relation search filtered for status 'active'. It is used only as a link relation in link objects combined with 'rdap-up' or 'rdap-top' (e.g., rel='rdap-up rdap-active'), and cannot be used as a <relation> value in relation search URLs.
The 'rdap-bottom' relation is a multiple-result search that returns the most-specific objects entirely covering the specified INR object value. If no such objects exist, an empty search response is returned.
The 'rdap-down' relation is a multiple-result search that returns only immediate child objects for the specified INR object value. If no such objects exist, an empty search response is returned.
The 'rdap-top' relation is a single-result search that returns the least-specific covering object (the top of the hierarchy) for the specified INR object value. If no such object exists, the server responds with HTTP 404.
The 'rdap-up' relation is a single-result search that returns the parent object for the specified INR object value, as if requested directly via a lookup URL. If no parent exists, the server responds with HTTP 404.
Two new resource type path segments are defined for basic search: 'ips' for IP network searches and 'autnums' for autonomous system number searches. Search patterns support exact match or trailing wildcard using '*' (ASCII 0x2A) as defined in RFC 9082 Section 4.1.
IANA has registered five new entries in the 'Link Relations' registry: 'rdap-up' (parent object), 'rdap-down' (child objects), 'rdap-top' (topmost parent), 'rdap-bottom' (leaf child objects), and 'rdap-active' (filter for active status), all specified by RFC 9910.
IANA has registered four entries in the 'RDAP Reverse Search Mapping' registry specifying JSON Path expressions for IP/ASN reverse search properties: 'fn' maps to $.entities[*].vcardArray[1][?(@[0]=='fn')][3]; 'handle' to $.entities[*].handle; 'email' to $.entities[*].vcardArray[1][?(@[0]=='email')][3]; 'role' to $.entities[*].roles.
RFC 7481 describes security requirements for RDAP generally. TLS guidance has been updated since RFC 7481; implementers should follow RFC 8446 and BCP 195. Security considerations from RFC 9082 regarding object retrieval also apply to the searches defined here.