Network Working Group M. Blanchet Internet-Draft Viagenie Intended status: Informational June 04, 2013 Expires: December 06, 2013 Finding the Authoritative Registration Data (RDAP) Server draft-blanchet-weirds-bootstrap-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 December 06, 2013. 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. Blanchet Expires December 06, 2013 [Page 1] Internet-Draft Finding Authoritative RDAP server June 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Domain Name Registry . . . . . . . . . . . . . . . . . . . . 2 3. Internet Numbers Registry . . . . . . . . . . . . . . . . . . 3 3.1. IPv4 Address Space . . . . . . . . . . . . . . . . . . . 3 3.2. IPv6 Address Space . . . . . . . . . . . . . . . . . . . 3 3.3. Autonomous Systems . . . . . . . . . . . . . . . . . . . 3 4. Nameserver . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. A and AAAA Queries . . . . . . . . . . . . . . . . . . . . . 4 7. Processing NXDOMAIN Considerations . . . . . . . . . . . . . 4 8. Querying to the Authoritative Server . . . . . . . . . . . . 4 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 10. Security Considerations . . . . . . . . . . . . . . . . . . . 5 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 13.1. Normative References . . . . . . . . . . . . . . . . . . 6 13.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 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...?) The proposed mechanism starts with a well-known domain suffix (rdap.arpa) managed by IANA. Below the suffix, each scope is delegated to the entity responsible for the registration data. A RDAP client constructs a DNS query based on the scope of the user query and receives from the DNS the address(es) of the servers to contact to send the registration data query using the RDAP protocol. The use of DNS provides the scaling and delegation properties needed for this large scale registration data access. 2. Domain Name Registry The domain names authoritative registration data servers are found by concatenating the queried FQDN to the domain suffix: Blanchet Expires December 06, 2013 [Page 2] Internet-Draft Finding Authoritative RDAP server June 2013 "domain.rdap.arpa." and then generating DNS address queries for that concatenated domain. For example, a RDAP query for example.com generates a DNS request to example.com.domain.rdap.arpa. IDN labels are in their A-label form[RFC5891]. 3. Internet Numbers Registry 3.1. IPv4 Address Space The IPv4 address space authoritative registration data servers are found by concatenating the reversed IPv4 address to the domain suffix: "ip4.rdap.arpa." and then generating A/AAAA DNS address queries for that concatenated domain. The reversed IPv4 address method is identical to the in-addr.arpa. tree method ([RFC1035] section 3.5). For example, a query for 192.9.200.0/24 generates a DNS request to 200.9.192.ip4.rdap.arpa. 3.2. IPv6 Address Space The IPv6 address space authoritative registration data servers are found by concatenating the reversed full IPv6 address to the domain suffix: "ip6.rdap.arpa." and then generating A/AAAA DNS address queries for that concatenated domain. The reversed full IPv6 address method is identical to the ip6.arpa. tree method ([RFC1886] section 2.5). For example, a query for 2001:db8::/32 generates a DNS request to 8.b.d.0.1.0.0.2.ip6.rdap.arpa. 3.3. Autonomous Systems The Autonomous Systems (AS) authoritative registration data servers are found by concatenating the AS number to the domain suffix: "autnum.rdap.arpa." and then generating A/AAAA DNS address queries for that concateneted domain. For example, a query for AS 65411 generates a DNS request to 65411.autnum.rdap.arpa. Blanchet Expires December 06, 2013 [Page 3] Internet-Draft Finding Authoritative RDAP server June 2013 4. Nameserver TBD 5. Entity TBD 6. A and AAAA Queries The RDAP client SHOULD not decide which of A and/or AAAA queries is sent as the DNS RR query. The client should use standard IP- independent APIs such as [RFC3493]. 7. Processing NXDOMAIN Considerations When a RDAP client receives a NXDOMAIN answer for the query, which means the queried domain does not exist, then the client removes the leftmost label of the domain and restart the query. The client redo this until either a positive answer or the domain to query is the root of the scope (i.e. {domain,ip4,ip6,autnum}.rdap.arpa). In this case, there is no such registration server available for the requested data and an error should be pushed to the end user. For example, if the initial query is 8.b.d.0.1.0.0.2.ip6.rdap.arpa. and the answer is NXDOMAIN, then the new query is b.d.0.1.0.0.2.ip6.rdap.arpa. and if the answer is still NXDOMAIN, then a new query to b.d.0.1.0.0.2.ip6.rdap.arpa. is tried. The removal of leftmost labels continues until either a positive answer is received or the root of the scope (ip6.rdap.arpa in this example) is reached. 8. 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]. The following is a non-normative example of the processing. If the query is to find the registration data for "example.com", and the autoritative server is reachable by 2001:db8:1:1::1 over HTTP[I-D.ietf-weirds-using-http], then the following steps will happen: o client sends A and AAAA DNS requests for example.com.domain.rdap.arpa. o NXDOMAIN is received. Blanchet Expires December 06, 2013 [Page 4] Internet-Draft Finding Authoritative RDAP server June 2013 o client sends A and AAAA DNS requests for com.domain.rdap.arpa. o 2001:db8:1:1:1 is received as the AAAA o client sends an HTTP request to 2001:db8:1:1::1 with the following url: http://com.domain.rdap.arpa/domain/example.com o client receives registration data for that domain[I-D.ietf-weirds-json-response] 9. Deployment Considerations RDAP clients SHOULD not cache any server information, since that caching(and related expiration processing) is already happening at the DNS level. Therefore, the RDAP clients SHOULD always process a new RDAP request by querying the DNS to find the authoritative RDAP server as specified in this document. RDAP server operators may use various techniques such as anycast[RFC4786] to manage the load on their servers. To avoid walking up the tree, DNS wildcards may be used by the zone operators with the considerations discussed in [RFC4592]. Using the previous example, if the wildcard is defined for 1.0.0.2.ip6.rdap.arpa., the query to 8.b.d.0.1.0.0.2.ip6.rdap.arpa. will receive a positive answer instead of a negative answer. Therefore, no walking up the tree will be done to find the authoritative server. This specification makes no assumption on how the authorities of registration data may work together on sharing their information for a common service. For example, the autnum zone may be wholly delegated to a single entity that acts on behalf of all regional registries for that space. The registration information of all autnum space can be provided by all registries to that single entity or redirection may be used at the HTTP level by the single operating entity to the servers of the authoritative registries. 10. Security Considerations TBD 11. IANA Considerations IANA is requested to do the following: o delegation of rdap.arpa as a zone file managed by IANA Blanchet Expires December 06, 2013 [Page 5] Internet-Draft Finding Authoritative RDAP server June 2013 o creation of the domain,ip4,ip6,autnum zones under rdap.arpa. o process by which an authoritative registration data registry requests addition/modification/removal of delegation of the zone for the scope the registry owns. o author note: more details needed 12. Acknowledgements The weirds working group had multiple discussions on this topic, including a session during IETF 84. All the people involved in these discussions are herin acknowledged. Simon Perreault, Jean-Philippe Dionne, John Levine, have provided input and suggestions to this document. 13. References 13.1. Normative References [I-D.ietf-weirds-json-response] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", draft-ietf- weirds-json-response-03 (work in progress), April 2013. [I-D.ietf-weirds-rdap-query] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol Lookup Format", draft-ietf-weirds-rdap-query-04 (work in progress), April 2013. [I-D.ietf-weirds-using-http] Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the Registration Data Access Protocol (RDAP)", draft-ietf- weirds-using-http-05 (work in progress), May 2013. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995. [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010. 13.2. Informative References Blanchet Expires December 06, 2013 [Page 6] Internet-Draft Finding Authoritative RDAP server June 2013 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006. [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006. Author's Address Marc Blanchet Viagenie 246 Aberdeen Quebec, QC G1R 2E1 Canada Email: Marc.Blanchet@viagenie.ca URI: http://www.viagenie.ca Blanchet Expires December 06, 2013 [Page 7]