D.0 How OpenText eDirectory Works with DNS

If a client asks a server to resolve a fully qualified name (for example, admin.novell.novell_inc) that does not exist in the OpenText eDirectory tree, or if you use a standalone application such as OpenText Identity Console for Linux or the OpenText eDirectory install application to resolve a name in the tree and you don't have a server to talk to yet, OpenText eDirectory uses service discovery protocols to resolve the name. Service discovery protocols are a class of network applications that allow distributed components to find and use needed services within a network.

OpenText eDirectory has traditionally used SAP and SLP to search for and advertise network services. DNS was added as a discovery protocol in OpenText eDirectory 8.7.1. This added functionality means that if you ask for a tree name that OpenText eDirectory doesn't understand (either because you are talking to a server that doesn't hold a copy of the tree or you are using a stand-alone application), the machine trying to do the discovery—whether it's a machine running a stand-alone application, a JClient application such as OpenText Identity Console or a server—uses OpenText eDirectory's discovery protocols, in the following order:

When using the DNS protocol, OpenText eDirectory takes the name as it was passed (for example, a server name such as prod_server4.provo.novell.novell-_inc), and tries to resolve the entire name just as it is. OpenText eDirectory then appends each name in the discovery machine's DNS search list and asks the machine's DNS server if it has an address for that name. For example, if the discovery machine's DNS search list included dev.novell.com and test.novell.com, OpenText eDirectory would search for prod_server4.provo.novell.novell_inc.dev.novell.com and prod_server4.provo.novell.novell_inc.test.novell.com.

Then OpenText eDirectory takes components off the name that was passed to it. For example, if trying to resolve prod_server4.provo.novell.novell_inc, OpenText eDirectory tries provo.novell.novell_inc, then novell.novell_inc, then novell_inc. OpenText eDirectory does that for each of the different search contexts until eventually it tries the single component that is the tree root. The client will attempt each of the addresses until it successfully makes a connection. It does the attempts using the ordering of records returned from the DNS server. It doesn’t matter what code revision the servers in the replica ring are running as long as the machine trying to do the discovery is running OpenText eDirectory 8.7.1 or later.

We recommend putting your OpenText eDirectory tree name in DNS using an A, AAAA, or Service (SRV) resource record under the DNS domain the clients are going to use to resolve names. If you use A or AAAA records, the OpenText eDirectory servers must be running on the default 524 port. If the servers are using any other port, use an SRV record.

In the following sample resource records, novell_inc is the tree name and provo.novell.com is the DNS search context:

For redundancy, or to specify multiple hosts (servers in the replica ring) to the A record, create more than one A record. OpenText eDirectory will look at all of them. For more information on A, AAAA, and SRV records, see “DNS resource records”.

You don't need to point the DNS server record entry to something that holds a corresponding partition root. As soon as the discovery machine can talk to a server that knows about the tree, it can walk up and down the tree to resolve the name. For example, if you put novell_inc in your DNS, you don't have to put in any of the servers that hold novell_inc root. All you need to do is point to any server in the novell_inc tree, because after you get to that server in the tree, that server will refer you around the tree.