Finding the Authoritative Registration Data Access Protocol (RDAP) Service
Extracted elements (27)
The bootstrap approach uses existing IANA allocation registries (IPv4, IPv6, AS numbers, root zone) as the source of truth, because IANA already maintains the authoritative delegation data. This avoids duplicating processes and keeps the RDAP bootstrap data consistent with allocation records.
The WEIRDS Working Group debated in-DNS lookup and other discovery mechanisms before settling on IANA-hosted JSON registries. IANA registries were chosen because IANA already maintains the underlying allocation data, and the method is simple for clients to implement without DNS dependencies.
The bootstrap method covers only domain names, IPv4/IPv6 address space, and AS numbers. It does not provide discovery for entities, search queries lacking a terminating string, nameservers, or help queries; implementers relying on this method must use alternative means for those object types.
All domain name labels used as entries or base RDAP URLs in the registries MUST be represented only in lowercase.
Any unrecognized JSON object properties or values MUST be ignored by implementations to ensure forward compatibility.
AS number ranges in the Bootstrap Service Registry for AS Number Space MUST NOT overlap.
Base RDAP URLs in the registries MUST have a trailing '/' character because they are concatenated with the path segments defined in RFC 9082.
Clients SHOULD NOT fetch the RDAP Bootstrap Service Registry on every RDAP request; they SHOULD cache the registry and use the HTTP Expires header field to determine when to refresh the cached copy.
Internationalized Domain Name labels used as entries or base RDAP URLs MUST be represented only in their A-label form as defined in RFC 5890.
JSON names in the registry MUST follow the format recommendations of Section 6 of RFC 7480.
Per RFC 7258, in each array of base RDAP URLs, the secure versions of the transport protocol SHOULD be preferred and tried first; if both HTTPS and HTTP URLs are present, the client SHOULD try HTTPS first.
RDAP Bootstrap Services Registries MUST be accessible only through HTTPS (TLS per RFC 8446) transport, as mandated in IANA considerations.
The HTTP Content-Type returned to clients accessing the JSON-formatted RDAP Bootstrap registries MUST be 'application/json' as defined in RFC 8259.
When the requested value is not found in any registry, the client SHOULD provide an appropriate error message to the user, as there is no known RDAP server for that value.
Authoritative RDAP servers for IP addresses are found via longest prefix match: addresses are converted to binary and the binary strings are compared up to the prefix length, exactly as in packet forwarding. This allows hierarchical delegation where a covering prefix and more-specific prefixes point to different RDAP servers.
Entities (contacts, registrants, registrars) can be queried by handle per RFC 9082, but since there is no global namespace for entities, this document does not define a bootstrap method for finding authoritative RDAP servers for entities. RFC 8521 object tagging MAY be used as an alternative.
The authoritative RDAP server for a domain name is found by a label-wise longest match of the target domain name against entries in the Bootstrap Service Registry for Domain Name Space, matching per label from right to left. If multiple entries tie for longest match, they are considered equivalent.
The Bootstrap Service Registry for AS Number Space contains entries as hyphen-separated AS number ranges in decimal (asplain per RFC 5396), e.g., '64512-65534'. A single AS is represented as a range of two identical numbers. AS number ranges MUST NOT overlap.
The Bootstrap Service Registry for IPv4 Address Space contains entries in CIDR format (RFC 4632), grouped by base RDAP URLs. Lookup uses longest-prefix match to identify the authoritative RDAP service for a queried IPv4 address or prefix.
The Bootstrap Service Registry for IPv6 Address Space contains IPv6 prefix entries using RFC 5952 text representation, grouped by base RDAP URLs. Lookup uses longest-prefix match to identify the authoritative RDAP service for a queried IPv6 address or prefix.
The RDAP Bootstrap Service Registry is a JSON object containing 'version', 'publication' (RFC 3339 timestamp), optional 'description', and a 'services' member. The services member is an array of two-element arrays, each pairing an Entry Array (registry keys) with a Service URL Array (base RDAP URLs).
IANA Bootstrap Service Registry for AS Number Space: maps ranges of Autonomous System numbers (asplain format) to base RDAP URLs. Entries are derived from IANA's AS Numbers registry.
IANA Bootstrap Service Registry for Domain Name Space: maps top-level domain labels attached to the root to base RDAP URLs. Entries are derived from the IANA Root Zone Database.
IANA Bootstrap Service Registry for IPv4 Address Space: maps CIDR-format IPv4 prefixes to base RDAP URLs. Entries are derived from IANA's IPv4 Address Space Registry and updated as allocations change.
IANA Bootstrap Service Registry for IPv6 Address Space: maps RFC 5952 IPv6 prefix entries to base RDAP URLs. Entries are derived from IANA's IPv6 Global Unicast Address Assignments and updated as allocations change.
By directing clients to RDAP registries served exclusively over TLS, the bootstrap method ensures end users obtain registration data from an authoritative source rather than a rogue one. The security properties of the bootstrap method are otherwise the same as for RDAP itself; additional RDAP security considerations are in RFC 7481.
The registry JSON structure nests three levels: the top-level 'services' array contains service arrays, each with two elements: an entry-list (array of strings) and a service-uri-list (array of URL strings). Elements within entry and URL arrays are not ordered.