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

[RL 'Bob' Morgan <rlmorgan@cac.washington.edu>]

On Tue, 18 Jan 2000, James Benedict wrote:

> So not only does this method assume that the directory is arranged by
> DNS domain

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.

> but it also assumes that the directory is arranged by DNS domains that
> are externally exposed.

True.  Use of the referenced directory also depends on it being accessible
by the client.  If applications don't have access to the network resources
they need then they fail.  Presumably those doing deployments will do
their best to avoid this situation.  I'm not sure what conclusion to
draw.  If your point is that the DNS service supplying the SRV
records might have different access control than the LDAP directory
service that is being referenced, this is certainly true; in practice it
seems to me that DNS is much more likely to be Internet-accessible than an
LDAP DS.

> I actually believe that email, or web address is a better resolution
> mechanism, because they are more likely to point to an address that
> can be resolved on the internet.

The locate spec only specifies what to do if you're starting with a DN,
since DNs are how directory entries are named.  Mapping from the domain
part of an RFC-822 email address to a DN is defined in RFC 2247; if the
client arrives at the DN by this means, then discovers the D based on that
DN, then this would presumably do what you want.

I would say that deployment models of LDAP directories to take advantage
of dc-names and SRV records in order to form a DNS-name-based
Internet-wide directory service is a rich and interesting topic.  I'm sure
there will be further discussion ...

 - RL "Bob"