Finding the Authoritative Registration Data (RDAP) Server

Querying and retrieving registration data from registries are defined in the Registration Data Access Protocol(RDAP). These documents do not specify where to send the queries. This document specifies a method to find which server is authoritative to answer queries for the requested scope. (author note: should it have some text on various possibilities that have been discussed, such as IETF84...?) This document proposes two different mechanisms depending on the type of the queried object. For IP addresses and autonomous system numbers, the method uses a Number Resource Organization(NRO) managed registry of allocations. For domain names, the method uses a well-known label in the top of the registry. Both use the same DNS resource record(RR) which is used to locate the RDAP server. The processing of the RR is discussed later in this document. It should be noted that the document currently uses SRV as an example and it is underspecified. When the concensus is reached on the method and the RR, the draft will be updated accordingly with the appropriate details.

The domain names authoritative registration data servers are found by extracting the tld part of the queried domain name and then querying _rdap._tcp.tld with a DNS resource record of type SRV . For example, a RDAP query for example.com generates a DNS SRV query to _rdap._tcp.com. IDN labels are in their A-label form.

The authoritative source is a file containing the allocations of IP addresses and Autonomous System (AS) numbers for all (currently five) Regional Internet Registries(RIR). It is compiled and maintained by the Number Resource Organization(NRO). The current format is a list of rows, where each column is separated by "|" (ASCII 0x7c). The third column contains the type of the object and the fourth column contains the value of the object. The current format does not list the URL of the RDAP server related to the queried resource. However, it has been said that it can be augmented to provide that information. The file is currently large(19Moctets, 300K lines) and should not be queried by clients every time. The average number of lines changed every day is currelty around 100. However, there are days when 95K lines were changed. The file should be cached and regularly updated. (author note: more to discuss on the updating/caching).

The IPv4 address space authoritative registration data servers are found in the file by looking for the type "ipv4" (currently in 3rd column) and doing a longest match on the queried prefix. The column X (not currently available) provides the fully-qualified domain name(FQDN) of the RDAP server for that prefix. For example, a query for 192.9.200.0/24 looks for the longest match prefix in the file and then fetch the fully-qualified domain name(FQDN) of that prefix, for example: rdap.rirexample.net. A DNS SRV record is then queried for the FQDN.

The IPv6 address space authoritative registration data servers are found in the file by looking for the type "ipv6" (currently in 3rd column) and doing a longest match on the queried prefix. The column X (not currently available) provides the fully-qualified domain name(FQDN) of the RDAP server for that prefix. For example, a query for 2001:db8::/32 looks for the longest match prefix in the file and then fetch the fully-qualified domain name(FQDN) of that prefix, for example: rdap.rirexample.net. A DNS SRV record is then queried on the FQDN.

The Autonomous Systems (AS) authoritative registration data servers are found in the file by looking for the type "asn" (currently in 3rd column) and doing an exact match on the queried number. The column X (not currently available) provides the fully-qualified domain name(FQDN) of the RDAP server for that AS. For example, a query for AS 65411 looks for the exact match AS in the file and then fetch the fully-qualified domain name(FQDN) of that prefix, for example: rdap.rirexample.net. A DNS SRV record is then queried on the FQDN.

TBD

TBD. The other RR choices are: A, AAAA, CNAME, NAPTR. See discussion in IETF87 for details.

After finding the authoritative server IP address, the client connects using the appropriate transport and application protocol to do the RDAP query.

Caching and Updating considerations (TBD) RDAP server operators may use various techniques such as anycast to manage the load on their servers.

This specification assumes that the NRO is the authoritative source of the IPv4, IPv6 and AS numbers allocations, and that it keeps the file updated. This specification only provides a method to find RDAP servers for two-labels domain names.

TBD

none at the moment.

The weirds working group had multiple discussions on this topic, including a session during IETF 84 and 87. The ideas in this draft were proposed during the IETF 87 weirds session by (TBD).