From 1d03f5dbac5e716c25c5e4809fb763c0ab5d9180 Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Sat, 29 Jan 2000 22:46:45 +0000 Subject: [PATCH] Import locate draft. --- doc/drafts/draft-ietf-ldapext-locate-xx.txt | 165 ++++++++++++++++++++ 1 file changed, 165 insertions(+) create mode 100644 doc/drafts/draft-ietf-ldapext-locate-xx.txt diff --git a/doc/drafts/draft-ietf-ldapext-locate-xx.txt b/doc/drafts/draft-ietf-ldapext-locate-xx.txt new file mode 100644 index 0000000000..40f438d514 --- /dev/null +++ b/doc/drafts/draft-ietf-ldapext-locate-xx.txt @@ -0,0 +1,165 @@ +INTERNET-DRAFT Michael P. Armijo + Levon Esibov +January, 2000 Paul Leach +Expires: July, 2000 Microsoft Corporation + + Discovering LDAP Services with DNS + +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. + + Distribution of this memo is unlimited. It is filed as , and expires on July 4, 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. + + +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 + 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. 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. + + +4. Security Considerations + + This document describes a method that uses DNS SRV records to + discover LDAP servers. All security considerations related to DNS + SRV records are inherited by this document. See the security + considerations section in [6] for more details. + + +5. References + + [1] M. Wahl, T. Howes, 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. + + [3] P. Mockapetris, RFC 1034, DOMAIN NAMES - CONCEPTS AND FACILITIES, + November, 1987. + + [4] P. Mockapetris, RFC 1035, DOMAIN NAMES - IMPLEMENTATION AND + SPECIFICATION, November, 1987. + + [5] T. Howes, M. Smith, "The LDAP URL Format". RFC 2255 December 1997. + + [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. + + [7] J. Reynolds, J. Postel, "Assigned Numbers", STD 2, October 1994 + + +6. Authors' Addresses + + Michael P. Armijo + One Microsoft Way + Redmond, WA 98052 + micharm@microsoft.com + + Paul Leach + One Microsoft Way + Redmond, WA 98052 + paulle@microsoft.com + + Levon Esibov + One Microsoft Way + Redmond, WA 98052 + levone@microsoft.com + + Expires July, 2000 + -- 2.39.5