[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS



At 05:33 PM 1/18/00 -0800, Paul Leach wrote:
>
>
>> -----Original Message-----
>> From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com]
>> Sent: Monday, January 17, 2000 4:36 PM
>> To: ietf-ldapext@netscape.com
>> Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP
>> Services with DNS
>> 
>> 
>> I don't understand (or necessarily agree with) the first two 
>> paragraphs of
>> this draft.  What difference does it make to this mechanism 
>> what a "native"
>> LDAP server is?
>
>We needed a word to describe servers whose NCs have DNs that start with a
>series of "DC=" components. Ones that don't have such names for their NCs
>are using the X.500 naming model with LDAP front ends -- those are
>"X.500-ish" LDAP servers.
>

OK.  The draft should drop the use of "native", and just say that it
applies to LDAP servers that have standardiz(s)ed on the "DC" naming RFC.
I liked the words in the original version of the taxonomy draft that said
something to the effect of: "If the directory uses DC naming then you can
do this...".  I'd also mention the sentiments expressed by R. L. "Bob":

>Indeed, if directory objects are named based on DNS names, then this
>method can be used.  Otherwise, there is no defined dynamic discovery
>method.  I know which naming scheme I'll choose.
>

I've also attached my (very) old draft that talks about how to get a
directory entry from an email address.  The locate draft and the taxonomy
draft don't seem to deal with this issue.  Does anyone think that I should
update this and get it moved forward as an Informational Draft?

Bruce





Application Working Group                               Bruce Greenblatt
Internet Draft
<draft-greenblatt-defema-02>
Expires in six months


                  Directory Entries From Email Address


Status of this Memo


        This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   andits 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.  Internet-Drafts may be updated, replaced, or made obsolete
   by other documents at any time. It is not appropriate to use
   Internet-Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress".

        To learn the current status of any Internet-Draft, please check
   the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

        Distribution of this document is unlimited.

        Abstract

        This draft describes various means for finding a user's direc-
   tory entry in a LDAP directory presuming that the user's electronic
   mail address is known. This draft does not presume any specific DIT
   structure or schema modifications.

   1.  Mechanism

        It is crucial to the success of finding services in the Internet
   that SRV records as defined in [1] be deployed. This draft shows how
   these records can be used in a straightforward manner to assist in
   the location of user records. First, assume that a users email
   address is of the form:  name@domain, and domain is of the form: dcn.
   ... .dc0.tld, where: tld is a top level domain, dc0 is an IETF
   registered domain name, and dcn through dc1 are locally administer
   subdomains of dc1, and n is greater than or equal to 0. Examples of



Greenblatt                                                      [Page 1]





Internet Draft                                                 July 1997


   valid name forms are:

   -    bgg@novell.com

   -    user@scvwd.ca.us

   -    foo@bar2.bar1.bar0.za

        In order to find the directory entry that corresponds to these
   email addresses, find the most specific domain name, i.e. dcn. ...
   .dco.tld, and use this string in a DNS lookup for an LDAP [3] service
   according to the mechanisms defined in [1].  If such a service is not
   found, then continue stripping off domain components until the
   dc0.tld component of the address is extracted and used in a DNS
   lookup for an LDAP service according to the mechanisms defined in
   [1].   So, in the last example above, the DNS lookups would start
   with bar2.bar1.bar0.za, and if that one yields no LDAP service, the
   next lookup would be for bar1.bar0.za, and if that lookup were again
   not successful the third try would be for the full hostname of
   bar0.za.  An example SRV record that might appear in the bar0.za zone
   file is:

        ldap.tcp SRV 0 0 389 ldap.bar0.za

        If such a service is found in one of the DNS lookups, then an
   LDAP subtree search for a person object with a "mail" attribute EQUAL
   to the known email address is then used.  The search base for the
   search should be set to the empty string, since it is not obvious
   from examining the email address, what the appropriate search base
   should be.  It is presumed that most directory services will be
   optimized for fast lookups based on email addresses. If the email
   address is valid, and the LDAP server for the registered domain
   either has an entry for the person, or can generate a referal to
   another directory server (possibly non-LDAP, e.g. X.500, Whois++,
   etc.), then we're done, and we have (or will shortly have) the direc-
   tory entry in question.  Just as email administrators need to put MX
   records for each publicized domain in the email address, the direc-
   tory administrator needs to put SRV records for the various services
   for each publicized domain name.

        On the other hand, if the search fails, there are several ave-
   nues available to help find this user.


   -    the timeLimit parameter of the session control can be raised to
        a higher limit.

   -    do a SUBSTRING search against the "mail" attribute with just the



Greenblatt                                                      [Page 2]





Internet Draft                                                 July 1997


        name component

   -    an LDAP service for a more fully qualified domain (e.g.
        dc1.dc0.tld)
         can be looked up, again according to the definitions in [1]

   -    a well known indexing [2] Internet directory service can be
        queried for the email address

        Note that it is possible that there is no directory entry for
   the user, in which case all possible lookups will fail. If the user's
   email address and directory entry are controlled by different domains
   with no links between the two domains, it will not be possible to
   find the user's directory entry from the email address initially, but
   if an Indexed Internet directory that has retrieved the user's direc-
   tory entry from the second domain, then it is likely that the Indexed
   Internet directory will be able to generate a referal to the
   appropriate domain, even though we initially started out with no
   direct information about that domain. For example, a directory ser-
   vice for a small Internet Service Provider (smallisp.com) might be
   maintained by a wider area Directory Service (bigldap.org) on a con-
   tract basis. Thus, the search for an LDAP service for smallisp.com
   might fail, but the ldap lookup to the Indexing Internet Directory
   would result in a referal to bigldap.com. What is more likely to be
   the case is that smallisp.com will create an SRV record for its LDAP
   service that points to bigldap.com.

        Note that this mechanism works regardless of the DIT structure.
   The DIT hierarchy can be built by making use of the traditional "O="
   or "OU=" containers, or it can be built making use of alternative
   proposals along the lines of RFC 1279 [4].  This is due to the fact
   that the proposal assumes a particular DNS infrastructure rather than
   a particular X.500/LDAP infrastructure.

   2.  References

   [1]  A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the location
        of services (DNS SRV)," RFC 2052, October 1996.

   [2]  J. Allen, "The Common Indexing Protocol (CIP)," Internet Draft
        (work in progress) 19 November 1996.

   [3]  W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Pro-
        tocol", RFC 1777, March 1995.

   [4]  S. Kille, "X.500 and Domains", RFC 1279, November 1991.





Greenblatt                                                      [Page 3]





Internet Draft                                                 July 1997


   3.  Author's Address

           Bruce Greenblatt
           Novell
           2180 Fortune Drive
           San Jose, CA 95131
           USA
           Phone: +1-408-577-7688
           Fax: +1-408-577-7605
           Email: bgg@novell.com









































Greenblatt                                                      [Page 4]


==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com