From fd57c2666b843620e36b119e744f9f0fe74f34cb Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Tue, 16 May 2000 18:26:16 +0000 Subject: [PATCH] Update to rev 2 --- doc/drafts/draft-ietf-ldapext-locate-xx.txt | 224 ++++++++++++-------- 1 file changed, 132 insertions(+), 92 deletions(-) diff --git a/doc/drafts/draft-ietf-ldapext-locate-xx.txt b/doc/drafts/draft-ietf-ldapext-locate-xx.txt index 40f438d514..3fb0d19a6d 100644 --- a/doc/drafts/draft-ietf-ldapext-locate-xx.txt +++ b/doc/drafts/draft-ietf-ldapext-locate-xx.txt @@ -1,7 +1,9 @@ INTERNET-DRAFT Michael P. Armijo - Levon Esibov -January, 2000 Paul Leach -Expires: July, 2000 Microsoft Corporation + Levon Esibov +April, 2000 Paul Leach +Expires: October, 2000 Microsoft Corporation + R.L. Morgan + University of Washington Discovering LDAP Services with DNS @@ -27,92 +29,121 @@ Status of this Memo http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. It is filed as , 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: - - _._. - - where is always "ldap", is a protocol that can - be either "udp" or "tcp", and 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: + + _._. + + where is always "ldap", and is a protocol that can + be either "udp" or "tcp". 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 @@ -120,28 +151,27 @@ Status of this Memo 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 @@ -161,5 +191,15 @@ Status of this Memo 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 -- 2.39.5