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

From: "James Benedict" <[email-masked]>
Date: Tue, 18 Jan 2000 10:31:13 -0500

The problem with this method is that the resolving client must already
have knowledge about the directory containing the DN.  Specificly, the
resolving client must expect that the DC tree represented by the DN
is a valid internet domain.

For examlple, a an enterprise intranet directory for example.net may
have internal DNS domains internal.example.net and external.example.net
giving the DN "cn=External Person, ou=customers, dc=external, dc=example,
dc=net" However, this gives no guarentee that
_ldap._tcp.external.example.net
exists on the internet. In this case it is possible that
_ldap._tcp.external.net provides access to the referenced directory
structure.  

So not only does this method assume that the directory is arranged by DNS
domain, but it also assumes that the directory is arranged by DNS domains
that are externally exposed.

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.

James A Benedict
Advisor, IP Directory Systems Architecture
Carrier Packet Solutions
NORTEL NETWORKS
Ph:  (613) 763-3909

> -----Original Message-----
> From: RL 'Bob' Morgan [mailto:[email-masked]]
> Sent: Tuesday, January 18, 2000 4:15 AM
> To: Bruce Greenblatt
> Cc: [email-masked]
> 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?  If this mechanism doesn't
> > work for non-native LDAP servers, shouldn't the draft 
> explain why this
> > is the case?  I'd just drop this whole notion from the draft.
> 
> You're right that this method is useful independent of what 
> kind of LDAP
> server is to be discovered (it is of course only defined in 
> the case of
> DNs that map to DNS domain names); hence this text and the 
> "Internet based
> organization" bits are not needed.  Also, this paragraph:
> 
>    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.
> 
> is misleading since the method can be used by any process, client or
> server, that wants to determine server names from a DN.
> 
> I think this motivational material would be better put into 
> the taxonomy
> draft, which seems to me to be lacking in info about why you 
> would use one
> discovery technique over another.  The taxonomy draft should IMHO
> highlight the SRV-record approach, which in its limited 
> domain solves the
> problem quite nicely.
> 
> > Can this same mechanism be used to find an LDAP server from an email
> > address? It seems like you should be able to find the 
> appropriate SRV
> > record from an email address just as easy as you can from a DN that
> > conforms to the DC naming principles.
> 
> This would depend on whether the organization had chosen to 
> represent the
> entities with those email addresses (whatever those entities 
> are) as the
> corresponding directory entries.  This is recommended in RFC 
> 2377 but is
> obviously optional.  A DN presumably identifies a directory 
> object but an
> email address may or may not.  Also, IMHO finding a dir entry
> corresponding to an email address implies a search operation 
> for an entry
> with that email address as an attribute (which attribute 
> might vary based
> on what it is you're trying to do); whereas a DN obviously 
> identifies an
> entry directly.  There may be a doc to be written about 
> "finding directory
> entries based on RFC 822 email addresses" ...
> 
>  - RL "Bob"
> 
> 
>

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Tue, 18 Jan 2000 14:49:14 -0800 (PST)

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.

> 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"