LDAP System Administration [Electronic resources] نسخه متنی

2.3 What Is the dc Attribute?

Returning to our discussion of the topmost entry in Figure 2-1, we can now explain the meaning of the
domain object class and the
dc
attribute. Here is the original LDIF listing for the entry:

# LDIF listing for the entry dn: dc=plainjoe,dc=org
dn: dc=plainjoe,dc=org
objectclass: domain
dc: plainjoe

The original recommendation for dividing the X.500 namespace was
based on geographic and national regions. You frequently see this
convention in LDAP directories as well, given the heritage that LDAP
shares with X.500. For example, under X.500, the distinguished name
for a directory server in the plainjoe.org
domain might be:

dn: o=plainjoe,l=AL,c=US

Here, the o attribute is the
organizationName, the l
attribute is the locality of the organization, and the
c attribute represents the country in which the
organization exists. However, there is no central means of
registering such names, and therefore no general way to refer to the
naming context of a directory server. RFC 2247 introduced a system by which LDAP
directory naming contexts can be piggybacked on top of an
organization's existing DNS infrastructure. Because
DNS domain names are guaranteed to be unique across the Internet and
can be located easily, mapping an organization's
domain name to an LDAP DN provides a simple way of determining the
base suffix served by a directory and ensures that the naming context
will be globally unique.

A directory's naming context is the DN of its topmost entry. The naming context of the directory in our examples is dc=plainjoe,dc=org. This context is used by the LDAP server to determine whether it will be able to service a client request. For example, our directory server will return an error (or possibly a referral) to a client who attempts to look up the information in an entry named cn=gerald carter,ou=people,dc=taco,dc=org because the entry would be outside our naming context. However, the server would search the directory (and return no information) if the client attempts to look up cn=gerald carter,ou=people,dc=taco,dc=plainjoe,dc=org. In this case, the directory's naming context does match the rightmost substring of the requested entry's DN. The server just does not have any information on the entry.

To support a mapping between a DNS domain name and an LDAP directory
namespace, RFC 2247 defines two objects, shown in Figures 2-6 and
2-7, for storing domain components. The dcObject
is an auxiliary class to augment an existing entry containing
organizational information (e.g., an
organizationalUnit). The domain
object class acts as a standalone container for both the
organizational information and the domain name component (i.e., the
dc attribute). The
organizationalUnit and domain
objects have many common attributes.

Figure 2-6. domain object class

Figure 2-7. dcObject object class

Generating an LDAP DN to represent a DNS domain name is a
simple process. An empty DN is used as a starting point. An RDN of
dc=domain
component is appended to the DN for each
portion of the domain name. For example, the domain name
plainjoe.org maps to our naming context of
dc=plainjoe,dc=org.

2.3.1 Where Is dc=org?

As we saw in the previous section,
dc=plainjoe,dc=org is the
directory's naming context. If the
directory's root entry was
dc=org, with a child entry of
dc=plainjoe,dc=org, then the naming context would
have been dc=org. Our server would then
unnecessarily respond to queries for any entry whose DN ended with
dc=org, even though it only has knowledge of
entries underneath dc=plainjoe,dc=org.

In this respect, designing an LDAP namespace is similar to designing a DNS
hierarchy. Domain name servers for plainjoe.org
have no need to service requests for the .org
domain. These requests should be referred to the server that actually
contains information about the requested hosts.