Re: LDAP server location and DN->DNS mapping

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

RFC 2247 itself introduces an algorithm for transforming any
domain name to a DN *AND* to convert these DNs back into the
original domain names (last paragraph of section 3).

The purpose of the Locate I-D is to more fully specify the DN
to DNS mapping and to provide DNS SRV capabilities.

Like RFC 2247, the locate I-D should not define (nor preclude)
other DNS/DN equivalences.

If there may be other useful DNS/DN equivalences, they should
be specified separately from RFC2247/locate.

Kurt


At 10:58 PM 12/17/00 -0800, David Chadwick wrote:


>RL 'Bob' Morgan wrote:
>
>> But the problem draft-ietf-ldapext-locate is trying to solve is finding a
>> DS based on a DN, which I suspect folks in our community think is a
>> worthwhile problem to solve.
>> 
>>  - RL "Bob"
>
>Bob
>
>I question your assertion above on several counts. Firstly locate is not
>trying to solve the above for the general case, but only for a very
>limited case. Quoting from locate it states
>
>"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. "
>
>Thus locate is only solving the problem once you have a domain name or a
>dc based DN to map into a domain name. It does not even pretend to be
>solving the general problem you outlined above. This is OK, since domain
>names are widely known and used.
>
>Secondly, I think the problem itself is something of an oxymoron. DNs
>are not widely known or used. You actually use an LDAP directory to find
>a DN if you want one, not the other way around. People usually dont know
>DNs, nor do they really care what they are. Therefore if a client has in
>its possession a DN it must have come from somewhere. If it came from a
>certificate, then as you say there are alternative ways of finding the
>LDAP server from the contents of the certificate, rather than doing some
>arbitrary DN mapping based on the subject DN. If it did not come from a
>certificate, but some other place, then why not get the other place to
>pass an LDAP URL containing the DN, rather than just the DN on its own.
>This would solve the problem nicely. After all URLs are a much more
>common currency than DNs.
>
>Finally we as a group should really be trying harder to help LDAP
>servers hold more knowledge information about each other, then the
>problem above tends to disappear since a client then only needs to know
>about one LDAP server and this will plug it into the rest of the LDAP
>world. Imagine how the DNS would operate if every resolver had to find
>the location of the DNS server it wanted before it could make domain
>look ups.
>
>I therefore seriously question whether the general problem you outline
>above is a sensible one that we should even be attempting to solve.
>
>David