[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 rfc3663                                        
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]