Finding the Authoritative Registration Data (RDAP) Server
draft-blanchet-weirds-bootstrap-autonomous-00.txt

Abstract

This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses or Autonomous System numbers.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 24, 2014.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Domain Name Registry
• 3. Internet Numbers Registry
• 3.1. IPv4 Address Space
• 3.2. IPv6 Address Space
• 3.3. Autonomous Systems
• 4. Nameserver
• 5. Entity
• 6. SRV Records Processing
• 7. Querying to the Authoritative Server
• 8. Deployment Considerations
• 9. Assumptions and Limitations
• 10. Security Considerations
• 11. IANA Considerations
• 12. Acknowledgements
• 13. References
• 13.1. Normative References
• 13.2. Informative References
• Author's Address

1. Introduction

Querying and retrieving registration data from registries are defined in the Registration Data Access Protocol(RDAP)[I-D.ietf-weirds-rdap-query][I-D.ietf-weirds-using-http][I-D.ietf-weirds-json-response]. 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.

2. Domain Name Registry

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 [RFC2782].

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[RFC5891].

3. Internet Numbers Registry

The authoritative source is a file[NROFILE] 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).

3.1. IPv4 Address Space

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.

3.2. IPv6 Address Space

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.

3.3. Autonomous Systems

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.

4. Nameserver

TBD

5. Entity

TBD

6. SRV Records Processing

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

7. Querying to the Authoritative Server

After finding the authoritative server IP address, the client connects using the appropriate transport and application protocol to do the RDAP query[I-D.ietf-weirds-rdap-query].

8. Deployment Considerations

Caching and Updating considerations (TBD)

RDAP server operators may use various techniques such as anycast[RFC4786] to manage the load on their servers.

9. Assumptions and Limitations

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.

10. Security Considerations

TBD

11. IANA Considerations

none at the moment.

12. Acknowledgements

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).

13. References

13.1. Normative References

13.2. Informative References

Author's Address