git.sur5r.net Git - openldap/blob - doc/drafts/draft-ietf-ldapext-locate-xx.txt

   1 INTERNET-DRAFT                                         Michael P. Armijo
   2 <draft-ietf-ldapext-locate-01.txt>                          Levon Esibov
   3 January, 2000                                                 Paul Leach
   4 Expires: July, 2000                                Microsoft Corporation
   5
   6                 Discovering LDAP Services with DNS
   7
   8 Status of this Memo
   9
  10    This document is an Internet-Draft and is in full conformance with
  11    all provisions of Section 10 of RFC2026.
  12
  13    Internet-Drafts are working documents of the Internet Engineering
  14    Task Force (IETF), its areas, and its working groups.  Note that
  15    other groups may also distribute working documents as Internet-
  16    Drafts.
  17
  18    Internet-Drafts are draft documents valid for a maximum of six months
  19    and may be updated, replaced, or obsoleted by other documents at any
  20    time.  It is inappropriate to use Internet- Drafts as reference
  21    material or to cite them other than as "work in progress."
  22
  23    The list of current Internet-Drafts can be accessed at
  24    http://www.ietf.org/ietf/1id-abstracts.txt
  25
  26    The list of Internet-Draft Shadow Directories can be accessed at
  27    http://www.ietf.org/shadow.html.
  28
  29    Distribution of this memo is unlimited.  It is filed as <draft-
  30    ietf-ldapext-locate-01.txt>, and expires on July 4, 2000.
  31    Please send comments to the authors.
  32
  33 1. Abstract
  34
  35    This draft defines a way that native Internet LDAP servers can make
  36    use of the DNS's knowledge base to provide clients a method to
  37    resolve LDAP services for a given domain.
  38
  39
  40 2. Introduction
  41
  42    The LDAPv3 protocol [1] is designed to be a lightweight access
  43    protocol for directory services supporting X.500 models. This may
  44    be the X.500 directory itself, but the LDAP specification
  45    explicitly allows it to be a different directory.  Let us define
  46    a "native LDAP server" to be one that is not a front end to the
  47    X.500 directory service. Let us further define an "Internet based
  48    organization" as one that has a domain name, and an "Internet LDAP
  49    server" to be one containing a directory entries for such an
  50    organization.
  51
  52    This draft defines a way that native Internet LDAP servers can make
  53    use of the DNS's knowledge base to perform the same function, while
  54    still supporting integration with the X.500 directory.
  55
  56    This draft builds on RFC 2247[2] to define a mechanism by which
  57    collections of native Internet LDAP servers can be integrated to
  58    create a directory service. That work supports this cause by
  59    defining a mapping from an LDAP DN to a DNS name that can be
  60    resolved to the address of a server holding the entry corresponding
  61    to the DN. For example, the DN "CN=Fred,OU=Eng,DC=example,DC=net"
  62    maps to the DNS name "example.net".
  63
  64    In an Internet context, many of the names about which users seek
  65    information are DNS names, or include DNS names. A native LDAP based
  66    directory service for the Internet should make it convenient to
  67    process such names -- there is a huge social investment spanning two
  68    decades to get to the point where names like
  69    "john.doe@somewhere.example" and "http://www.example.net" can
  70    appear in newspaper articles, TV commercials, and on billboards
  71    and millions of people understand what to do with them. As a result,
  72    we assume that Internet based organizations wish to preserve this
  73    investment, yet also want to deploy directory services.
  74
  75    Widespread use of, and dependence on, LDAP services will require that
  76    they are robust and scalable. Both of these features are typically
  77    supported by replicated servers. Use of SRV records to locate LDAP
  78    servers supports clients' use of replicated servers.
  79
  80
  81 3. Locating LDAP servers through DNS
  82
  83    LDAP server location information is to be stored using DNS Service
  84    Location Record (SRV)[6].  The data in a SRV record contains the DNS
  85    name of the server that provides the LDAP service, corresponding Port
  86    number, and parameters that enable the client to choose an
  87    appropriate server from multiple servers according to the algorithm
  88    described in the SRV protocol[6].  The name of this record always has
  89    the following format:
  90
  91    _<Service>._<Proto>.<Domain>
  92
  93    where <Service> is always "ldap", <Proto> is a protocol that can
  94    be either "udp" or "tcp", and <Domain> is the domain hosted by the
  95    LDAP Server.  Note that "ldap" is the symbolic name for the LDAP
  96    service in Assigned Numbers [7], as required by the SRV Protocol[6].
  97
  98    Presence of such records enables clients to find the LDAP servers
  99    using standard DNS query [3].  As an example, a client that searches
 100    for an LDAP server in the example.net domain that supports TCP protocol
 101    will submit a DNS query for a set of SRV records with owner name:
 102
 103    _ldap._tcp.example.net.
 104
 105    The client will receive the list of SRV records published in DNS
 106    that satisfy the requested criteria.  The following is an example
 107    of such record:
 108
 109    _ldap._tcp.example.net.   IN    SRV   0 0 389 phoenix.example.net.
 110
 111    The set of returned records may contain multiple records in the
 112    case where multiple LDAP servers serve the same domain.
 113
 114
 115 4. Security Considerations
 116
 117    This document describes a method that uses DNS SRV records to
 118    discover LDAP servers.  All security considerations related to DNS
 119    SRV records are inherited by this document.  See the security
 120    considerations section in [6] for more details.
 121
 122
 123 5. References
 124
 125    [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
 126    Protocol(v3)".  RFC 2251, December 1997.
 127
 128    [2] S. Kille, M. Wahl, "Using Domains in LDAP/X.500 Distinguished
 129    Names". RFC 2247, January 1998.
 130
 131    [3] P. Mockapetris, RFC 1034, DOMAIN NAMES - CONCEPTS AND FACILITIES,
 132    November, 1987.
 133
 134    [4] P. Mockapetris, RFC 1035, DOMAIN NAMES - IMPLEMENTATION AND
 135    SPECIFICATION, November, 1987.
 136
 137    [5] T. Howes, M. Smith, "The LDAP URL Format". RFC 2255  December 1997.
 138
 139    [6] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the
 140    location of services (DNS SRV)".
 141    http://www.ietf.org/internet-drafts/draft-ietf-
 142    dnsind-rfc2052bis-05.txt, November 1999.
 143
 144    [7] J. Reynolds, J. Postel, "Assigned Numbers", STD 2, October 1994
 145
 146
 147 6. Authors' Addresses
 148
 149    Michael P. Armijo
 150    One Microsoft Way
 151    Redmond, WA 98052
 152    micharm@microsoft.com
 153
 154    Paul Leach
 155    One Microsoft Way
 156    Redmond, WA 98052
 157    paulle@microsoft.com
 158
 159    Levon Esibov
 160    One Microsoft Way
 161    Redmond, WA 98052
 162    levone@microsoft.com
 163
 164    Expires July, 2000
 165