Windows Server 2003 : Designing a DNS Namespace

Using an Existing Namespace

If you are designing a new network from scratch, you are creating a new DNS namespace as well, which means that you don’t have to work existing domains and hosts into your naming strategy. If the organization for which you are designing the network already has domain names in use, whether internal or external, or has a computer naming strategy already in place, it is probably best to retain those elements and build your new DNS namespace around them.

If the organization already has an Internet presence, they probably already have at least one registered domain name and the use of a DNS server to host the domain. You can continue using the existing the domain name, even expanding it to include internal subdomains. You can also continue using the existing DNS server, or migrate the DNS services to a new server on the network you are designing. If you change the DNS server, you must inform the domain registrar, so they can alter the IP addresses of the authoritative servers in the top-level domain records. The changes can take a few days to propagate throughout the Internet, so it is a good idea to have an overlap period during which both the old and new DNS servers are operational.

If you are deploying Active Directory on your network for the first time, and you have an existing namespace of any kind, be careful to design your Active Directory hierarchy in coordination with the names you already have.

Creating Internet Domains

Designing a DNS namespace for your organization’s Internet presence is usually the easiest part of deploying DNS. Most organizations register a single second-level domain and use it to host all their Internet servers.

Registering a Domain

In most cases, the selection of a second-level domain name depends on what is available. A large portion of the most popular top-level domain, com, is already depleted, and you might find that the name you want to use is already taken. In this case, you have three alternatives: choose a different domain name, register the name in a different top-level domain, or attempt to purchase the domain name from its current owner.

If you are certain that you want to use the second-level domain name you have chosen, for example, when the name is a recognizable brand of your organization, your best bet is usually to register the name in another top-level domain. Although the org and net domains are available to anyone, these domains are associated with non-profit and network infrastructure organizations, respectively, and might not fit your business. As an alternative, a number of countries around the world with attractive top-level domain names have taken to registering second-level domains commercially.

Using Multiple Domains

Some organizations maintain multiple sites on the Internet, for various reasons. Your organization might be involved in several separate businesses that warrant individual treatment, or your company might have independent divisions with different sites. You might also want to create different sites for retail customers, wholesale customers, and providers. Whatever the reason, there are two basic ways to implement multiple sites on the Internet:

• Register a single second-level domain name and then create multiple subdomains beneath it For the price of a single domain registration, you can create as many third-level domains as you need, and you can also maintain a single brand across all your sites. For example, a company called Contoso Pharmaceuticals might register the contoso.com domain, and then create separate Web sites for doctors and patients, in domains called doctors.contoso.com and patients.contoso.com.

• Register multiple second-level domains If your organization consists of multiple completely unrelated brands or operations, this is often the best solution. You must pay a separate registration fee for each domain name you need, however, and you must maintain a separate DNS namespace for each domain. A problem might arise when you try to integrate your Internet domains with your internal network. You can select one of your second-level domains to integrate with your internal namespace, or you can leave your internal and external namespaces completely separate, as discussed later in this lesson.

Creating Internal Domains

Using DNS on an internal Windows Server 2003 network is similar to using DNS on the Internet in many ways. You can create domains and subdomains to support the organizational hierarchy of your network in any way you want. When you are designing a DNS namespace for a network that uses Active Directory, the DNS domain name hierarchy is directly related to the directory service hierarchy. For example, if your organization consists of a headquarters and a series of branch offices, you might choose to create a single Active Directory tree and assign the name adatum.com to the root domain in the tree. Then, for the branch offices, you create subdomains beneath adatum.com with names like miami.adatum.com and chicago.adatum.com. These names correspond directly to the domain hierarchy in your DNS namespace.

When selecting names for your internal domains, you should try to observe these rules:

• Keep domain names short Internal DNS namespaces tend to run to more levels than Internet ones, and using long names for individual domains can result in excessively long FQDNs.

• Avoid an excessive number of domain levels To keep FQDNs a manageable length and to keep administration costs down, limit your DNS namespace to no more than five levels from the root.

• Create a naming convention and stick to it When creating subdomains, establish a rule that enables users to deduce what the name of a domain should be. For example, you can create subdomains based on political divisions, such as department names, or geographical divisions, such as names of cities, but do not mix the two at the same domain level.

• Avoid obscure abbreviations Don’t use abbreviations for domain names unless they are immediately recognizable by users. Domains using abbreviations such as NY for New York or HR for Human Resources are acceptable, but avoid creating your own abbreviations just to keep names short.

• Avoid names that are difficult to spell Even though you might have established a domain naming rule that calls for city names, a domain called albuquerque.adatum.com will be all but impossible for most people (outside New Mexico) to spell correctly the first time.

When you are designing an internal DNS namespace for a network that connects to the Internet, consider the following rules:

• Use registered domain names Although using a domain name on an internal network that you have not registered is technically not a violation of Internet protocol, this practice can interfere with the client name resolution process on your internal network.

• Do not use top-level domain names or names of commonly known products or companies Naming your internal domains using names found on the Internet can interfere with the name resolution process on your client computers. For example, if you create an internal domain called microsoft.com, you cannot predict whether a query for a name in that domain will be directed to your DNS server or to the authoritative servers for microsoft.com on the Internet.

• Use only characters that are compliant with the Internet standard The DNS server included with Windows Server 2003 supports the use of Unicode characters in UTF-8 format, but the RFC 1123 standard, “Requirements For Internet Hosts—Applications and Support”, limits DNS names to the uppercase characters (A–Z), the lowercase characters (a–z), the numerals (0–9), and the hyphen (-). You can configure the Windows Server 2003 DNS server to disallow the use of UTF-8 characters.

Creating Subdomains

Owning a second-level domain that you have registered gives you the right to create any number of subdomains beneath that domain. The primary reason for creating subdomains is to delegate administrative authority for parts of the namespace. For example, if your organization has offices in different cities, you might want to maintain a single DNS namespace, but grant the administrators at each site autonomous control over the DNS records for their computers. The best way to do this is to create a separate subdomain for each site, locate it on a DNS server at that site, and delegate authority for the server to local network support personnel. This procedure also balances the DNS traffic load among servers at different locations, preventing a bottleneck that could affect name resolution performance.

Combining Internal and External Domains

When you are designing a DNS namespace that includes both internal and external (that is, Internet) domains, there are three possible strategies you can use, which are as follows:

• Use the same domain name internally and externally

• Create separate and unrelated internal and external domains

• Make the internal domain a subdomain of the external domain

Using the Same Domain Name

Using the same domain name for your internal and external namespaces is a practice that Microsoft strongly discourages. When you create an internal domain and an external domain with the same name, you make it possible for a computer in the internal network to have the same DNS name as a computer on the external network. This duplication wreaks havoc with the name resolution process.

Using Separate Domain Names

When you use different domain names for your internal and external networks, you eliminate the potential name resolution conflicts that come with using the same domain name for both networks. However, using this solution requires you to register (and pay for) two domain names and to maintain two separate DNS namespaces. The different domain names can also be a potential source of confusion to users who have to distinguish between internal and external resources.

Using a Subdomain

The solution that Microsoft recommends for combining internal and external networks is to register a single Internet domain name and use it for external resources, and then create a subdomain beneath that domain name and use it for your internal network. For example, if you have registered the name adatum.com, you would use that domain for your external servers and create a subdomain, such as int.adatum.com for your internal network. If you have to create additional subdomains, you can create fourth-level domains beneath int for the internal network, and additional third-level domains beneath adatum for the external network.

The advantages of this solution are that it makes it impossible to create duplicate FQDNs, and it lets you delegate authority across the internal and external domains, which simplifies the DNS administration process. In addition, you have to register and pay for only one Internet domain name.

Creating an Internal Root

When you use the Windows Server 2003 DNS server with the namespace configurations described thus far, your network’s namespace is technically part of the Internet DNS namespace, even if your private network computers are not accessible from the Internet. This is because all your DNS servers use the root of the Internet DNS as the ultimate source for information about any part of the namespace. When a client sends a name resolution request to one of your DNS servers, and the server has no information about the name, it begins the referral process by sending an iterative query to one of the root name servers on the Internet.

If you have a large enterprise network with an extensive namespace, you can create your own internal root. You do this by creating a private root zone on one of your Windows Server 2003 DNS servers. This causes the DNS servers on your network to send their iterative queries to your internal root name server, rather than to the Internet root name server. Keeping DNS traffic inside the enterprise speeds up the name resolution process.

Creating Host Names

Once you have created the domain structure for your DNS namespace, it is time to populate these domains with hosts. You should create hosts the same way you create domains, by devising a naming rule and then sticking to it. In many cases, host-naming rules are based on users, geographical locations, or the function of the computer.

For workstations, a common practice is to create host names from some variation on the user’s name, such as a first initial followed by the user’s surname. For example, the host name for Mark Lee’s computer would be Mlee. Many organizations also use similar naming rules to create user account names and e-mail addresses. Following the same pattern for DNS host names enables users to keep track of only one name. For servers, the most common practice is to create host names describing the server’s function or the department that uses it, such as Mail1 or Sales1.

Whatever naming rules you decide to use for your namespace, you should adhere to the following basic practices:

• Create easily remembered names Users and administrators should be able to figure out the host name assigned to a particular computer using your naming rules alone.

• Use unique names throughout the organization Although it is possible to create identical host names as long as they are located in different domains, this practice is strongly discouraged. You might have to move a computer and put it in a new domain that already has a host by that name, causing duplication that interferes with name resolution.

• Do not use case to distinguish names Although you can use both uppercase and lowercase characters when creating a computer name on a computer running a Windows operating system, DNS itself is not case-sensitive. Therefore, you should not create host names that are identical except for the case of the letters, nor should you create host names that rely on case to be understandable.

• Use only characters supported by all of your DNS servers As with domain names, avoid using characters that are not compliant with the DNS standard, unless all the DNS servers processing the names support these characters. The NetBIOS namespace supports a larger character set than DNS does. When you are upgrading a Windows network that uses NetBIOS names to one that uses DNS names, you might want to use the Unicode (UTF-8) character support in the Windows Server 2003 DNS server to avoid having to rename all your computers. However, you must not do this on computers that are visible from the Internet; these systems must use only the character set specified in RFC 1123.