The Cable Guy - December 2000

Quick Look at DNS Namespace Planning

By The Cable Guy

In Microsoft Windows NT 4.0 and earlier, server and service location operations were done through the resolution of NetBIOS names using NetBIOS name servers, such as those running Windows Internet Name Service (WINS). In Windows 2000, Active Directory-based server and service location are done by resolving Domain Name System (DNS) names using DNS servers. With Active Directory, a DNS infrastructure is required.

For example, to locate a domain controller, a computer running Active Directory queries a DNS server for SRV (service location) resource records that correspond to the Active Directory domain name. The DNS name of a domain controller is returned. The computer then queries a DNS server for A (address) resource records that correspond to the DNS domain name of the domain controller. Without a DNS infrastructure, computers running Active Directory are unable to locate domain controllers and other types of application servers.

DNS domains and Active Directory domains use similar structure for different namespaces. Each namespace stores different data and manages different objects. DNS uses zones and resource records, while Active Directory uses domains and domain objects. Therefore, it is critical that the DNS namespace is designed with Active Directory in mind and that the external namespace that exists on the Internet is not in conflict with the organization's internal namespace.

Designing a DNS Namespace for Windows 2000 Active Directory

The recommended approach to DNS design in an Active Directory environment is to design the Active Directory environment first and then support it with an appropriate DNS structure. In some cases, however, the DNS namespace might already be in place. In this case, the Active Directory environment should be designed independently and then implemented either as a totally separate DNS namespace or as a subdomain of the existing DNS namespace.

The Windows 2000 Active Directory Architecture white paper describes the Active Directory namespace, including the forest and tree domain structure, organizational units, the global catalog, trust relationships, and replication. The Windows 2000 Guide to Active Directory Design white paper describes the planning, design, and architectural criteria that network architects and administrators should consider when designing an Active Directory namespace for an organization. The recommendations in this white paper assist the network architect in designing an Active Directory namespace that can withstand company reorganizations without expensive restructuring.

When designing the DNS namespace, consider the following:

Identify the DNS namespace that you will be using for your domain

Identify the name that your organization has registered for use on the Internet (for example, <company>.com). If your company does not have a registered name, but you will be connected to the Internet, it is highly recommended to register a name on the Internet. If you choose not to register a name, make sure that you choose one that is unique. You can both review existing names and register for a name at https://www.networksolutions.com.

Use different internal and external namespaces

Internally, you could use <comp>.com (an abbreviation of your externally registered name that represents your internal DNS namespace) or a subdomain of the external name such as corp.<company>.com. The subdomain structure might be useful if you already have an existing external DNS namespace. Different geographic locations (wcoast.corp.<company>.com or ecoast.corp.<company>.com) or departments (sales.corp.<company>.com or research.corp.<company>.com) can then be named as subdomains to reflect your Active Directory domain structure.

Separate internal and external names on separate servers

External DNS servers should include only those names that you want to be visible to the Internet. Internal DNS servers should include names that are for internal use. You can set your internal DNS servers to forward requests that they cannot resolve to external servers for resolution. Different types of clients have different name resolution requirements. Web proxy clients, for example, do not require external name resolution because the proxy server does this for them.

Internal and external namespaces that overlap are not recommended. In most cases, the result of this configuration is that computers are unable to locate resources because they receive incorrect IP addresses from DNS. This is especially problematic when network address translation (NAT) is used and the internal IP address is in a range that is unreachable for external clients.

Choose computer names that are supported by DNS

It is strongly recommended that you use only characters in your computer names that are part of the Internet standard character set permitted for use in DNS host naming. Allowed characters are defined in RFC 952 as follows: all uppercase letters (A through Z), lowercase letters (a through z), numbers (0 through 9), and the hyphen (-).

For organizations using Windows NT 4.0 and NetBIOS names, computer names might need to be revised. NetBIOS names can contain the following special characters which are not allowed in DNS names (as specified in RFC 952): ! @ # $ % ^ & ' ) ( - _ { } ~ . [space]. To assist with the transition from Windows NT 4.0 NetBIOS names to Windows 2000 DNS domain names, the Windows 2000 DNS service includes support for extended ASCII and Unicode characters. However, this additional character support can only be used in a pure Windows 2000 environment.

Choose your DNS servers

At a minimum, DNS servers in your organization must support SRV resource records (as specified in RFC 2052). While SRV resource records can be manually configured on the appropriate DNS server, it is recommended that your DNS servers also support dynamic registration (as specified in RFC 2136). With dynamic registration support, Active Directory servers and clients can register their DNS records during startup, reducing manual configuration overhead. With Windows 2000, the number of records in the DNS needed to support Active Directory clients and servers increases. Therefore, it is recommended that your DNS servers also support incremental zone transfer (as specified in RFC 1995). An incremental zone transfer reduces network overhead by sending only the DNS records that have changed during zone replication—instead of the entire zone file.

If you decide to use the Windows 2000 DNS Server service (which supports RFCs 2052, 2136, and 1995), you have the option of deciding whether a particular zone is integrated into Active Directory. Normally, DNS zones must be administered on the server on which the master copy of the zone resides physically. However, an Active Directory-integrated zone can be modified from any domain controller using a multi-master replication model.

For More Information

For more information on Active Directory and DNS namespace design, including detailed examples, consult the following resources:

• Active Directory Architecture
• Deployment Planning Guide (Chapter 9 - Designing the Active Directory Structure)
• Guide to Active Directory Design
• Best Practices for Designing the Active Directory Structure
• Windows 2000 Domain Name System Overview
• Windows 2000 DNS White Paper
• Windows 2000 DNS chapter of the Windows 2000 Server Resource Kit
• Windows 2000 Server Documentation (Active Directory and Networking\DNS)

For a list of all The Cable Guy articles, click here.