D.0 How NetIQ 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 NetIQ eDirectory tree, or if you use a standalone application such as NetIQ iManager for Linux or the eDirectory install application to resolve a name in the tree and you don't have a server to talk to yet, 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.

eDirectory has traditionally used SAP and SLP to search for and advertise network services. DNS was added as a discovery protocol in eDirectory 8.7.1. This added functionality means that if you ask for a tree name that 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 NetIQ iManager or ConsoleOne, or a server—uses eDirectory's discovery protocols, in the following order:

  1. Domain Name System (DNS)

  2. Service Location Protocol (SLP)

  3. Service Advertising Protocol (SAP)

When using the DNS protocol, 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. 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, eDirectory would search for prod_server4.provo.novell.novell_inc.dev.novell.com and prod_server4.provo.novell.novell_inc.test.novell.com.

Then eDirectory takes components off the name that was passed to it. For example, if trying to resolve prod_server4.provo.novell.novell_inc, eDirectory tries provo.novell.novell_inc, then novell.novell_inc, then novell_inc. 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 eDirectory 8.7.1 or later.

We recommend putting your 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 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:

Record

Example

A

novell_inc.provo.novell.com. IN A 192.168.1.2

AAAA

novell_inc.provo.novell.com. IN AAAA 4321:0:1:2:3:4:567:89ab

SRV

_ldap._tcp.novell_inc.provo.novell.com. SRV 0 0 389 server1.novell_inc.provo.novell.com SRV 10 0 389 server2.novell_inc.provo.novell.com

For redundancy, or to specify multiple hosts (servers in the replica ring) to the A record, create more than one A record. 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.