Locating Directory Servers in a Distributed Environment

To perform an operation on a particular entry, a client must be able to find the server in which that entry resides. In a distributed environment, information about the location of a server can be available in one of two ways:

• Statically, in the directory server usage file (ldap.ora) stored on the client host

• Dynamically, by using the domain name system (DNS). In this case, the information about server location is stored and managed in a central domain name server. The client, at request processing time, retrieves this information from the domain name server dynamically.

This section discusses these two methods of locating server information. It contains these topics:

• Static Directory Server Discovery by Using the Directory Server Usage File (ldap.ora)

• Dynamic Directory Server Discovery by Using the Domain Name System (DNS)

  See Also: "Discovering LDAP Services with DNS," Michael P. Armijo et alii (draft-ietf-ldapext-locate-08.txt) at http://www.ietf.org "A DNS RR for specifying the location of services (DNS SRV)", Internet RFC 2782 at http://www.ietf.org

Static Directory Server Discovery by Using the Directory Server Usage File (ldap.ora)

Using this method, when a client seeks to perform an operation on a directory entry, it obtains directory server location information from the directory server usage file (ldap.ora) stored on the client host. This file contains configuration parameters that specify:

• The type of directory server--for example, Oracle Internet Directory, Microsoft Active Directory, SunONE Directory Server, and so forth

• The location of the directory server

• The default directory entry that the client or server will use to look up or configure connect identifiers for connections to database services

The file ldap.ora resides in the file system of the LDAP client. When the client looks for this file, it follows this precedence:

• First, it looks at the file system directory pointed to by the LDAP_ADMIN environment variable

• Then it looks at the directory ORACLE_HOME/ldap/admin (or, on Microsoft Windows NT, ORACLE_HOME\ldap\admin)

• Then it looks at the file system directory pointed to by the TNS_ADMIN environment variable

• Finally, it looks at the directory ORACLE_HOME/network/admin (or, on Microsoft Windows NT, ORACLE_HOME\network\admin)

If the file ldap.ora is present in more than one location, then the location having higher precedence is honored.

Using the static method to discover a directory server can increase management overhead. For example, because the ldap.ora file is stored on the client host, the administrator must update that file on every client whenever the host name or port number of a directory server is changed. To avoid this increased overhead, you can enable an application to discover directory servers dynamically by using the domain name system (DNS).

Dynamic Directory Server Discovery by Using the Domain Name System (DNS)

The domain name system (DNS) is a dynamic way of locating domain names and translating them into the actual addresses of computers. This translation process is handled by a central domain name server, which contains information about the locations of directory servers.

Once a network administrator has entered the necessary information about directory server locations in a domain name server, clients can retrieve that information from that server instead of from ldap.ora files.

For a client to locate a directory server by using DNS, the following steps must have been completed:

• The network administrator must have entered a DNS Service Location Record (SRV) into the domain name server.

• The client application must have been enabled to map distinguished names to domain names.

How a Client Locates a Directory Server by Using DNS

To find the directory server on which an entry resides, a client communicates with the domain name server. Specifically, it provides to the domain name server a domain name. The domain name specifies where the needed directory server is located.

To generate the domain name, the client extracts the domain component from the DN entered by the user. For example, in the DN
cn=John Doe,ou=accounting,dc=example,dc=net, the domain component is dc=example,dc=net. That domain component represents the server on which the requested entry resides. The client then converts that domain name component to a domain name in a format recognized by the domain name server, namely, example.net.

Figure 5-4 and the accompanying text show the process of locating a directory server from the perspective of a client.

Figure 5-4 A Client Locating a Directory Server by Using DNS

Text description of the illustration oidag082.gif

1. A user wanting to perform an operation on a directory entry, enters into the client the distinguished name (DN) of that entry--for example, cn=John Doe,ou=accounting,dc=example,dc=net.

2. To communicate with the domain name server, the client converts the domain component of the DN to a domain name. In the example used here, the client would convert the domain component of that DN--namely, dc=example,dc=net--to the domain name example.net.

3. The client queries the domain name server for SRV resource records having the specified domain name.

4. The domain name server returns the SRV resource records that match the specified domain name. These resource records contain the host name information of the directory server containing the requested entry. If the domain name server is not able to find any matching SRV resource records, then it returns an error message.

5. The client parses the records. It extracts the directory host name information from these records and returns it to the user.

   See Also: P. Mockapetris, Domain Names--Concepts and Facilities (RFC 1034) at http://www.ietf.org P. Mockapetris, Domain Names--Implementation and Specification (RFC 1035) at http://www.ietf.org

   Note: The domain name server either stores all the necessary SRV records locally, or obtains them from other domain name servers. If the domain name server cannot find the requested information, then it returns an error message. It does not return a referral to another domain name server.

Registering a Directory Server with the Domain Name System

Registering server location information for a directory server involves entering a DNS service location record (SRV) into the domain name server. The SRV record contains:

• The DNS name of the server that provides the LDAP service

• The corresponding port number

• Parameters that enable the client to choose an appropriate server from multiple servers

The SRV resource record enables administrators to use several servers for a single domain, to move services from host to host easily, and to designate some hosts as primary servers for a service and others as backups.

The format of the SRV record can be either specific to Oracle Internet Directory servers or standard. For information about Oracle Internet Directory servers, the Oracle Internet Directory-specific format is preferred. When a client first queries a domain name server, it looks for SRV records that have the Oracle Internet Directory-specific format. If it does not find any with this format, then it queries for SRV records that have the standard format.

The Oracle Internet Directory-Specific Format for SRV Records

The Oracle Internet Directory-specific format is:

_Service._Proto._product.Domain TTL Class Type Priority Weight Port Target

Table 5-3 describes the arguments. The following is an example of an SRV record that uses the Oracle Internet Directory-specific format.

_ldap._tcp._oid.acme.com 0 IN SRV 0 1 389 ldap.acme.com

The Standard Format for SRV Records

The standard format is:

_Service._Proto.Domain TTL Class Type Priority Weight Port Target

Table 5-3 describes the arguments. The following is an example of an SRV record for a non-SSL-based directory server that uses the standard format.

_ldap._tcp.acme.com 0 IN SRV 0 1 389 ldap.acme.com

Table 5-3  Arguments in a Service Location Record (SRV)

Argument	Description
Service	For a non-SSL-based server, the value for this argument is ldap. For an SSL-based server, the value is ldaps.
Proto	The value is always tcp.
Product	The value is always oid.
Domain	The domain name. It is usually obtained by converting the DN of the naming context mastered by the directory server into a domain name. See Also: "How a Client Locates a Directory Server by Using DNS"
TTL	Time to live. This argument has the standard DNS meaning. It specifies how long the resource record may be cached before the source of the information is again consulted.
Class	This argument has the standard DNS meaning. SRV records occur in the IN class.
Type	For all SRV records, the value for this argument is SRV.
Priority	The priority of the directory server. A client must attempt to contact the target host with the lowest-numbered priority.
Weight	A server selection mechanism, this argument specifies a relative weight for entries with the same priority. If multiple SRVs have the same priority, then they are ordered according to the following protocol: To select a target to be contacted next, arrange in any order all SRV resource records that have not yet been ordered--but place all those with weight 0 at the beginning of the list. Compute the sum of the weights of those resource records, and with each resource record associate the running sum in the selected order. Choose a uniform random number between 0 and the sum computed (inclusive), and select the resource record whose running sum value is the first in the selected order that is greater than or equal to the random number selected. The target host specified in the selected SRV resource record is the next one to be contacted by the client. Remove this SRV resource record from the set of the unordered SRV resource records. Apply the described algorithm to the unordered SRV resource records to select the next target host. Continue the ordering process until there are no unordered SRV resource records. Repeat this process for each priority.
Port	The port on target host for the directory service.
Target	The domain name of the host on which the directory server is running.

Note: If the directory server is moved to a different host or is run on different port, then the corresponding SRV resource record must be updated accordingly.