INTERNET-DRAFT Michael P. Armijo
-<draft-ietf-ldapext-locate-01.txt> Levon Esibov
-January, 2000 Paul Leach
-Expires: July, 2000 Microsoft Corporation
+<draft-ietf-ldapext-locate-02.txt> Levon Esibov
+April, 2000 Paul Leach
+Expires: October, 2000 Microsoft Corporation
+ R.L. Morgan
+ University of Washington
Discovering LDAP Services with DNS
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. It is filed as <draft-
- ietf-ldapext-locate-01.txt>, and expires on July 4, 2000.
+ ietf-ldapext-locate-02.txt>, and expires on October 15, 2000.
Please send comments to the authors.
+
1. Abstract
- This draft defines a way that native Internet LDAP servers can make
- use of the DNS's knowledge base to provide clients a method to
- resolve LDAP services for a given domain.
+ A Lightweight Directory Access Protocol (LDAP) request must be
+ directed to an appropriate server for processing. This document
+ specifies a method for discovering such servers using information in
+ the Domain Name System.
2. Introduction
- The LDAPv3 protocol [1] is designed to be a lightweight access
- protocol for directory services supporting X.500 models. This may
- be the X.500 directory itself, but the LDAP specification
- explicitly allows it to be a different directory. Let us define
- a "native LDAP server" to be one that is not a front end to the
- X.500 directory service. Let us further define an "Internet based
- organization" as one that has a domain name, and an "Internet LDAP
- server" to be one containing a directory entries for such an
- organization.
-
- This draft defines a way that native Internet LDAP servers can make
- use of the DNS's knowledge base to perform the same function, while
- still supporting integration with the X.500 directory.
-
- This draft builds on RFC 2247[2] to define a mechanism by which
- collections of native Internet LDAP servers can be integrated to
- create a directory service. That work supports this cause by
- defining a mapping from an LDAP DN to a DNS name that can be
- resolved to the address of a server holding the entry corresponding
- to the DN. For example, the DN "CN=Fred,OU=Eng,DC=example,DC=net"
- maps to the DNS name "example.net".
-
- In an Internet context, many of the names about which users seek
- information are DNS names, or include DNS names. A native LDAP based
- directory service for the Internet should make it convenient to
- process such names -- there is a huge social investment spanning two
- decades to get to the point where names like
- "john.doe@somewhere.example" and "http://www.example.net" can
- appear in newspaper articles, TV commercials, and on billboards
- and millions of people understand what to do with them. As a result,
- we assume that Internet based organizations wish to preserve this
- investment, yet also want to deploy directory services.
-
- Widespread use of, and dependence on, LDAP services will require that
- they are robust and scalable. Both of these features are typically
- supported by replicated servers. Use of SRV records to locate LDAP
- servers supports clients' use of replicated servers.
-
-
-3. Locating LDAP servers through DNS
-
- LDAP server location information is to be stored using DNS Service
- Location Record (SRV)[6]. The data in a SRV record contains the DNS
- name of the server that provides the LDAP service, corresponding Port
- number, and parameters that enable the client to choose an
- appropriate server from multiple servers according to the algorithm
- described in the SRV protocol[6]. The name of this record always has
- the following format:
-
- _<Service>._<Proto>.<Domain>
-
- where <Service> is always "ldap", <Proto> is a protocol that can
- be either "udp" or "tcp", and <Domain> is the domain hosted by the
- LDAP Server. Note that "ldap" is the symbolic name for the LDAP
- service in Assigned Numbers [7], as required by the SRV Protocol[6].
-
- Presence of such records enables clients to find the LDAP servers
- using standard DNS query [3]. As an example, a client that searches
- for an LDAP server in the example.net domain that supports TCP protocol
+ The LDAPv3 protocol [1] is designed to be a lightweight access
+ protocol for directory services supporting X.500 models. As a
+ distributed directory service, the complete set of directory
+ information (known as the Directory Information Base) is spread
+ across many different servers. Hence there is the need to
+ determine, when initiating or processing a request, which servers
+ hold the relevant information. In LDAP, the Search, Modify, Add,
+ Delete, ModifyDN, and Compare operations all specify a Distinguished
+ Name (DN) [2] on which the operation is performed. A client, or a
+ server acting on behalf of a client, must be able to determine the
+ server(s) that hold the naming context containing that DN, since
+ that server (or one of that set of servers) must receive and process
+ the request. This determination process is called "server
+ location". To support dynamic distributed operation, the
+ information needed to support server location must be available via
+ lookups done at request processing time, rather than, for example,
+ as static data configured into each client or server.
+
+ It is possible to maintain the information needed to support server
+ location in the directory itself, and X.500 directory deployments
+ typically do so. In practice, however, this only permits location
+ of servers within a limited X.500-connected set. LDAP-specific
+ methods of maintaining server location information in the directory
+ have not yet been standardized. This document defines an
+ alternative method of managing server location information using the
+ Domain Name System. This method takes advantage of the global
+ deployment of the DNS, by allowing LDAP server location information
+ for any existing DNS domain to be published by creating the records
+ described below. A full discussion of the benefits and drawbacks of
+ the various directory location and naming methods is beyond the
+ scope of this document.
+
+ RFC 2247[3] defines an algorithm for mapping DNS domain names into
+ DNs. This document defines the inverse mapping, from DNs to DNS
+ domain names, based on the conventions in [3], for use in this
+ server location method. The server location method described in
+ this document is only defined for DNs that can be so mapped, i.e.,
+ those DNs that are based on domain names. In practice this is
+ reasonable because many objects of interest are named with domain
+ names, and use of domain-name-based DNs is becoming common.
+
+
+3. Mapping Distinguished Names into Domain Names
+
+ This section defines a method of converting a DN into a DNS domain
+ name for use in the server location method described below. Some
+ DNs cannot be converted into a domain name.
+
+ The output domain name is initially empty. For each RDN component
+ of the DN, beginning with the first, if the attribute type is "DC",
+ then the attribute value is used as a domain name component (label).
+ The first such value becomes the most significant (i.e., rightmost)
+ domain name component, and successive values occupy less significant
+ positions (i.e., extending leftward), in order. If the attribute
+ type is not "DC", then processing stops. If the first RDN component
+ of the DN is not of type "DC" then the DN cannot be converted to a
+ domain name.
+
+
+4. Locating LDAP servers through DNS
+
+ LDAP server location information is to be stored using DNS Service
+ Location Record (SRV)[5]. The data in a SRV record contains the DNS
+ name of the server that provides the LDAP service, corresponding
+ Port number, and parameters that enable the client to choose an
+ appropriate server from multiple servers according to the algorithm
+ described in [5]. The name of this record has the following format:
+
+ _<Service>._<Proto>.<Domain>
+
+ where <Service> is always "ldap", and <Proto> is a protocol that can
+ be either "udp" or "tcp". <Domain> is the domain name formed by
+ converting the DN of a naming context mastered by the LDAP Server
+ into a domain name using the algorithm in Section 2. Note that
+ "ldap" is the symbolic name for the LDAP service in Assigned
+ Numbers[6], as required by [5].
+
+ Presence of such records enables clients to find the LDAP servers
+ using standard DNS query [4]. A client (or server) seeking an LDAP
+ server for a particular DN converts that DN to a domain name using
+ the algorithm of Section 2, does a SRV record query using the DNS
+ name formed as described in the preceding paragraph, and interprets
+ the response as described in [5] to determine a host (or hosts) to
+ contact. As an example, a client that searches for an LDAP server
+ for the DN "ou=foo,dc=example,dc=net" that supports the TCP protocol
will submit a DNS query for a set of SRV records with owner name:
-
- _ldap._tcp.example.net.
- The client will receive the list of SRV records published in DNS
- that satisfy the requested criteria. The following is an example
- of such record:
+ _ldap._tcp.example.net.
+
+ The client will receive the list of SRV records published in DNS
+ that satisfy the requested criteria. The following is an example of
+ such a record:
+
+ _ldap._tcp.example.net. IN SRV 0 0 389 phoenix.example.net.
- _ldap._tcp.example.net. IN SRV 0 0 389 phoenix.example.net.
+ The set of returned records may contain multiple records in the case
+ where multiple LDAP servers serve the same domain.
- The set of returned records may contain multiple records in the
- case where multiple LDAP servers serve the same domain.
-4. Security Considerations
+5. Security Considerations
This document describes a method that uses DNS SRV records to
discover LDAP servers. All security considerations related to DNS
considerations section in [6] for more details.
-5. References
+6. References
- [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol(v3)". RFC 2251, December 1997.
+ [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol(v3)", RFC 2251, December 1997.
- [2] S. Kille, M. Wahl, "Using Domains in LDAP/X.500 Distinguished
- Names". RFC 2247, January 1998.
+ [2] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished
+ Names", RFC 2253, December 1997.
- [3] P. Mockapetris, RFC 1034, DOMAIN NAMES - CONCEPTS AND FACILITIES,
- November, 1987.
-
- [4] P. Mockapetris, RFC 1035, DOMAIN NAMES - IMPLEMENTATION AND
- SPECIFICATION, November, 1987.
+ [3] Kille, S. and M. Wahl, "Using Domains in LDAP/X.500
+ Distinguished Names", RFC 2247, January 1998.
- [5] T. Howes, M. Smith, "The LDAP URL Format". RFC 2255 December 1997.
+ [4] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
+ 1034, STD 13, November 1987.
- [6] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the
- location of services (DNS SRV)".
- http://www.ietf.org/internet-drafts/draft-ietf-
- dnsind-rfc2052bis-05.txt, November 1999.
+ [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
- [7] J. Reynolds, J. Postel, "Assigned Numbers", STD 2, October 1994
+ [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
+ 1700, October 1994.
6. Authors' Addresses
Redmond, WA 98052
levone@microsoft.com
- Expires July, 2000
+ RL "Bob" Morgan
+ University of Washington
+ 4545 15th Ave NE
+ Seattle, WA 98105
+ US
+
+ Phone: +1 206 221 3307
+ EMail: rlmorgan@washington.edu
+ URI: http://staff.washington.edu/rlmorgan/
+
+ Expires October, 2000
projects / openldap / commitdiff