Designing a DNS Namespace

Before you deploy a DNS infrastructure, the DNS designer in your organization must design a DNS namespace. You can design an external namespace that is visible to Internet users and computers, or you can design an internal namespace that is accessible only to users and computers that are within the internal network. After your DNS namespace has been deployed, DNS administrators are responsible for managing and maintaining the DNS namespace. Figure 3.3 shows the process for designing a DNS namespace.

Figure 3.3: Designing a DNS Namespace

Identifying Your DNS Namespace Requirements

The first step in designing a DNS namespace is to determine whether you need a new namespace for your organization, or whether you can retain an existing Windows or third-party DNS namespace.

Important

You must plan your DNS namespace in conjunction with planning your Active Directory logical structure. For more information about designing the Active Directory logical structure, see "Designing the Active Directory Logical Structure" in Designing and Deploying Directory and Security Services of this kit.

Table 3.2 summarizes the DNS namespace design requirements for each possible scenario.

Table 3.2: DNS Namespace Design Requirements

Scenario	Design Requirements
You are upgrading an existing DNS infrastructure from a version of Windows earlier than Windows Server 2003.	DNS namespace design can remain the same.
You are upgrading from a third-party DNS infrastructure that uses DNS software that adheres to standard DNS domain naming guidelines.	DNS namespace design can remain the same.
Your existing DNS software does not conform to standard DNS domain naming guidelines.	Bring your existing DNS namespace design into compliance with DNS domain naming guidelines before deploying a Windows Server 2003 DNS namespace.
You are integrating Windows Server 2003 DNS into an existing third-party DNS software that adheres to standard DNS domain naming guidelines.	Integrate Windows Server 2003 DNS with your current DNS infrastructure. You do not need to change the namespace design of the third-party DNS infrastructure or your existing namespace.
You are deploying a new Windows Server 2003 DNS infrastructure.	Design a logical naming convention for your DNS namespace based on DNS domain naming guidelines.
You are deploying Windows Server 2003 DNS to support Active Directory.	Create a DNS namespace design that is based on your Active Directory naming convention.
You are modifying your existing DNS namespace to support Active Directory, but you do not want to redesign your DNS namespace.	Ensure that Active Directory domain names match your existing DNS names. This enables you to deploy the highest level of security by using the simplest management techniques.

Creating Internal and External Domains

Organizations that require an Internet presence as well as an internal namespace must deploy both an internal and an external DNS namespace and manage each namespace separately. You can create a mixed internal and external DNS namespace in one of two ways:

• By making the internal domain a subdomain of the external domain.

• By using different names for the internal and external domains.

Note

You can also use the same name for the internal domain and the external domain. However, this method is not recommended. It creates name resolution problems because it introduces DNS names that are not unique. This method requires additional configuration to enable optimized performance.

Select the configuration design option that best meets the needs of your organization. Table 3.3 lists the design options for deploying a mixed internal and external namespace and the level of management complexity for each option, along with an example to illustrate each option.

Table 3.3: Mixed Internal and External DNS Namespace Design Options

Design Option	Management Complexity	Example
The internal domain is a subdomain of the external domain.	Easy to deploy and administer.	An organization with an external namespace contoso.com uses the internal namespace corp.contoso.com.
The internal and external domain names are different from each other.	More complicated than previous option.	An organization uses contoso.com for its external namespace, and corp.internal for its internal namespace.

Using an Internal Subdomain

The recommended configuration option for a mixed internal and external DNS namespace is to make your internal domain a subdomain of your external domain. For example, an organization that has an external namespace domain name of contoso.com might use the internal namespace domain name corp.contoso.com. Using an internal domain that is a subdomain of an external domain:

• Requires you to register only one name with an Internet name authority even if you later decide to make part of your internal namespace publicly accessible.

• Ensures that all of your internal domain names are globally unique.

• Simplifies administration by enabling you to administer internal and external domains separately.

You can use your internal subdomain as a parent for additional child domains that you create to manage divisions within your company. Child domain names are immediately subordinate to the DNS domain name of the parent. For example, a child domain for the human resources department that is added to the us.corp.contoso.com namespace might have the domain name hr.us.corp.constoso.com.

Using Different Internal and External Domain Names

If it is not possible for you to configure your internal domain as a subdomain of your external domain, use a stand-alone internal domain. This way, your internal and external domain names are unrelated. For example, an organization that uses the domain name contoso.com for their external namespace uses the name corp.internal for their internal namespace.

The advantage to this approach is that it provides you with a unique internal domain name. The disadvantage is that this configuration requires you to manage two separate namespaces. Also, using a stand-alone internal domain that is unrelated to your external domain might create confusion for users because the namespaces do not reflect a relationship between resources within and outside of your network. In addition, you might have to register two DNS names with an Internet name authority if you want to make the internal domain publicly accessible.

Deciding Whether to Deploy an Internal DNS Root

If you have a large distributed network and a complex DNS namespace, it is best to use an internal DNS root that is isolated from public networks. Using an internal DNS root streamlines the administration of your DNS namespace by enabling you to administer your DNS infrastructure as if the entire namespace consists of the DNS data within your network.

If you use an internal DNS root, a private DNS root zone is hosted on a DNS server on your internal network. This private DNS root zone is not exposed to the Internet. Just as the DNS root zone contains delegations to all of the top-level domain names on the Internet, such as .com, .net, and .org, a private root zone contains delegations to all of the top-level domain names on your network. The DNS server that hosts the private root zone in your namespace is considered to be authoritative for all of the names in the internal DNS namespace.

Using an internal DNS root provides the following benefits:

• Simplicity. If your network spans multiple locations, an internal DNS root might be the best method for administering DNS data in a network.

• Secure name resolution. With an internal DNS root, DNS clients and servers on your network never contact the Internet to resolve internal names. In this way, the DNS data for your network is not broadcast over the Internet. You can enable name resolution for any name in another namespace by adding a delegation from your root zone. For example, if your computers need access to resources in a partner organization, you can add a delegation from your root zone to the top level of the DNS namespace of the partner organization.

Important

Do not reuse names that exist on the Internet in your internal namespace. If you repeat Internet DNS names on your intranet, it can result in name resolution errors.

If name resolution is required by computers that do not support software proxy, or by computers that support only LATs, then you cannot use an internal root for your DNS namespace. In this case, you must configure one or more internal DNS servers to forward queries that cannot be resolved locally to the Internet.

Table 3.4 lists the types of client proxy capabilities and whether you can use an internal DNS root for each type.

Table 3.4: Client Proxy Capabilities

Proxy Capability	Microsoft Software with Corresponding Proxy Capabilities	Forwards Queries	Can You Use an Internal Root?
No Proxy	Generic Telnet	•
Local Address Table (LAT)	Winsock Proxy (WSP) 1.x and later Microsoft Internet Security and Acceleration (ISA) Server 2000 and later	•
Name Exclusion List	WSP 1.x and later Internet Security and Acceleration (ISA) Server 2000 and later, and all versions of Microsoft Internet Explorer	•	•
Proxy Auto-configuration (PAC) File	WSP 2. x, Internet Security and Acceleration Server (ISA) Server 2000 and later, Internet Explorer 3.01 and later	•	•

Configuring Name Resolution for Disjointed Namespaces

If you need to create or merge two DNS namespaces when you deploy Windows Server 2003 DNS, this can result in disjointed namespaces — a DNS infrastructure that includes two or more top-level DNS domain names. To configure internal name resolution for multiple DNS top-level domains, you must do one of the following:

• If you have an internal DNS root, add delegations for each top-level DNS zone to the internal DNS root zone.

• If you want to reduce cross-domain DNS query traffic, configure the DNS servers that host the DNS zones in the first and second namespaces to host secondary zones for the DNS zones in each other's namespaces. In this configuration, the DNS servers that host the DNS zones in each namespace are aware of the DNS servers in the other namespace. This solution requires increased storage space for hosting secondary copies of zones in different namespaces, and generates increased zone transfer traffic.

• If storage capacity on DNS servers is a consideration, configure the DNS servers that host the DNS zones in one namespace to forward name resolution queries in a second namespace to the DNS servers that are hosting the DNS zones for the second namespace. Then configure the DNS servers that host the DNS zones in the second namespace to forward name resolution queries in the first namespace to the DNS servers that are hosting the DNS zones for the first namespace. You can use Windows Server 2003 DNS conditional forwarders for this configuration.

You can also use Windows Server 2003 DNS stub zones to facilitate DNS data distribution between separate namespaces. For more information about conditional forwarders and stub zones, see Help and Support Center for Windows Server 2003 and the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Integrating a Windows Server 2003 DNS Infrastructure Into an Existing DNS Namespace

Windows Server 2003 DNS is standards-compliant and interoperates with other implementations of DNS, including Microsoft Windows NT version 4.0, BIND 9.1.0, BIND 8.2, BIND 8.1.2, and BIND 4.9.7. The complexity of your integration process depends, in part, on the DNS features that you need to support. If the computers in your DNS infrastructure are running versions of DNS that support the same features, then integrating the Windows Server 2003 DNS infrastructure is a simple process. If the computers in your DNS infrastructure are running versions of DNS that do not support the same DNS features, then the integration process is more complex.

Table 3.5 compares feature support in Windows Server 2003 DNS and other implementations of DNS.

Table 3.5: Feature Support in Different Implementations of DNS

Feature	Windows Server 2003	Windows 2000	Windows NT 4.0	BIND 9	BIND 8.2	BIND 8.1.2	BIND 4.9.7
Supports RFC 2782: A DNS RR for specifying the location of services (DNS SRV)	•	•	•	•	•	•	•
Dynamic update	•	•		•	•	•
Secure dynamic update based on the GSS-Transaction signature (TSIG) algorithm	•	•
WINS and WINS-R records	•	•	•
Incremental zone transfer	•	•		•	•
UTF-8 character encoding	•	•
DNS MMC snap-in	•	•
Dnscmd.exe	•	•
Active Directory-integrated zones	•	•
Storage of zones in the DNS application directory partition	•
Aging and scavenging of obsolete records	•	•
Stub zones	•	•		•
Conditional forwarding	•			•

Creating DNS Domain Names and Computer Names

Before you deploy your Windows Server 2003 DNS infrastructure, you must create a naming convention for your DNS Internet and internal domains and the DNS computers on your network. To create a DNS naming convention, you must establish the following:

• An Internet DNS domain name, if your organization is connected to the Internet.

• An internal DNS domain name for your organization.

• A DNS resource naming convention.

In addition, you must determine whether you need to support NetBIOS names in your organization.

Creating an Internet DNS Domain Name

If you are deploying a new Windows Server 2003 DNS infrastructure that is connected to the Internet, you must create an Internet DNS domain name for your organization. Because all of the nodes in your network that require name resolution are assigned a DNS name that includes the Internet DNS domain name for your organization, it is important to select an Internet DNS domain name that is short and easy to remember. Because DNS is hierarchical, DNS domain names grow when you add subdomains to your organization. Short domain names result in computer names that are easy to remember, facilitating resource access.

A DNS namespace that is connected to the Internet must be a subdomain of a top-level or second-level domain of the Internet DNS namespace. If you are deploying a new Windows Server 2003 DNS namespace, you must select a top-level Internet DNS domain in which to register your Internet DNS domain name. For example, you can register your domain as a subdomain of .com, .org, or .net, or as a subdomain of the domain name that is assigned to your country/region, such as .au (Australia), .fr (France) or .ca (Canada).

When you have selected your Internet DNS domain name and identified the top-level domain for which your DNS domain is a subdomain, complete the following steps to register your DNS domain name:

1. Search the Internet to confirm that the DNS domain name that you selected for your organization is not registered to another organization. If the DNS domain name that you selected is owned by another organization, you can attempt to buy it from that organization, or select a different DNS domain name.

2. Configure at least one authoritative DNS server to host the DNS zone for your domain name. This DNS server might be located on your network or on the network of your ISP.

3. Register your DNS domain name with an Internet registrar, and supply the registrar with the DNS name and IP address of at least one DNS server that is authoritative for your DNS domain name. For a list of Internet registrars, see the ICANN link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

The Internet domain name registration process varies according to the design of your DNS namespace. Table 3.6 lists the domain names that you need to register for each type of DNS namespace design.

Table 3.6: Internet DNS Domain Name Registration

Namespace Design	Domain Name Registration	Example
The internal domain name is a subdomain of the external domain.	Register only the external domain name.	The domain name contoso.com is used for the external namespace. The domain name corp.contoso.com is used for the internal namespace.
The internal and external domain names are different from each other.	Register the external domain name, and then, if you want the internal domain to be publicly accessible, also register the internal domain name.	The domain name contoso.com is used for the external namespace. The domain name corp.contoso.com is used for the internal namespace.

When you register your DNS domain name, the Internet registrar creates a delegation in the DNS zone that is authoritative for the top-level domain that you selected. This is the top-level domain for the DNS servers that are authoritative for your organization's Internet DNS domain name.

Note

If a domain name that you want to register is not available in one top-level domain, such as .com, and you register the same domain name in another top-level domain, such as .net, then people who are searching for your domain name on the Internet might assume that computers and services in the wrong top-level domain belong to your company.

Creating Internal DNS Domain Names

When creating names for your internal domains, use the following guidelines:

• If your organization has an Internet presence, use names relative to your registered Internet DNS domain name. For example, if you have registered the Internet DNS domain name contoso.com for your organization, use a DNS domain name such as corp.contoso.com for your intranet domain name.

• Do not use the name of an existing corporation or product as your domain name.

• Do not use top-level Internet domain names, such as .com, .net, .org, .us, .fr, .gr, on your intranet. Using top-level Internet domain names on your intranet can result in name resolution errors for computers on your network that are connected to the Internet.

• Do not use acronyms or abbreviations for domain names. The business units that these acronyms represent can be difficult for users to recognize.

• Do not use business unit or division names for domain names. Business units and other divisions change periodically and the domain names can become obsolete or misleading.

• Do not use geographic names that are difficult to spell and remember.

• Avoid extending your DNS domain name hierarchy more than five levels from the internal or DNS root domain. Limiting the extent of the domain name hierarchy reduces administrative costs.

If you are deploying DNS in a private network and do not plan to create an external namespace, it is recommended that you register the DNS domain name that you create for your internal domain. If you do not register the name and later attempt to use it on the Internet, or connect to a network that is connected to the Internet, you might find that the name is unavailable.

Creating DNS Computer Names

It is important to develop a practical DNS computer naming convention for your network. This enables users to remember the names of computers on public and private networks easily, and therefore facilitates access to resources on your network.

The DNS computer name creation process varies according to whether you are creating a new DNS infrastructure, integrating your DNS infrastructure with an existing third-party infrastructure, or upgrading an existing DNS infrastructure.

Creating Computer Names in a New Windows Server 2003 DNS Infrastructure

Use the following guidelines when creating names for the DNS computers in your new Windows Server 2003 DNS infrastructure:

• Select computer names that are easy for users to remember.

• Identify the owner of a computer in the computer name. For example, john-doe-1 indicates that John Doe uses the computer.

• Select names that describe the purpose of the computer. For example, a file server named past-accounts-1 indicates that the file server stores information related to past accounts.

• Do not use character case to convey the owner or purpose of a computer. DNS is not case-sensitive.

• If you are deploying DNS to support Active Directory, match the Active Directory domain name to the primary DNS suffix of the computer name. For more information about designing the Active Directory logical structure, see "Designing the Active Directory Logical Structure" in Designing and Deploying Directory and Security Services of this kit.

• Use unique names for all computers in your organization. Do not assign the same computer name to different computers in different DNS domains.

• Use ASCII characters to ensure interoperability with computers running versions of Windows earlier than Windows 2000. For DNS computer names, use only the characters listed in RFC 1123:Requirements for Internet Hosts — Application and Support, which include A-Z, a-z, 0-9, and the hyphen (-). Windows Server 2003 DNS supports almost any UTF-8 character in a name; however, do not use extended ASCII or UTF-8 characters unless all of the DNS servers in your environment support them.

Note

Windows Server 2003 DNS is configured to use UTF-8 name checking by default.

Creating Computer Names in an Integrated DNS Infrastructure

If you are integrating Windows Server 2003 DNS with an existing third-party DNS infrastructure, you do not need to make any changes to your third-party DNS host names. If you are migrating to Windows Server 2003 DNS from a third-party DNS infrastructure, you must ensure that the host names that are used in the third-party DNS infrastructure conform to the DNS Internet naming standards.

If you are integrating or migrating an existing public DNS infrastructure that is connected to the Internet into your existing DNS infrastructure, you do not need to make any changes to the DNS domain names of your infrastructure.

Creating Computer Names When Upgrading a DNS Infrastructure

If you are upgrading to Windows Server 2003 DNS from Windows NT 4.0, you do not need to change your DNS host names; however, you might need to convert any NetBIOS names to DNS names. DNS names must conform to the DNS standard defined by RFC 1123.

Table 3.7 lists the different character sets that are supported by standard DNS, Windows Server 2003 DNS, and NetBIOS.

Table 3.7: Character Set Restrictions

Character Set Restriction	Standard DNS (Including Windows NT 4.0)	DNS in Windows 2000 and Windows Server 2003	NetBIOS
Characters permitted	Supports RFC 1123, which permits A-Z, a-z, 0-9, and the hyphen (-).	Supports RFC 1123 and UTF-8. On a per-server basis, You can configure the Windows 2000 DNS Server service to allow or disallow the use of UTF-8 characters on your DNS server.	Not allowed: Unicode characters, numbers, white space, symbols: / \ [ ] : | < > + = ; , ? and *)
Maximum host name and FQDN length.	63 octets per label. 255 bytes per FQDN (254 bytes for the FQDN plus one byte for the terminating dot).	The same as standard DNS with the addition of UTF-8 support. Character count is insufficient to determine size because some UTF-8 characters exceed one octet in length. Domain controllers are limited to 155 bytes for an FQDN.	16 bytes in length.

Important

Names encoded in UTF-8 format must not exceed the limits defined in RFC 2181: Clarifications to the DNS Specification, which specifies a maximum of 63 octets per label and 255 octets per name.

Determining if You Need to Support NetBIOS Names

During a domain upgrade to Windows Server 2003, you might need to support NetBIOS on your network if your domain includes clients that are running versions of Windows earlier than Windows 2000. For example, if your network is multi-segmented, WINS is required to create the NetBIOS browse list. Without WINS, the network must rely on Active Directory for browsing resources. This can have a significant impact on clients that are running applications that require NetBIOS support, even if the client operating system does not require NetBIOS support. When WINS is installed, performance monitor counters for WINS are also installed. Use these WINS performance monitor counters to determine how many queries WINS is receiving, and how many names WINS is resolving. This information will help you to determine whether it is necessary to support NetBIOS names on the network.

Windows Server 2003 DNS is compatible with WINS; therefore, in a mixed networking environment, you can use a combination of DNS and WINS. Windows NT 4.0-based clients can register in both Windows 2000 WINS and Windows Server 2003 WINS. Also, computers running either the Microsoft Windows 2000 Professional or Windows XP Professional operating systems can register in Windows NT 4.0 WINS. To maintain backward compatibility, each computer is given a NetBIOS name that must be unique in the domain to which the computer belongs.

Preserving existing NetBIOS names can be difficult because NetBIOS names have a broader character set than DNS names. One solution is to replace NetBIOS names with DNS names to ensure that the names adhere to existing DNS naming standards. This is not possible for organizations that support computers running versions of Windows earlier than Windows 2000.

RFC 2181: Clarifications to the DNS Specification expands the character set that is allowed in DNS names to include any binary string. The binary strings do not have to be interpreted as ASCII. Windows 2000 and Windows Server 2003 support UTF-8 character encoding (RFC 2044). UTF-8 is a superset of ASCII and a translation of the UCS-2 (or Unicode) character encoding. The UTF-8 character set enables you to transition from Windows NT 4.0 NetBIOS names to Windows 2000 and Windows Server 2003 DNS names

By default, multibyte UTF-8 name checking is used. This provides the greatest tolerance when the DNS service processes characters. This is the preferred name-checking method for most DNS servers that are not providing name resolution services for Internet hosts.

Important

Windows Server 2003 and Windows 2000 DNS support NetBIOS and UTF-8 characters for computer names. Other versions of DNS only support the characters permitted in RFC 1123. Therefore, only use NetBIOS and UTF-8 character sets when you are certain that Windows Server 2003 or Windows 2000 DNS is the method used for name resolution. Names that are intended to be visible on the Internet must contain ASCII-only characters, as recommended in RFC 1123.

Creating Subdomains

If you are deploying DNS on a large enterprise network, or if you expect your network to expand to include additional subnets and sites, consider distributing the management of portions of your DNS namespace to the administrators for the different subnets and sites in your network. To distribute the management of your DNS namespace, create subdomains of your initial DNS domain and delegate the authority for these subdomains to DNS servers located on different subnets or sites. In this way, you can create any number of separate and autonomous entities within a DNS namespace, each of which is authoritative for a portion of the overall namespace.

Example: Merging DNS Namespaces

Contoso Corporation merged with Trey Research Corporation. Before the merger, each corporation used internal domains that were subdomains of their external domains. The Contoso Corporation used a private root to simplify their DNS server administration. The Trey Research Corporation forwarded queries to the Internet, rather than using a private root.

The external namespace of the newly merged corporation contains the zones contoso.com and treyresearch.com. Each zone in the external namespace contains the DNS resource records that the companies want to expose to the Internet. The internal namespace contains the internal zones, corp.contoso.com and corp.treyresearch.com.

The Contoso division and the Trey Research division each use a different method to support name resolution for names in their namespace. The Contoso division uses the name contoso.com externally and corp.contoso.com internally. The internal root servers host the root zone. Internal servers also host the zone, corp.contoso.com. The name contoso.com is registered with an Internet name authority.

To ensure that every client within the organization can resolve every name in the newly merged organization, the private root zone contains a delegation to the zone for the top level of the merged organization's internal namespace, corp.treyresearch.com.

To resolve internal and external names, every DNS client must submit all queries to either the internal DNS servers or to a proxy server. Figure 3.4 shows this configuration.

Figure 3.4: Name Resolution in the Contoso Division

Based on this configuration, internal clients can query for names in the following ways:

• Query internal DNS servers for internal names. The internal DNS servers resolve the query. If a DNS server that receives a query does not contain the requested data in its zones or cache, it uses root hints to contact the internal root DNS servers.

• Query a proxy server for names on the Internet. The proxy server forwards the query to DNS servers on the Internet. The DNS servers on the Internet resolve the query.

• Query internal DNS servers for names in the Trey Research division. Because the root servers contain a delegation to the top level of the DNS namespace of the Trey Research division, the internal DNS servers recursively resolve the query by contacting the DNS servers in the Trey Research division.

External clients:

• Cannot query for internal names. This limitation helps secure the internal network.

• Query DNS servers on the Internet for names in the contoso.com external namespace. The DNS servers on the Internet resolve the query.

The Trey Research division uses the name treyresearch.com externally and the name corp.treyresearch.com internally. The server InternalDNS.treyresearch.com hosts the corp.treyresearch.com zone. The Trey Research division does not have a private root.

To simplify management of clients and DNS servers, Trey Research division administrators decided to use conditional forwarding. Administrators configured the DNS server InternalDNS.treyresearch.com to forward queries in the following manner:

• The server forwards all queries destined for the Contoso division to a DNS server for the Contoso division. For example, the server forwards queries destined for corp.contoso.com to InternalDNS.contoso.com.

• At the same time, the server forwards all other queries destined for contoso.com to a DNS server on the Internet.

Figure 3.5 shows this configuration.

Figure 3.5: Conditional Forwarding in the Trey Research Division