4.2 Namespace and name resolution

---

4.2.1 Domain name system

Exchange is a network-based product that resides in the applications layer of the TCP/IP Reference Model. As a network-based product, it is highly dependent on the network transport and protocol support provided by the underlying network. Although the Exchange server packages e-mail messages for delivery, it is actually the underlying network that transports the message to the recipient's environment. Client systems also use the network infrastructure to communicate with the Exchange servers. Before a client or server can communicate with another server, it must be able to translate the target server's name into an address. A properly functioning name resolution system is an essential component of any networked environment.

Windows NT 4.0 and Exchange Server 5.5 used two methods of name resolution:

• Windows Internet Naming Service (WINS). WINS provided Net-BIOS over TCP/IP (NetBT) name resolution for Windows NT 4.0. WINS was the preferred name resolution method for Windows NT 4.0 primarily because it supported dynamic name registration.

• Domain Name System. DNS provided Winsock-based name resolution. By default, both Exchange and Outlook used DNS for name resolution because they used the Winsock layer for communications.

Active Directory and Exchange 2000/2003 use DNS for name resolution. Neither Windows nor Exchange will operate if you do not have a DNS service running on your network. Although Exchange has always relied on DNS, the extensive use of DNS by the operating system is new. All domain names and the Windows namespace are stored in DNS. The location of DCs is stored in DNS using Service Resource Records to map service names. DNS, rather than WINS, is now used for logon validation and domain validation.

DNS is primarily used to record the names and locations of systems and services, whereas the Active Directory is used to store object and attribute information. Windows uses LDAP to find Active Directory objects and elements. Table 4.5 compares the relative advantages of DNS and LDAP for locating information.

Table 4.5: Domain Name System and Lightweight Directory Access Protocol

DNS	LDAP
Hierarchical, distributed, partitioned, replicated	Emerging standard
Most-used naming service	Great for fine-grained attributes and lookups
Great for finding systems	Used to access objects inside a domain
Not good for accessing fine-grained attributes
Used to find LDAP server that is a domain controller
DNS, Domain Name System; LDAP, Lightweight Directory Access Protocol

The DNS naming scheme is standards based (RFC 1034 and RFC 1035) and provides maximum interoperability with Internet technologies. The DNS used in your Active Directory environment must also support Service Resource Records (RFC 2052). It is also advisable that the DNS you choose also support the following features:

• Dynamic Update (RFC 2136). With dynamic updates, the net logon service on the DC will automatically register domain services and sites. This reduces the need to manually update DNS records and reduces human errors.

• Incremental Zone Transfers (RFC 1995). Incremental Zone Transfers reduce the network bandwidth requirements for replicating information to all DNS servers.

The DNS service that is supplied with Windows Server supports all of these features. Your DNS strategy needs to be planned early and implemented before you deploy Active Directory. Carefully consider the names you will use, because after you choose and deploy the names any changes may be difficult.

The DNS root domain name will be the name used for the root of your Active Directory forest. The root domain name should be meaningful, available, registered, and stable. Management and legal approval are usually required for DNS root domain names because these are known to the public.

You will need to determine the zones that need to be created. You should ensure that you have a zone for each domain so that you can integrate DNS into the Active Directory if you decide to do so at some point, either immediately or in the future.

You also need to consider the names that will be used. Remember that each system will be represented by a fully qualified DNS name (e.g., server89.dallasdomain.company.com). The names should be meaningful, but they also should be short because the fully qualified name can become rather lengthy and difficult to use. You should use only characters that are part of the character set permitted for use in DNS host naming. These characters include all letters (both uppercase and lowercase), numbers, and the hyphen (-).

Exchange relies on specific DNS services, and it relies on Service Resource Records to locate DCs, GC servers, and sites. Exchange does not enter any Service Resource Records for the Exchange servers. Instead, Exchange servers are registered in DNS as Address (A) records, and Exchange uses these Address records to locate other Exchange servers in the forest. Exchange also uses DNS Mail Exchanger records to identify Exchange and non-Exchange mail servers that support different domain namespaces. SMTP (including the Exchange SMTP connector) uses the Mail Exchanger records to locate preferred SMTP mail servers.

In addition, some Exchange components use Internet Information Server web services. For example, Outlook Web Access has an associated namespace. DNS aliases can be used to provide users with a more friendly representation of the namespace.

By default, the Active Directory domain name as registered in DNS is used as part of the e-mail address for users within the domain. For example, users in the dallas.company.com domain have e-mail addresses of the form [e-mail]. However, this need not be the case. Although a user's Active Directory logon name might be [e-mail], the generation of e-mail addresses can be controlled using the following procedure:

1. Start ESM from the Windows Start menu by selecting All Programs →Microsoft Exchange →System Manager.

2. Select Recipients →Recipient Policies and then double-click Default Policy to display the Default Policy Properties (Figure 4.14). The E-Mail Addresses tab contains the default e-mail address general rules.

   
   Figure 4.14: E-Mail Address (Policy) window

Windows Internet naming service

WINS and NetBIOS are still supported by Windows. In fact, Windows has enhanced WINS by adding manual tombstoning, improved management tools, enhanced filtering, and dynamic record deletion. Although Active Directory no longer relies on WINS, WINS is still used by Windows NT 4.0 domain members in a mixed environment and by legacy applications.

You should evaluate your use of WINS. For an existing Windows NT environment that is migrating to Active Directory, you will need to keep WINS running for coexistence. You should consider how names would be supported in both DNS and WINS because clients may be using either one to access resources.

4.2.2 Active Directory naming contexts

Active Directory naming contexts define boundaries for holding specific types of Active Directory information. Each naming context partition has its own permissions structure, replication configuration, and other properties. Active Directory has three default naming contexts: Configuration, Domain, and Schema. The following sections briefly describe the three naming contexts and how Exchange uses them.

Configuration naming context

The configuration naming context contains Exchange information such as address list services, addressing templates, display templates, administrative groups, routing groups, connections to other Exchange servers, recipient policies, instant messaging settings, message delivery settings, and Internet message formats. Exchange servers use the configuration naming context to hold most of the Exchange-specific information. Because the configuration naming context is common to all DCs within the forest, Exchange servers can query a local DC to get this type of information.

Domain naming context

The domain naming context defines the boundaries of the Active Directory domain and contains all objects for the domain. The domain naming context is unique to each domain within a forest, and this information is replicated only to other DCs within the same domain. The domain naming context contains Exchange information such as mailboxes, mail-enabled users, groups, contacts, and public folder definitions.

Schema naming context

The schema naming context contains the class definitions for objects within the Active Directory. The class definitions are the rules that define the attributes that must be included with each specific type of object, the attributes that may be included with each object, and the place within the Active Directory hierarchy that each type of object may be created. When the Active Directory is created, a default schema is created that defines all object classes needed by Windows. Exchange extends the schema during the Exchange installation to add object classes and attributes needed by Exchange.

---