Internet DRAFT - draft-blanchet-weirds-bootstrap

draft-blanchet-weirds-bootstrap







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]