Windows Server 2003 : Planning a Host Name Resolution Strategy - Designing a DNS Namespace

10/23/2012 2:55:47 AM
Once you have determined how your network will use DNS, it is time to begin designing the DNS namespace for your network. The namespace design can include a hostnaming pattern for all the computers on your network, as well as the more complex naming of the network’s domains and subdomains, both on the Internet and in Active Directory.

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 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 that 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.

Upgrading NetBIOS to DNS

If you are upgrading a NetBIOS network to Windows Server 2003 and Active Directory, you already have an internal NetBIOS namespace, which you can migrate to DNS, gradually or immediately. For example, if you are currently using WINS for NetBIOS name resolution, you can configure Windows Server 2003 DNS servers to resolve the NetBIOS names by sending queries to your WINS servers. You can also continue to use your existing NetBIOS names by integrating them into your DNS namespace design.

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 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 nonprofit 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 domain, and then create separate Web sites for doctors and patients, in domains called and

  • 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 to the root domain in the tree. Then, for the branch offices, you create subdomains beneath with names like and 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 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 named, 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 on the Internet.

  • Use only characters that are compliant with the Internet standard The DNS server included with Microsoft 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.

See Also

The two primary DNS standards are RFC 1034, “Domain Names - Concepts and Facilities,” and RFC 1035, “Domain Names - Implementation and Specification.” These and numerous other documents related to the development and operation of DNS are freely available at

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.


It is possible to make this arrangement work by copying all the zone data from your external DNS servers to your internal DNS servers, but the extra administrative difficulties make this a less than ideal solution.

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, you would use that domain for your external servers and create a subdomain, such as 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 an internal root is recommended when the majority of your clients do not need frequent access to resources outside your private namespace. If your clients access the Internet through a proxy server, you can configure the proxy to perform name resolutions by accessing the Internet DNS namespace instead of the private one. If your clients require access to the Internet but do not go through a proxy server, you should not create an internal root.

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. When determining your naming rules, follow these principles:

  • Create easily remembered names Users and administrators should be able to figure out the host name assigned to a particular computer by 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.

Practice: Designing a DNS Namespace

Fabrikam, Inc., is constructing a new data network and has registered the Internet domain name You are to design a DNS namespace for the network and, in the diagram shown after the following list, write the fully qualified domain name for each computer in the space provided. Base your design on the following information:

  • is the only second-level domain name you can use.

  • The internal network should be in a different domain from the external network.

  • The company consists of three internal divisions: Sales, Human Resources, and Production. Each division is to be represented by a separate subdomain in the namespace.

  • Each division has departmental servers performing various roles and as many as 200 workstations, only some of which are shown in the diagram. Your host names should identify the function of each computer.

  • Three servers on an external perimeter network host the company’s Internet services: Web, FTP, and e-mail. These servers must be in the domain

Correct answers for this practice can vary, but they should contain the following characteristics:

  • The servers in the perimeter network should have FQDNs consisting of host names in the second-level domain

  • All three internal divisions should be in a third-level domain beneath

  • Each of the three divisions should have a fourth-level domain name beneath the internal network’s third-level domain.

  • Each computer should have a unique host name that reflects its function and differentiates it from other computers performing the same function.

The following diagram contains an example of a correctly designed namespace:

Most View
Microsoft SharePoint 2010 Web Applications : Presentation Layer Overview - Ribbon (part 1)
The Cyber-athletic Revolution – E-sports’ Era (Part 1)
Windows Server 2003 : Implementing Software Restriction Policies (part 4) - Implementing Software Restriction Policies - Creating a Path Rule, Designating File Types
Sql Server 2012 : Hierarchical Data and the Relational Database - Populating the Hierarchy (part 1)
Two Is Better Than One - WD My Cloud Mirror
Programming ASP.NET 3.5 : Data Source-Based Data Binding (part 3) - List Controls
Windows 8 : Configuring networking (part 5) - Managing network settings - Understanding the dual TCP/IP stack in Windows 8, Configuring name resolution
Nikon Coolpix A – An Appealing Camera For Sharp Images (Part 2)
Canon PowerShot SX240 HS - A Powerful Perfection
LG Intuition Review - Skirts The Line Between Smartphone And Tablet (Part 2)
Popular Tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS
Top 10
Review : Acer Aspire R13
Review : Microsoft Lumia 535
Review : Olympus OM-D E-M5 Mark II
TomTom Runner + MultiSport Cardio
Timex Ironman Run Trainer 2.0
Suunto Ambit3 Peak Sapphire HR
Polar M400
Garmin Forerunner 920XT
Sharepoint 2013 : Content Model and Managed Metadata - Publishing, Un-publishing, and Republishing
Sharepoint 2013 : Content Model and Managed Metadata - Content Type Hubs