NDS eDirectory/DNS Integration

DNS has many similarities with NDS. For example, both DNS and NDS eDirectory are:

Hierarchical

DNS follows a naming structure that is nearly identical to that of NDS eDirectory. DNS has a naming tree root, and all names branch from that root. See Figure 39

Figure 39
Typical DNS Naming Structure

DNS zones can be partitioned by keeping the data in separate files if management of the zone stays with the same set of servers. If the parent zone administrator wants to delegate a sub-zone (and thus relinquish management responsibility), the sub zone can be delegated and management handed off to other individuals or organizations.

Figure 40
DNS Tree Structure Showing Delegated Zone Boundaries

Replicated

To maintain reliability of DNS data, zone information can be replicated through zone transfers from primary master servers to other primary slave servers. These servers act as backups in case something happens to one of the other servers.

Object Based

As shown in Figure 40, each node is an object that can hold information. In DNS, the information is limited to addresses for services or aliases to other objects. NDS eDirectory, on the other hand, can store a wide variety of information and thus can be used as a general repository.

DNS Integration

The intent of DNS integration is to allow NDS objects to also become DNS objects. This has the following benefits:

Data reuse eliminates data duplication.
Automatic referential integrity performed by NDS sub-systems.
This allows certain data items to be updated automatically (for example, Network Addresses) and thus immediately reflected in the DNS system.
Simplified management caused by the consolidation of the data repository for DNS into the NDS system.
This lets you use NDS utilities to manage DNS.

NDS eDirectory 8.5 has the ability to be integrated into the DNS name space. In order to better understand this concept and how this is accomplished, the following terms are explained in Table 129.

Table 129.

Term	Description
Management tree or domain	Defines a boundary where management is contained. Each management domain is independent from other management domains.
Management root	The location where the management domain begins.
Naming tree or hierarchy	Defines the structure of the naming within a namespace.
Naming root	The location that defines the root object within the namespace. In the DNS namespace the naming root is " ". For NDS, the naming root is the tree name.
Schema domain	The NDS schema is globally shared by all servers within a given schema domain. The schema domain and management domain are the same in NDS eDirectory 8.5 and prior directory versions.
Schema root	The location that defines the root of the schema domain within NDS. The schema root and management root are the same in NDS eDirectory 8.5 and prior directory versions.
DNS name space	The Internet naming standard. Name format is hierarchical, replicated, and distributed.
Independent tree	Term used to describe legacy NDS tree structures. In this type of tree, the naming root, schema root, and management root are the same and start at the root of the tree hierarchy.
Federation boundary	This is an auxiliary class applied to the management root object denoting the start of a management domain and schema domain in NDS.

By separating the naming root from the management root, NDS eDirectory can be constructed such that a unique management domain can exist without the global DNS namespace. Once configured, any valid name outside the management boundary can be found through the DNS resolver mechanism.

For each eDirectory server participating in a DNS rooted tree environment, the DNS resolver configuration must be correct.

Table 130.

Platform	DNS Resolver Configuration
NetWare^®	Make sure the file SYS:\ETC\RESOLV.CFG exists and is correct.
Windows* NT*/2000	Use Network Configuration to verify the DNS setup.
Linux, Solaris, or Tru64 UNIX*	Make sure the file /ETC/RESOLV.CONF file exists and is correct.

When NDS attempts to find other DNS-rooted trees through DNS, the record queries in Table 131 are performed:

Table 131.

DNS Server	Query
BIND 8.x only - RFC 2782	DNS SRV records are queried using the following format: _NDAP._TCP.domain_name and _NDAP._UDP.domain_name where _NDAP denotes the Novell Directory Access Protocol service, _TCP or _UDP are the transport types, and domain_name is the DNS name being resolved.
BIND 4.x or BIND 8.x	A records are queried using the following format: NDS.domain name where domain_ name denotes the name being resolved.

For example, if NDS needs to resolve ADMIN.ACME.COM from another DNS rooted tree, it would first attempt to find SRV records _NDAP._TCP.ACME.COM then _NDAP._UDP.ACME.COM. If both of these failed, NDS will query for A records using the name NDS.ACME.COM. If this fails, an error is returned.