Network Working Group A.L. Newton Internet-Draft VeriSign, Inc. Expires: January 10, 2002 July 12, 2001 Whois Domain Data in LDAP draft-newton-ldap-whois-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 10, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract Domain registration data has typically been exposed to the general public via whois for administrative purposes. This document discusses the application of LDAP and well-known LDAP types to make available Domain registration data. Newton Expires January 10, 2002 [Page 1] Internet-Draft whois-in-ldap July 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Historical Directory Services for Domain Registration Data . 3 1.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Service Description . . . . . . . . . . . . . . . . . . . . 4 3. Registry LDAP Service . . . . . . . . . . . . . . . . . . . 5 3.1 TLD DIT . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3 Access Control . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Name Server DIT . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Registrar Referral DIT . . . . . . . . . . . . . . . . . . . 7 3.3.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 7 4. Registrar LDAP Service . . . . . . . . . . . . . . . . . . . 9 4.1 TLD DIT . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 10 4.1.3 Access Control . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Name Server and Contact DIT . . . . . . . . . . . . . . . . 11 4.2.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2 Allowed Searches . . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 6. Internationalization Considerations . . . . . . . . . . . . 14 7. Security Consideratons . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . 17 Newton Expires January 10, 2002 [Page 2] Internet-Draft whois-in-ldap July 2001 1. Introduction This document describes the Referral LDAP Service, a pilot project launched by VeriSign, Inc., to explore the use of LDAP and LDAP-related technologies for use as a directory service of administrative domain registration information. 1.1 Historical Directory Services for Domain Registration Data The original National Science Foundation contract for the InterNIC called for the creation of an X.500 directory service to allow for administrative needs of the domain registration data and information. Due to problems with implementations of X.500 server software, a server based on the whois[1] protocol was temporarily erected. In 1994, the rwhois[3] protocol was introduced to enhance the whois protocol. This directory service never gained wide acceptance. At present, ICANN requires the operation of whois servers by registries and registrars of generic top-level domains. 1.2 Motivations With the recent split in functional responsibilities between registries and registrars, the constant miss-use and data-mining of domain registration data, and the difficulties with machine-readability of whois output, the creation of the Referral LDAP Service had the following motivations: o Use a mechanism native to the directory protocol to refer clients from inquiries about specific domains made at a registry to the appropriate domain within the appropriate directory service at a registrar. o Limit access to domain data based on authentication of the client. o Provide for structured queries and well-defined structured results. o Use a directory service technology already in general use. Given these general criteria, LDAP[5] was selected as the protocol for this directory service. Newton Expires January 10, 2002 [Page 3] Internet-Draft whois-in-ldap July 2001 2. Service Description The service is composed of three distinct server types: a registry LDAP server, registrar LDAP servers, and registrant LDAP servers. The registry LDAP server contains three Directory Information Tree's (DIT). o The Top-Level Domain (TLD) DIT's follows the DNS hierarchy for domains (i.e. dc=foo,dc=com). o The name server DIT allows a view of the name servers, many of which serve multiple domains. o The registrar-referral DIT provides referrals from the registry into the respective TLD DIT of the registrars (on a TLD basis). The registrar LDAP server contains two types of DIT's. o The TLD DIT follows the DNS hierarchy for domains (i.e. dc=foo,dc=com) and parallels the TLD DIT of the registry. o The name server and contact DIT allow a view of the name servers and contacts, many of which are associated and serve multiple domains. There is no specification on the DIT or schema for the registrant LDAP server. Referrals from the registrar server to the registrant server are provided solely for the purpose of allowing the registrant direct control over extra administrative information as it relates to a particular domain. Access control for this service is merely a demonstration of using simple bind DN and password authentication. Should registries and registrars uniformly adopt LDAP as a means to disseminate domain registration data, standardization of the bind DN's would need to be undertaken based on each type of user base. Newton Expires January 10, 2002 [Page 4] Internet-Draft whois-in-ldap July 2001 3. Registry LDAP Service 3.1 TLD DIT 3.1.1 DIT Structure The registry TLD DIT has the following structural hierarchy. TLD (i.e. dc=net) | | ------------------------------------- | | SLD (i.e. dc=foo,dc=net) SLD (i.e. dc=bar,dc=net) | | --------------------- --------------------- | | | | | | name server | | name server | | (i.e. | | (i.e. | | cn=nameserver1, | | cn=nameserver1, | | dc=foo,dc=net ) | | dc=bar,dc=net ) | | | | | | name server | name server | (i.e. | (i.e. | cn=nameserver2, | cn=nameserver2, | dc=foo,dc=net ) | dc=bar,dc=net ) | | | registrar referral registrar referral (i.e. (i.e. cn=registrar, cn=registrar, dc=foo,dc=net ) dc=bar,dc=net ) The root of a TLD DIT is an entry of objectclass domain as specified by RFC2247[4] and represents a top-level domain. The second tier of the DIT represents second-level domains. Each of these entries is of objectclass domain as specified by RFC2247[4]. The description attribute on these entries often contains descriptive text giving the name of the registrar through which these domains have been registered. The third tier contains entries specific to each second-level domain for which they fall under. Name server entries are of objectclass ipHost as specified by RFC2307[8]. The distinguished names of these name server entries are algorithmicly calculated where the first component is the word "nameserver" concatenated with an index number of the name server entry and the remaining components being the appropriate domain names. There is no specification relating the Newton Expires January 10, 2002 [Page 5] Internet-Draft whois-in-ldap July 2001 value of the name server entry to the index it may be assigned other than it is unique and consistent with respect to the client session. This tier also contains the referral from the registry to the registrar. This referral is a direct referral to the entry in the appropriate registrar LDAP server corresponding to the domain name which the referral falls beneath in this DIT. 3.1.2 Allowed Searches Because of the vast amount of entries contained within this DIT, only certain types of searches are allowed. Allowing any search expressible via LDAP would lead to expensive searches that would be far too costly for a publicly available service. The searches allowed are as follows. o One-level scoped searches based at the root of the DIT. Substring matching is allowed on dc attributes, but the substring must be at least be 3 characters in length. o Base search based at the root of the DIT. o Base, one-level, and sub-tree searches based at any second level domain name (the second tier) and below. 3.1.3 Access Control The registry TLD DIT only has one access control type. When a client binds with a DN of "cn=trademark" and password of "attorney", the second-level domain entries also take on an objectclass of extensibleObject with the added attributes of "createddate" and "registrationexpirationdate", which are of type Generalized Time as specified by RFC2252[6]. 3.2 Name Server DIT 3.2.1 DIT Structure The registry name server DIT has the following structural hierarchy. (o=nsiregistry.com) | | ------------------------------------- | | | name server name server name server (cn=ns1.foo.net) (cn=ns.bar.com) (cn=named.acme.org) The root of a name server DIT is an entry of objectclass Newton Expires January 10, 2002 [Page 6] Internet-Draft whois-in-ldap July 2001 organization as specified by RFC1617[2]. It has no significance other than to serve as the root of the DIT. The second tier of this DIT represents name servers. Each of these entries is of objectclass ipHost as specified by RFC2307[8]. 3.2.2 Allowed Searches Because of the vast amount of entries contained within this DIT, only certain types of searches are allowed. Allowing any search expressible via LDAP would lead to expensive searches that would be far too costly for a publicly available service. The searches allowed are as follows. o One-level and sub-tree scoped searches based at the root of the DIT if a filter on the cn attribute is provided. o Base search based at the root of the DIT. o Base, one-level, and sub-tree searches based at any name server entry. 3.3 Registrar Referral DIT 3.3.1 DIT Structure The registry registrar-referral DIT has the following structural hierarchy. (o=tlds) | | ------------------------------- | | | | tld tld tld tld (dc=net) (dc=com) (dc=org) (dc=edu) | | | | : : | : : : | : | --------------------------- | | | referral to referral to referral to registrar 1 registrar 2 registrar n dc=org DIT dc=org DIT dc=org DIT The root of the registrar referral DIT is an entry of objectclass organization as specified by RFC1617[2]. It has no significance Newton Expires January 10, 2002 [Page 7] Internet-Draft whois-in-ldap July 2001 other than to serve as the root of this DIT. The second tier of this DIT represents top-level domains. Each of these entries is of objectclass domain as specified by RFC2247[4]. Underneath each TLD entry, the third tier contains referrals to the appropriate TLD DIT of each registrar. Newton Expires January 10, 2002 [Page 8] Internet-Draft whois-in-ldap July 2001 4. Registrar LDAP Service 4.1 TLD DIT 4.1.1 DIT Structure The registrar TLD DIT's, which is similar to the registry TLD DIT's, has the following structural hierarchy. TLD (i.e. dc=net) | | ------------------------------------------------ | | | SLD (i.e. dc=foo,dc=net) : : | : : --------------------------------------------- | | | | | | name server contact referral to (i.e. cn=nameserver1, (i.e. cn=contact1, registrant dc=foo,dc=net ) dc=foo,dc=net ) | | name server contact (i.e. cn=contact, cn=nameserver1, dc=foo,dc=net ) The root of a TLD DIT is an entry of objectclass domain as specified by RFC2247[4] and represents a top-level domain. The second tier of the DIT represents second-level domains. Each of these entries is of objectclass domain as specified by RFC2247[4]. The third tier contains entries specific to each second-level domain for which they fall under. The entries at this level are as follows: o Name server entries are of objectclass ipHost as specified by RFC2307[8]. The distinguished names of these name server entries are algorithmicly calculated where the first component is the word "nameserver" concatenated with an index number of the name server entry and the remaining components being the appropriate domain names. There is no specification relating the value of the name server entry to the index it may be assigned other than it is unique and consistent with respect to the client session. o Contact entries are of objectclass inetOrgPerson as specified by Newton Expires January 10, 2002 [Page 9] Internet-Draft whois-in-ldap July 2001 RFC2798[9]. The distinguished names of these contact entries are algorithmicly calculated where the first component is the word "contact" concatenated with an index number of the contact and the remaining components being the appropriate domain names. There is no specification relating the value of the contact entry to the index it may be assigned other than it is unique and consistent with respect to the client session. The description attribute of the entry contains the role for which a contact is related to a domain. These roles are identified as "Admin Contact", "Technical Contact", and "Billing Contact", and may appear in any order. o Finally, this third tier contains the referral from the registrar to the registrant. The fourth tier only contains name server contact entries. These entries are of objectclass inetOrgPerson as specified by RFC2798[9]. 4.1.2 Allowed Searches Because of the vast amount of entries contained within this DIT, only certain types of searches are allowed. Allowing any search expressible via LDAP would lead to expensive searches that would be far too costly for a publicly available service. The searches allowed are as follows. o One-level scoped searches based at the root of the DIT. Substring matching is allowed on dc and o attributes, but the substring must be at least be 3 characters in length. o Base search based at the root of the DIT. o Base, one-level, and sub-tree searches based at any second level domain name (the second tier) and below. 4.1.3 Access Control The registrar TLD DIT's have two access control types. When binding anonymously, a client only sees dc, o, and c attributes of the second-level domain entries. When a client binds with a DN of "cn=trademark" and password of "attorney", all of the other attributes normally available on entries of objectclass domain are visible if they have values. In addition, if a client binds with the DN of a contact and password of "password", all attributes for second-level domain entries for which the bind DN has a relation are visible. Newton Expires January 10, 2002 [Page 10] Internet-Draft whois-in-ldap July 2001 4.2 Name Server and Contact DIT 4.2.1 DIT Structure The registrar name server and contact DIT has the following structural hierarchy. (o=nsi.com) | | -------------------------------------- | | Contacts Name Servers (ou=contacts) (ou=name servers) | | ----------------- ------------------------ | | | | | | Contact : : Name Server : : (uid=handle) : : (cn=handle) : : | Name Server Contact (cn=contact1) The first tier of the name server and contact DIT is an entry of objectclass organization as specified by RFC1617[2]. The second tier of the DIT contains two entries, each of which is of objectclass organizationalUnit as specified by RFC2256[7]. One entry represents the part of the DIT containing contacts and the other entry represents the part of the DIT containing name servers. Entries underneath the contacts organizationalUnit entry are of objectclass inetOrgPerson and represent contacts registered with the registrar. Their RDN is composed of the uid attribute. The uid attribute's value is a unique identifier or handle that is registrar assigned. Entries underneath the name server organizationalUnit entry are of objectclass ipHost and represent name servers registered with the registrar. Their RDN is composed of the cn attribute. The cn attribute's value is a unique identifier or handle that is registrar assigned. Each name server entry may optionally have children entries of objectclass inetOrgPerson. These entries represent the contacts of the name server they fall beneath. Newton Expires January 10, 2002 [Page 11] Internet-Draft whois-in-ldap July 2001 4.2.2 Allowed Searches Because of the vast amount of entries contained within this DIT, only certain types of searches are allowed. Allowing any search expressible via LDAP would lead to expensive searches that would be far too costly for a publicly available service. The searches allowed are as follows. o One-level and base searches at the root of the DIT. o Sub-tree searches at the root of the DIT using cn and uid attributes as a filter. o Base searches at the either entry of the second tier. o One-level and sub-tree searches at either entry of the second tier using cn or uid attributes as a filter. o Base, one-level, and sub-tree searches based at any contact or name server entry and below. Newton Expires January 10, 2002 [Page 12] Internet-Draft whois-in-ldap July 2001 5. IANA Considerations There are no IANA considerations beyond those need by LDAP[5]. Newton Expires January 10, 2002 [Page 13] Internet-Draft whois-in-ldap July 2001 6. Internationalization Considerations There are no internationalization considerations beyond those needed by LDAP[5]. Newton Expires January 10, 2002 [Page 14] Internet-Draft whois-in-ldap July 2001 7. Security Consideratons There are no security considerations beyond those need by LDAP[5]. Newton Expires January 10, 2002 [Page 15] Internet-Draft whois-in-ldap July 2001 References [1] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985. [2] Barker, P., Kille, S. and T. Lenggenhager, "Naming and Structuring Guidelines for X.500 Directory Pilots", RFC 1617, May 1994. [3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, June 1997. [4] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, January 1998. [5] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [6] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [7] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [8] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307, March 1998. [9] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", RFC 2798, April 2000. Author's Address Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA Phone: +1 703 948 3382 EMail: anewton@research.netsol.com URI: http://www.research.netsol.com/ Newton Expires January 10, 2002 [Page 16] Internet-Draft whois-in-ldap July 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Newton Expires January 10, 2002 [Page 17]