Finding the Authoritative Registration Data (RDAP) Service
obsoleted by
- rfc-9224 — Finding the Authoritative Registration Data Access Protocol (RDAP) Service
updated by
- rfc-8521 — Registration Data Access Protocol (RDAP) Object Tagging
Extracted elements (25)
Clients cache the Bootstrap Registries and use HTTP Expires to limit fetch frequency, rather than querying IANA on every RDAP lookup, because registry download demand from software could be unusually high compared to normal IANA registries; caching reduces load on IANA servers while keeping data timely.
IP address lookup uses the same longest-match algorithm as routing (binary string comparison up to prefix length) because this naturally handles hierarchical delegation where covering prefixes point to one RDAP server while more specific sub-prefixes are served by another.
The bootstrap information for RDAP clients is generated from IANA's existing allocation registries (IPv4, IPv6, AS numbers, domain names) because TLDs, AS numbers, and network blocks are delegated by IANA, making IANA the authoritative and natural source. This avoids creating a parallel infrastructure.
Entities (contacts, registrants, registrars) can be queried by handle per RFC 7482, but there is no global namespace for entities; therefore, this document does not define a bootstrap method for entity lookups. An entity handle received from a prior RDAP query may be requeried at the same server, or a fully referenced URL may be used directly.
This bootstrap method does not cover entities, nameservers, help queries, or search-pattern queries that do not contain a terminating string matching registry entries. Implementors must use alternative means (e.g., RDAP aggregators or redirectors) for these object types.
When a new object is allocated (new AS range, TLD, or IP address range), there is no guarantee its entry will appear promptly in the corresponding bootstrap registry; the RDAP server setup may go live and be registered later. Clients must tolerate missing entries for newly allocated objects.
All Domain Name labels used as entries or base RDAP URLs in the registries defined in this document MUST be represented only in lowercase.
Base RDAP URLs MUST have a trailing '/' character because they are concatenated to the various path segments defined in RFC 7482.
Internationalized Domain Name labels used as entries or base RDAP URLs in these registries MUST be represented only using their A-label form as defined in RFC 5890.
JSON names in the registry MUST follow the format recommendations of RFC 7480. Any unrecognized JSON object properties or values MUST be ignored by implementations.
Per RFC 7258, in each array of base RDAP URLs the secure transport versions SHOULD be preferred and tried first. If both HTTPS and HTTP URLs are present, the bootstrap client SHOULD try HTTPS first.
RDAP clients SHOULD NOT fetch the Bootstrap Registry on every RDAP request. Clients SHOULD cache the registry and rely on the HTTP Expires header field (RFC 7234) to determine when to refresh it.
The HTTP Content-Type returned to clients accessing JSON-formatted RDAP Bootstrap Services Registries MUST be 'application/json' as defined in RFC 7159.
When a requested value is not present in the registry (no matching entry), there is no known RDAP server for that value, and the client SHOULD provide an appropriate error message to the user.
AS number lookups match against inclusive ranges expressed as 'LOW-HIGH' decimal strings in the Bootstrap Registry for AS Number Space. A single AS number is encoded as a range of two identical values (e.g., '2045-2045').
Domain name lookups use label-wise longest match of the target domain name against domain values in the Bootstrap Registry for Domain Name Space. Matching is done per label, from right to left; if the longest match yields multiple entries they are treated as equivalent. The root of the domain name space is represented as the empty string "".
IPv4 address space lookups use longest prefix match against CIDR [RFC 4632] entries in the Bootstrap Registry for IPv4 Address Space. Addresses are converted to binary form and compared bit-by-bit up to the prefix length, mirroring routing longest-match semantics.
IPv6 address space lookups use longest prefix match against entries in RFC 4291 text-representation format in the Bootstrap Registry for IPv6 Address Space. If the primary URL fails to respond, the client may try another URL from the Service URL Array.
The RDAP Bootstrap Service Registry is a JSON object with members: 'version' (string, currently '1.0'), 'publication' (RFC 3339 date/time string), optional 'description' (string), and 'services' (array). Each services entry is a two-element array: an Entry Array of scope strings and a Service URL Array of base RDAP URLs.
IANA Bootstrap Service Registry for AS Number Space: each entry contains a range of Autonomous System numbers and one or more RDAP service URLs. Generated from the IANA Autonomous System Numbers registry.
IANA Bootstrap Service Registry for Domain Name Space: each entry contains a domain name attached to the root (a TLD label) and one or more RDAP service URLs. Generated from the IANA Root Zone Database.
IANA Bootstrap Service Registry for IPv4 Address Space: each entry contains a CIDR [RFC 4632] specification of the network block and one or more RDAP service URLs. Generated from and kept in sync with the IANA IPv4 Address Space Registry.
IANA Bootstrap Service Registry for IPv6 Address Space: each entry contains an IPv6 prefix [RFC 4291] specification of the network block and one or more RDAP service URLs. Generated from the IANA IPv6 Global Unicast Address Assignments registry.
By directing RDAP clients to authoritative servers via IANA-maintained registries, the bootstrap method helps ensure users receive RDAP data from authoritative sources rather than rogue ones. The registries can be accessed via TLS for additional transport security, and the overall security properties are the same as those of the RDAP protocols themselves (see RFC 7481).
The registry JSON object contains: 'version' (STRING, value '1.0'), 'publication' (STRING, RFC 3339 format), optional 'description' (STRING), and 'services' (ARRAY of service arrays). Each service is a 2-element ARRAY: an entry-list ARRAY of STRING scope values and a service-uri-list ARRAY of STRING base URLs.