- Introduction
- Introduction to DNS
- Planning a DNS Namespace Design
- Planning DNS Zone Requirements
- Planning DNS Forwarding Requirements
- Configuring DNS Security
- Integrating with Third-Party DNS Solutions
- Introduction to WINS
- Implementing WINS Replication
- Implementing NetBIOS Name Resolution
- Troubleshooting Name Resolution Problems
- Chapter Summary
- Apply Your Knowledge
This chapter is from the book
This chapter is from the book
This chapter is from the book
Planning a DNS Namespace Design
Plan a host name resolution strategy.
- Plan a DNS namespace design.
Up to this point in our discussion about DNS, we have looked at only the historical and design aspects of DNS—and for good reason. Only by understanding how DNS was created and designed can you effectively plan and implement a DNS design in a Windows Server 2003 Active Directory domain. Because DNS permeates Windows Server 2003, you should deliberately and carefully plan your DNS namespace before you ever perform the first installation of Windows Server 2003 on a computer.
TIP
The following discussion about DNS assumes that you are already familiar with installing the DNS service and performing basic management and configuration tasks. If you need a review, see Chapter 2 of MCSA/MCSE 70-291 Training Guide: Implementing, Managing, and Maintaining a Windows Server 2003 Network Infrastructure, (2003, Que Publishing; ISBN: 0789729482) by Will Schmied and Dave Bixler.
The following list represents some questions you should ask yourself when planning your namespace needs:
Is your DNS namespace to be used for internal purposes only? If so, you can use characters that are not typically used in DNS names, such as those outside the RFC 1123 standards. An example might be bigcorp.local.
Is your DNS namespace to be used on the Internet as well? If you are currently using a corporate DNS namespace on the Internet, or think that you might at any point in the future, you should register your own domain name and conform to Internet naming standards.
Will you be implementing Active Directory? The design and implementation of Active Directory on your network play a critical role in determining how domains should be created and nested within each other.
You have the following three basic options to consider when planning the DNS namespace you will be using:
Use an existing DNS namespace—This option uses the same namespace for both the internal (corporate network) and external (Internet) portions of your network. If your domain name is bigcorp.com, you would use it for both internal and external use. Although this method is the easiest and provides simple access to both internal and external resources, it poses additional administrative requirements because an administrator must ensure that the appropriate records are being stored on the internal and external DNS servers as a security precaution.
Use a delegated DNS namespace—This option uses a delegated domain of the public namespace. If your domain name is bigcorp.com, you might consider using corp.bigcorp.com for the internal namespace. When you use this option, the corp.bigcorp.com domain becomes the root of the Active Directory forest and domain structure. Internal clients should be allowed to resolve external namespace addresses; however, external clients should not. Using a delegated DNS namespace provides a namespace that is easy to understand and remember, and that fits in nicely with the existing registered domain name. All internal domain data is isolated in the domain or domain tree, thus requiring its own DNS server for the delegated internal domain. The downside to delegated namespaces is that this adds length to the total FQDN.
Use a unique DNS namespace—This option uses a completely separate but related domain name for your internal namespace. As an example, if you are using bigcorp.com for your external namespace, you might use bigcorp.net for your internal namespace. This configuration provides the advantage of improving security by isolating the two namespaces from each other. Additionally, the administrative burden is relatively low because zone transfers do not need to be performed between the two namespaces, and the existing DNS namespace remains unchanged. In addition, this option prevents internal resources from being exposed directly to the Internet.
Consider the following example of a fictitious company that is in the planning stages of a major worldwide network reorganization and upgrade to Windows Server 2003 Active Directory. Gidget's Widgets, Inc., is a major manufacturer of household goods and already owns the gidgets.com domain name for its Internet Web site. Gidget's makes everything from bath towels to kitchen sinks. Gidget's corporate headquarters are located in the United States, with regional field offices in Canada, Mexico, England, Germany, India, Japan, and Australia. Gidget's corporate structure has the following major departments: Executive, Administrative, Engineering, Manufacturing, Facilities, Sales, Legal, and Information Services. Within each department are one or more individual divisions. How would you go about designing a DNS namespace for the Gidget's Widgets internal network?
You have several options; let's assume for the sake of argument that you are going to first create a delegated domain named corp to serve as the root of the internal network and also as the Active Directory root. Starting with the corp.gidgets.com domain, you could create fourth-level domains by country code. Within these domains, you could create fifth-level domains, as required, for each of the major departments. You might end up with a configuration that looks something like that shown in Figure 3.2.
)
Figure
3.2 Gidget's network has been nicely organized by using countries as
fourth-level domains and major departments as fifth-level domains.
If you were a network administrator in the United States working from a computer called GREENGUY42, your FQDN would be greenguy42.it.us.corp.gidgets.com. Of course, you could also design the DNS namespace using continents instead of countries, if desired. When creating DNS namespaces that are several levels deep like the example in Figure 3.2, you must keep in mind some general DNS restrictions as outlined in Table 3.1.
Table 3.1 DNS Name Restrictions
|
Restriction |
Standard DNS |
DNS in Windows Server 2003 (and Windows 2000) |
|
Characters |
Supports RFC 1123, which permits A to Z, a to z, 0 to 9, and the hyphen (-). |
Supports several different configurations: RFC 1123 standard, as well as support for RFCs 2181 and the character set specified in RFC 2044. |
|
FQDN length |
Permits 63 bytes per label and 255 bytes for an FQDN. |
Permits 63 bytes per label and 255 bytes for an FQDN. Domain controllers are limited to 155 bytes for an FQDN. |
TIP
Designing the DNS hierarchy Several of the examples presented in this chapter do not represent "best design practices" in that they have many levels of depth. This is done for illustrative purposes to help you gain a better understanding of how DNS works. In reality, you may want to consider placing resources within Organizational Units instead of fifth-level domains and below. Having too many levels in your domain architecture can lead to slower authentication, among other issues.
No matter what design you settle on, you must (in most cases) get it right the first time. Redesigning a DNS namespace is a difficult and time-consuming task after the fact, at best. In addition, failing to properly design the namespace for Active Directory compatibility can lead to functionality problems in the future.
After you've planned your namespace, you're ready to get down to business and start working out the finer points of your DNS implementation. The next thing you need to plan for is the types of zones you will be using. But what exactly is a zone?