TechNet Home > Windows Server System Reference Architecture > Network Services > Blueprint

Enterprise Design for DNS

Published: March 31, 2005

In an IP-based network, computers and other devices are referred to either by name or by IP address. From a user’s perspective, it is easier if these resources are referred to using simple permanent names rather than the numerical IP addresses that may change over time. A name resolution service provides the mapping between such names and addresses.

This section describes the most common name resolution service, DNS. DNS design consists of the following steps:

1.	Service design: In a majority of cases, DNS is chosen as the most appropriate name resolution solution.
2.	Logical design: The most appropriate logical DNS configuration is defined in this step.
3.	Physical design: The logical design is mapped onto physical hardware and software configurations.

During each of these steps, the DNS design needs to meet specific service-level design goals such as availability, security, and scalability.

The following section provides a description of the DNS service and explains the options for each step and each design goal together with the advantages and disadvantages of each option.

Service Definition

DNS is a hierarchical distributed database used for locating domain names on the Internet and private TCP/IP networks. DNS refers both to the hierarchical namespace and to the Internet service used to resolve domain names to IP addresses. Hence, DNS provides a service for mapping DNS domain names to IP addresses and vice versa. This service allows users, computers, and applications that query DNS to specify remote systems by fully qualified domain names (FQDNs) rather than by IP addresses. Clients and servers use DNS for several purposes including:

•	Locating authentication services.
•	Locating file and print services.
•	Performing lookups for external computer names.

In an enterprise organization, clients and servers also use DNS for:

•	Locating domain controllers or other authentication services.
•	Locating services for replication purposes.
•	Locating catalog or directory servers for performing searches.
•	Locating file and print services.
•	Performing lookups for external computer names.

Several additional services can be used to increase the functionality of DNS. These include:

•	Dynamic DHCP: To perform automatic name registration for clients.
•	DNS dynamic updates: To enable clients to update their own host records automatically.
•	WINS: To provide interoperability so that NetBIOS name resolution services work together with DNS.
•	Active Directory integration: To use Active Directory replication for DNS replication and Active Directory security services for securing the DNS database.

Assigning DNS Names

All nodes on a network that need to be resolved to an IP address must be assigned a DNS name that includes the top-level Internet DNS domain name of the organization or part of the organization. Because DNS is hierarchical, DNS domain names increase in length when subdomains are added to the organization. If possible, you should use short domain names; doing so makes fully qualified computer names easier to remember and facilitates 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 or second-level Internet DNS domain to register your own Internet DNS domain name. For example, you can register your domain as a subdomain of a top-level domain such as .com, .org, or .net, or as a subdomain of the domain name that is assigned to your country or region, such as .au (Australia), .fr (France) or .ca (Canada). Some country registrars, such as the .uk domain, do not allow subdomains to be registered at the top level; instead you are allowed to register the subdomain at the second level, such as .co.uk. When you register your DNS domain name, the Internet registrar creates a delegation in the DNS zone that is authoritative for the high-level domain you selected (for example, the .com domain in the case of .com names). Contact information is also registered in the global WHOIS database.

Once the domain name has been registered with an Internet registrar, at least two authoritative DNS servers must be assigned to host the DNS zone for the domain. These root DNS servers might be located on your network or on your Internet service provider’s (ISP’s) network. This design choice is discussed in more detail later in this blueprint.

Namespace Planning

DNS namespaces should be planned in a flexible, yet logically hierarchical fashion, which will allow a DNS administrator to add new zones to the namespace environment without negatively affecting the existing namespace services. The design must be able to meet the security and naming requirements of all relevant clients and business units in the enterprise.

When starting a DNS namespace design, a good practice is to draw a graphical representation of the base namespace and then define any other zones beneath the root zone to accommodate their varying security and view requirements. This initial view should represent namespace services strictly from a logical perspective; any concerns about actual physical equipment and flow of data should be secondary. The focus here is to ensure that the logic behind the design fulfills the requirements for providing stable, redundant, and secure domain name services to clients in the networking environment. As DNS administrators begin to work out the details of this diagram, they will most likely find that various segments of the drawing need to be modified, moved, or deleted for various reasons. The initial design of a workable DNS namespace plan is often the most difficult part of establishing a DNS environment.

Naming Design Guidelines

Once you have decided on a namespace design, it is necessary to determine DNS names for the internal domains and computer names.

Internal Subdomain Naming Guidelines

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

•	When using acronyms or abbreviations for domain names, ensure that the business units that these acronyms represent are easy for users to recognize (unless the subdomains are for administrative and technical use only).
•	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 or remember.
•	Avoid extending your DNS domain name hierarchy more than five levels from the internal or Internet root domain. Limiting the extent of the domain name hierarchy reduces administrative costs.

Computer Naming Design Guidelines

Use the following guidelines when creating names for computers:

•	Select computer names that are easy for users to remember.
•	Identify the owner 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.
•	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 Request For Comments (RFC) 1123 titled "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.
•	Do not use the character case to convey the owner or purpose of a computer, because DNS is not case-sensitive.

The following table lists the different character sets that are supported by standard DNS, Windows Server 2003 DNS, and NetBIOS.

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" to "Z", "a" to "z", "0" to "9", and the hyphen “-“.	Supports RFC 1123 and UTF-8. You can configure the Windows 2000 or Windows Server 2003 DNS server to allow or disallow the use of UTF-8 characters, and do so on a per server basis.	Not allowed: Unicode characters, numbers, white space, symbols: / \ [ ] : \| < > + = ; , ? and *)
Maximum host name and FQDN length.	63 bytes for each name and 255 bytes for the complete 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 byte in length. Domain controllers are limited to 155 bytes for an FQDN.	15 bytes in length.

Table 1. Character Set Restrictions

For information on integrating DNS with WINS, refer to the "DNS Interoperability" section in this blueprint.

Top of page

Service Design

The decision to use a specific IP name service such as DNS is one step in the network architecture design process for the enterprise. Generally, DNS will be the most appropriate option for most organizations; however it is not the only one. Therefore, the first step is to decide which name service is the most appropriate.

For more information on design of the network architecture and the decision steps it follows, refer to the Network Architecture Blueprint.

Design Inputs

As the requirement for IP address management is established, a number of additional factors that influence its design should be taken into account. To determine an appropriate configuration for a given situation, the following questions should be asked:

•	What are the availability and scalability criteria that must be met by the network infrastructure?
•	How extensive is the environment in terms of the number of IP addresses and resource names to be assigned and managed?
•	What management resources are available to administer the selected options?
•	What infrastructure is in place for the management of the IT architecture? For example, is it centralized or distributed?
•	What are the security criteria that need to be taken into account as part of the definition of a name service?

With this information, it is possible to define an appropriate set of options for IP address management.

Design Options for Name Service Technology

Internet name resolution can be provided in one of the following ways:

•

Static HOSTS files

•

DNS

Note: As mentioned, it is likely that DNS will be the most appropriate technology for name resolution. However, there are a number of situations in which use of HOSTS files will be more appropriate.

These name resolution options are described in the following sections.

Option 1—Static HOSTS Files

The simplest method of managing IP device names is through the use of HOSTS files. A HOSTS file is a simple text file installed on every client that contains name-to-address mappings. HOSTS files were the first name resolution technology used on the Internet and in the early days of TCP/IP networking; a single HOSTS file was maintained centrally and was downloaded to each client, either manually or automatically, through technologies such as Network Information Service (Yellow Pages) on UNIX.

Advantages

The advantages of using static HOSTS files include:

•	Simplicity: This method of name resolution is by far the simplest to understand and troubleshoot.
•	Highly controlled: The use of HOSTS files can have a role in the secure resolution of small numbers of critical servers in a tightly controlled environment. In such situations, requirements for security and simple management can outweigh the management overhead of maintaining HOSTS files.
•	Platform support: The HOSTS files option is available on all network operating systems; therefore the same management procedures can be employed across a range of platforms.
•	No service dependencies: Name resolution is carried out independently of other computers in the network because the HOSTS file is stored locally. This means that the only circumstance in which the name resolution system can fail is when the HOSTS file gets corrupted; it cannot fail due to problems with other systems.

Disadvantages

The disadvantages of using static HOSTS files include:

•	Administrative overhead: This approach is inappropriate in a modern business environment. On all but the smallest networks, the administrative overhead of supporting HOSTS files is excessive because they must be administered on every computer.
•	No Active Directory support: Name resolution through HOSTS files cannot support Active Directory services because a HOSTS file can only contain simple Alias records and not the specific types of records that Active Directory requires.
•	File integrity: The integrity of the HOSTS file can be compromised; users can modify the file. The HOSTS file is a simple text file that can easily be edited by a user who has proper access rights or is on a client computer where access rights are not enforced. Such modifications to the HOSTS file, accidental or deliberate, could lead to name resolution failures. File system security can be used to protect the HOSTS files under operating systems such as Windows XP and Windows Server 2003, but such security measures might negatively affect HOSTS file management and maintenance procedures (for example, by making it difficult to disseminate updates).

Option 2—DNS Service

DNS replaces the HOSTS file with a distributed database that implements the DNS hierarchical naming system. In a DNS system, host records are held in a zone file. Zones correspond to administrative boundaries within the DNS namespace, and for each zone there is at least one DNS server that holds a copy of the zone file. For example, if the domain wingtiptoys.com has a subdomain corp.wingtiptoys.com, the complete namespace can be hosted on a single DNS server with a single zone file containing all the records. Alternatively, wingtiptoys.com and corp.wingtiptoys.com can be hosted in separate zones, so that different administrators can be responsible for each zone, different settings can be applied to each, and zone files can be hosted on different servers.

Advantages

The advantages of using the DNS service include:

•	Scalability: DNS allows for the number of named hosts to increase, an important requirement both within the enterprise and on the Internet. It also ensures that names are unique throughout the Internet and private TCP/IP-based intranets.
•	Centralized administration: With a DNS system, it is no longer required for each client to maintain its own name-to-IP address mappings. Centralized administration can now create and edit the database, thereby reducing administrative overhead and the potential for configuration errors.
•	Availability: DNS servers can make use of replication to place copies of the database across the enterprise for performance and fault tolerance reasons.
•	NetBIOS name support: DNS can provide name resolution for NetBIOS names in addition to FQDNs, which is achieved by using specific NetBIOS record types in the DNS database or through forwarding requests to a NetBIOS name resolution server, such as a Windows Internet Name Server (WINS) server. Support for these features depends on the type and version of DNS server being used, and is described in greater detail later in this blueprint.

Disadvantages

The disadvantages of using the DNS service include:

•	Security: DNS zone files can be easily corrupted by inexperienced administrators using text-based administration tools. Also, it may be difficult to protect zone files from malicious or accidental damage. Mechanisms to protect DNS data are discussed later in this blueprint.
•	Latency: File-based zone files can only be updated on the DNS server that holds the primary copy, which means that in a large network there may be considerable latency before updates appear on the servers holding the secondary copies. Local administrators in one part of the enterprise cannot quickly update DNS records for their part of the network if the primary copy is held in another part of the network. However, the use of subdomains can help overcome this problem. Designing DNS to minimize latency is discussed later in this blueprint.
•	Availability: Because standard DNS replication is single-master, a primary DNS server in a standard primary DNS zone can be a single point of failure.
•	No support for NetBIOS extended information: DNS zones do not contain extended information to support NetBIOS name types, such as NetBIOS groups. For this reason, DNS cannot completely replace a NetBIOS name resolution system such as WINS.

Recommendation for Best Practice

For most enterprise environments, Internet name resolution should be provided through DNS, which provides centralized management and control. The use of HOSTS files can be justified in specific situations, such as when resolution of critical network names on key servers or workstations must be ensured even if the DNS service is unavailable.

Top of page

Logical Design

Implementing an effective DNS service requires decisions on the following issues:

•	Design of the namespace.
•	Location of the DNS host.

Once these issues have been addressed more detailed planning can be done, particularly in the case of more complex namespaces such as those required for an enterprise. Additional design choices include:

•	How to host internal and external namespaces?
•	Which DNS technology to implement?
•	How to design DNS zones?
•	How to determine the appropriate number of DNS servers for the enterprise?
•	How to optimize DNS queries for clients, including the forwarding of name resolution queries to other name servers?
•	How to configure DNS to interoperate with other name resolution systems such as WINS and with other technologies such as DHCP?

Design Options for Namespace Design

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.

•	If you are upgrading to Windows Server 2003 DNS from an earlier version of Windows, you might need to replace or support an existing name resolution system (such as WINS) with your Windows Server 2003 DNS infrastructure. You can support an existing WINS deployment by configuring Windows Server 2003 DNS servers to query WINS servers; this configuration uses the properties of the DNS zone.
•	If you are migrating or integrating Windows Server 2003 DNS with a non-Microsoft DNS infrastructure, you do not need to change the namespace design used in your third-party DNS infrastructure.
•	If you are deploying a new Windows Server 2003 DNS infrastructure, you must create a DNS domain and computer naming strategy and plan for how these names will resolve within your network and over the Internet.
•	If you are deploying Windows Server 2003 DNS to support Active Directory, you must plan your DNS namespace in conjunction with planning your Active Directory logical structure.

The following table below summarizes the DNS namespace design requirements for each possible scenario.

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. However, to support Active Directory there are additional zones, such as the _msdcs zones, which must be considered.
You are upgrading from a non-Microsoft DNS infrastructure that uses DNS software which follows the standard DNS domain naming guidelines.	DNS namespace design can remain the same. However, to support Active Directory there are additional zones, such as the _msdcs zones, which must be considered.
Your existing DNS software does not conform to the standard DNS domain naming guidelines.	Make your existing DNS namespace design compliant with DNS domain naming guidelines before deploying a Windows Server 2003 DNS 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 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 of management techniques.

Table 2. DNS Namespace Design Requirements

When considering namespaces, two key decisions are:

•	The number of namespaces required.
•	The root domain name or names to use.

The following options describe how an enterprise can choose to design its namespace. Later sections in the blueprint consider the additional issues of whether to create a subdomain structure and how to name computers and servers.

The cases presented here assume a single public domain name, but the same options work even if the enterprise includes multiple business units with their own domain names. However, the design will become more complex to deploy if there are multiple public or internal namespaces. In particular, it becomes important to plan how to ensure that DNS queries are correctly handled across the domains. For more details, refer to the “Design Options for Optimizing DNS Queries—Server Configuration” section in this blueprint.

Option 1—Single Namespace for the Enterprise

In this design option there is only one namespace, for example wingtiptoys.com. In this namespace, an externally accessible Web server may have the DNS name www.wingtiptoys.com and an internal server may have the DNS name server1.wingtiptoys.com, with both these records defined in the same DNS zone. More details on the design options for DNS zones are provided later in this blueprint. This design is common in smaller organizations where there is limited internal TCP/IP networking and therefore minimal internal DNS requirements. It may also be found in organizations with no current public Internet presence.

Advantages

The advantages of a single namespace for the enterprise include:

•	Single Internet domain name: You only need to register a single name with an Internet name authority.
•	Simplicity: There is only one DNS namespace and all host records are defined in the same zone.
•	Low administrative overhead: Because all records are in the same zone, this design is easy to manage.

Disadvantages

The disadvantages of a single namespace for the enterprise include:

•

Enterprise DNS is hosted in one place: Because there is a single zone, the DNS must be hosted in one location, either within the enterprise or externally (such as on an ISP’s server). There is no need to split the DNS to provide the most appropriate hosting for internal and external requirements.

•

Security: This design suffers from inherent security weaknesses. For example, if the DNS is hosted internally, then external DNS traffic must be allowed into the organization's network so that external clients can resolve enterprise names, such as for public Web servers. Similarly if the DNS is hosted externally, private DNS records must be allowed to pass over public networks in order to be hosted on the external DNS servers.

Option 2—Internal Domain as a Subdomain of External Domain

In this design option there are in effect two namespaces, with all internal domains being subdomains of the publicly resolvable external domain name. For example, an organization that has an external namespace domain name of wingtiptoys.com may use corp.wingtiptoys.com as the internal namespace domain name.

You can use your internal subdomain as a parent for the additional child domains that you create to manage divisions within your company. Child domains have DNS names that are immediate subordinates 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.wingtiptoys.com namespace may have the domain name hr.us.corp.contoso.com.

If this configuration is used, computers in the external domain that are accessible from the Internet must be deployed outside the firewall. The computers that you do not want to be accessible from the Internet are deployed within the internal subdomain, behind the firewall.

Advantages

The advantages of having the internal domain as a subdomain of the external domain include:

•	Single Internet domain name: You only need to register a single name with an Internet name authority.
•	Distributed administration: This design simplifies administration by enabling you to distribute administrative responsibilities across internal and external domains.
•	Hosting flexibility: As the namespace is split, it is possible to host the external parent domain and the internal subdomains on different DNS servers. For example, the parent domain wingtiptoys.com (which can include host records for public resources such as Web servers) can be hosted externally by an ISP, and the internal subdomain corp.wingtiptoys.com can be hosted on internal DNS servers.

Disadvantages

The disadvantages of having the internal domain as a subdomain of the external domain include:

•	Long internal names: Internal names are longer than external names because they include the subdomain prefix.
•	Security: Although this design allows the public part of the DNS to be hosted on external DNS servers and internal records to be hosted on internal DNS servers, there must be communication between these two sets of hosts. Therefore, potentially sensitive DNS information will have to be transmitted over public networks.

Option 3—Unrelated Names for Internal and External Domains

This configuration involves two namespaces. The domain names used for internal and external resources are completely different. For example, an organization uses the domain name wingtiptoys.com for their external namespace but uses the name wingtiptoys.local for their internal namespace. This example uses “.local” as a non-publicly resolvable suffix; such domains are known as internal stand-alone domains. As an alternative to using a non-publicly resolvable suffix, the internal domain could use a variant of the public domain with a slight change to the names, such as adding “-corp” to the domain name as in domain-corp.com.

Advantages

The advantages of using unrelated names for internal and external domains include:

•	Security: This design uses a unique internal domain name that is not resolvable from any external clients. The internal name need not be registered with the Internet registry; therefore, any name can be used although it is advisable to register the name. As the internal name is not used within any externally reachable DNS, there is no risk of external systems being able to resolve the IP addresses of your internal systems. If a suffix is used that is not publicly resolvable, names can never be resolved by public DNS servers, thereby adding a layer of protection.
•	Distributed administration: This design enables you to distribute administrative responsibilities across internal and external domains easily, which are completely separate and can be appropriately managed.
•	Hosting flexibility: Because the internal and external domain namespaces are separate, it is possible and advisable to host them on different DNS servers.

Disadvantages

The disadvantages of using unrelated names for the internal and external domains include:

•	Management overheads: This design requires additional administrative work because two separate namespaces must be managed to provide full internal and external name resolution for internal clients in an efficient manner.
•	Potential user confusion: 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 your network.
•	Potential internal-external communication problems: If there are design needs that require transparent crossover between a company’s private and public namespaces, use of a non-resolvable name may cause problems or at least additional planning requirements.
•	Requires additional Internet registrations: If you want to provide for design changes that require the internal domain to be used externally, you must register two DNS names with the Internet name authority.

Option 4—Same Name for Internal and External Domains

In this configuration, the internal private namespace and the external public namespace share the same domain name. However, they are still completely separate and distinct namespaces.

You can use one of the following methods to enable the use of the same domain name for your internal and external DNS namespace:

•	If your clients can pass queries to external servers, such as Web servers, through a firewall, copy the zone data from your external DNS server to your internal DNS server.
•	If your clients cannot pass queries through a firewall, duplicate all public DNS zone data and all public servers, such as Web servers, that belong to your organization onto your internal network.
•	Maintain a list of public servers that belong to your organization in the Proxy Auto-Configuration (PAC) file on each of your DNS clients.

The method that you choose depends on your client software proxy capabilities. The following table lists the possible methods for enabling the use of the same domain name for internal and external namespaces, and the client software proxy capabilities that are possible for each.

Method	Proxy Capability	Local Address Table (LAT)	Name Exclusion List	Proxy Auto-Configuration (PAC) File
Copy the zone data from your external to your internal DNS server.	Yes	Yes	Yes	Yes
Duplicate all public DNS zone data and all public servers onto your internal network.	Yes	Yes	Yes	Yes
Maintain the list of public servers in the PAC files on the DNS clients.	No	No	No	Yes

Table 3. Using the Same Name for Internal and External Namespaces and Compatible Proxy Capabilities

Advantages

The advantages of using the same name for the internal and external domains include:

•	Single Internet registration: In this design there is no need to register more than one domain name with an Internet name authority. There is also no need to manage subdomains, although internally the use of subdomains may be beneficial for other reasons that are discussed later in this section.
•	Distributed administration: This design enables you to distribute administrative responsibilities across internal and external domains easily, and although they share the same name the domains are completely separate and can be managed as appropriate.

Disadvantages

The disadvantages of using the same name for the internal and external domains include:

•	Potentially non-unique names: This configuration can cause name resolution problems because it introduces a potential for DNS names that are not unique. When you use this configuration, a computer in your internal namespace can have the same name as a computer in the Internet namespace. Any attempt to resolve that name can result in errors, increasing the administrative overhead because you need to anticipate all possible name duplications.
•	Hosting requirements: Because the namespace is separate but the domain names are the same, the external and internal domains must be hosted on different DNS servers.
•	Administrative overhead: Administrative procedures must be put in place to ensure that host records are not hosted on the wrong domain; for example, an internal record inadvertently created on an external domain DNS server.
•	Name resolution: Careful planning must be done to ensure that internal clients can resolve public organizational Web servers by name even though the public and internal root namespaces are the same.

Additional Option—Use of Subdomains

Subdomains can be used in any of the four design options, and are fundamental to the option where the internal domain is a subdomain of the external domain (Option 2). The term subdomains refers to child namespaces set up within zones. For example, a subdomain of the corp.wingtiptoys.com namespace might have the domain name us.corp.wingtiptoys.com. This subdomain can contain additional subdomains, such as hr.us.corp.wingtiptoys.com. Subdomains are a level at which many critical DNS decisions are handled. When looking at different subdomain schemas consider the following:

•

Will any business unit in an organization have special name resolution needs? If WINS forwarding is not enabled as a general policy in a DNS environment, it may need to be enabled for business units made up of predominantly non-Windows computers. Such business units may need to be put into a separate subdomain to grant the computers in that subdomain full namespace services through DNS without compromising the overall organizational policy of keeping WINS namespace services separate from DNS.

•

What standards should be used when determining the depth and breadth of a DNS schema? Is it better to have a large number of subdomains immediately beneath the root domain (child domains) or to create only a handful of child domains and a larger number of grandchild domains (domains beneath child domains)? The answer to these questions will be largely driven by an organization’s physical network, Active Directory, and public versus internal DNS namespace needs. Many enterprises create their general DNS namespace at the child level and add grandchild domains as required. This keeps the root domain free from having to handle daily DNS activities and provides flexibility in handling future DNS design needs.

Advantages

The advantages of using subdomains include:

•	Distribution of network administration: Subdomains enable the distribution and management of network resources across administrative groups or departments. You can deploy DNS subdomains that reflect the existing administrative departments in your company by creating a different subdomain for each network segment.
•	Load balancing: You can increase the efficiency and the performance of your DNS namespace by distributing the network load across several subdomains on different DNS servers.

Disadvantages

The disadvantages of using subdomains include:

•	Administrative overhead: Splitting your namespace into subdomains requires additional administrative overhead, because there will be more than one administrative zone to manage.
•	Longer FQDN: The namespace will be comprised of longer names, than in the case of a single domain. For example, a server may be named hr-server1.hr.corp.wingtiptoys.com, rather than server1.wingtiptoys.com if there was only a top-level domain.

Recommendation for Best Practice

Consider the following guidelines when using subdomains:

•	Use an internal domain as subdomain of the external domain, if possible; this is simplest to deploy and administer.
•	Use unrelated internal and external domains only if it is not possible to configure your internal domain as a subdomain of your external domain.
•	Avoid internal and external domains sharing the same name.

Design Options for DNS Hosting

The DNS root is the topmost level of the DNS that is within your control and ownership. For example, if your domain is wingtiptoys.com the “wingtiptoys” domain root is within your control; whereas the “com” domain root is currently managed and controlled by the domain name registrar, Verisign Global Registry Services.

The following design options are applicable whether your organization has a single domain or multiple top-level domains. Multiple top-level domains are required in cases where the enterprise is made up of business units with their own domain names or where businesses acquired through acquisitions and mergers need to be supported within the enterprise DNS.

Option 1—External Root

An external root is where an external system (such as that run by an ISP or third-party DNS host) is responsible for hosting your DNS, which may include your top-level domain and your internal DNS depending on your namespace design. (ISPs usually provide DNS as part of their services.)

Advantages

The advantages of using an external root include:

•

Less administration: Using the services of an external root can simplify administration, because there is one less service your administrators need to manage. ISPs will typically run parallel systems for performance and fault tolerance, and you do not need to provide backup systems to ensure reliable operation. It may be possible to negotiate a Service Level Agreement (SLA) to provide for guaranteed levels of DNS uptime.

•

Simple client configuration: External clients will be able to resolve the names of your public servers, as the ISP’s DNS is accessible from any part of the Internet. Your internal clients can be configured to point to the ISP’s DNS for both internal and external name resolution.

Disadvantages

The disadvantages of using an external root include:

•	Security: In this design, your DNS information is hosted with your ISP and you have little control over your own namespace.
•	Potential for incompatibility: If you use an ISP to host your DNS data, you must assure yourself that the DNS infrastructure of the ISP can support your DNS deployment by confirming that the DNS server software of the ISP is compatible with your name service requirements. For example, if you need your ISP to support specific Windows Server 2003 DNS features, you will only be able to use an external root if the version of DNS that your ISP uses supports the particular features that you need. For more details on interoperability, refer to the "DNS Interoperability" section in this blueprint.
•	Performance: Performance issues may arise if all your internal clients need to use an external host to resolve enterprise names, particularly if the external host is not connected to your network by highly available and fast connections. However, the use of internal DNS servers hosting read-only secondary zones that are updated from the external host can help alleviate this issue. Details on secondary zones are provided later in this blueprint.
•	Update limitations: This design is not suitable for any organization where DNS records need to be regularly added, amended, or deleted because the DNS is not under the direct control of your administrators. Also, there may be delays before records are changed as requests for changes are queued by the ISP.
•	No support for dynamic updates: The ISP’s DNS may not support DNS dynamic record updates. Even if it does, however, the issue of internal clients needing to regularly access the external DNS server causing high levels of network traffic would still exist.

Option 2—Internal Root

If you use an internal DNS root, a private DNS root zone is hosted on a DNS server on your internal network. Just as the Internet root zone contains delegations to all 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 is authoritative for all of the names in the internal DNS namespace. Internal clients can query the internal DNS for all private names and can be configured to query a different set of DNS servers for external name resolution. More details on this area of DNS design are provided later in this blueprint.

Advantages

The advantages of using an internal root include:

•	Full control of internal DNS: Hosting your own DNS data gives you complete control of network resource allocation and security. If your organization hosts all of your DNS data, you do not need to consider the DNS infrastructure of your ISP. Note that even if you are hosting your DNS data without the help of your ISP, you might decide to enable your DNS clients and servers to use the DNS servers of your ISP to perform name resolution for external hosts. (You would not need to inform your ISP of this configuration.)
•	Security: If required, all or part of your internal DNS root zone can be made private to protect internal domain names from exposure to the Internet. More details on this option are provided later in this blueprint.
•	Scalability: A large network with an internal DNS namespace that is hosted on multiple DNS servers is easily scalable. If your network spans multiple locations, an internal DNS root is the best method for administering all of the DNS activity on the distributed network.
•	Efficient name resolution: With an internal DNS root, DNS clients and servers on your network do not contact the Internet to resolve internal names. Therefore, 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.

Disadvantages

The disadvantages of using an internal root include:

•	Risk of failure: If name resolution is supported entirely by your own servers and infrastructure, it may be at risk if you do not use a highly available solution.
•	Requirement for administration: Hosting your own DNS requires your administrators to be responsible for DNS administration.

Recommendation for Best Practice

Use internal DNS roots isolated from public networks if you have a large distributed network and a complex DNS namespace. Using internal DNS roots 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. You should also consider enabling your DNS clients and servers to use DNS servers of an ISP to perform name resolution for external hosts. This configuration can improve bandwidth utilization across your network. More details on this type of design are provided in the next section.

Design Options for Hosting Internal and External Namespaces

This set of options and all the remaining design options are applicable if your organization hosts its own DNS and has one or more of the following:

•	Multiple top-level domains: This is a DNS infrastructure that includes two or more top-level DNS domain names within the same enterprise, for example wingtiptoys.com and tailspintoys.com.
•	Internal domains that are subdomains of your public external namespace: For example, corp.wingtiptoys.com is an internal domain and wingtiptoys.com is the external namespace.
•	Internal domains that have a completely separate namespace from the external domain: For example, wingtiptoys.local for the internal namespace and wingtiptoys.com for the external namespace.

The key decision involves which clients will benefit from the services of this DNS implementation. For example, will the DNS provide enterprise name resolution services for all clients both internal and external, or will it provide services only to one or the other? If a DNS server is restricted to providing DNS services for only a part of the internal or external network, careful attention will need to be focused on the interfaces on the server that need to be enabled for DNS. For example, in the case of a DNS server put in place only to handle the resolving of public Internet names on behalf of internal clients (not advertising), there is no need to enable DNS on the network interface facing the Internet.

The next decision is about how to divide the services between internal and external clients:

•	Complete DNS
•	Split DNS
•	Split-split DNS

Option 1—Complete DNS

The same DNS server can provide services for internal and external clients. Because this DNS server hosts zones for internal private records as well as external public records, it must be accessible from both internal and external networks to be able to provide name resolution for both internal and external clients.

Advantages

The advantages of complete DNS include:

•	Simple deployment: This design is easy to configure and manage. It is always clear which DNS servers are providing what service because there is no complex split between different aspects of the DNS.
•	All internal clients use the same DNS servers: There is no need to separately configure different workstations and servers because they all use the same DNS servers.

Disadvantages

There are inherent security problems in allowing the same DNS to support both external and internal name resolution. There are no security boundaries within DNS to prevent external access to internal DNS records.

Option 2—Split DNS

Split DNS architecture consists of external-facing DNS servers that provide name resolution for external Internet clients and internal DNS root servers that provide name resolution for internal clients. The internal DNS services may be behind the enterprise firewall, and can be configured to forward all DNS queries to the external DNS servers for resolution. Alternatively, internal clients can be configured to query different DNS servers, depending on whether the request is for an internal or an external name. To be able to do this, clients must have proxy capabilities. The table below lists the types of client proxy capabilities and whether clients can be configured to query an internal DNS root for internal names.

Proxy Capability	Microsoft Software With Corresponding Proxy Capabilities	Forwards Queries	Can Clients Be Configured to Query Internal Root for Internal Names?
No Proxy	Generic Telnet	Yes	No
Local Address Table (LAT)	Winsock Proxy (WSP) 1.x and later. Internet Security and Acceleration (ISA) Server 2000 and later.	Yes	No
Name Exclusion List	WSP 1.x and later. Internet Security and Acceleration (ISA) Server 2000 and later. All versions of Microsoft Internet Explorer.	Yes	Yes
Proxy Auto-Configuration (PAC) File	WSP 2.x. Internet Security and Acceleration (ISA) Server 2000 and later. Internet Explorer 3.01 and later.	Yes	Yes

Table 4. Client Proxy Capabilities

Advantage

Zone transfers are not allowed between the internal and external DNS servers. This configuration allows internal DNS namespace information to remain isolated and unavailable to the Internet. Zone transfers are also not allowed between the external DNS servers and any DNS server on the Internet.

Disadvantage

The disadvantage of split DNS is that resolving external names requires computers that support either software proxy or Proxy Local Address Tables (LATs); alternatively, you must configure one or more internal DNS servers to forward queries that cannot be resolved locally to the Internet.

Option 3—Split-Split DNS

This design is similar to the split DNS design in that external DNS servers provide name resolution for public Internet clients, but in this case the external DNS servers are either advertisers or resolvers; they do not act (as is usual) in both roles. As with the split DNS design, there is also a separate set of DNS servers for internal clients.

Advantages

The advantages of split-split DNS include:

•

Extra security: The split-split DNS design provides additional security. Split-split DNS takes a split-DNS design one step further by separating the Advertiser and Resolver services in the external DNS. Advertiser services in DNS handle queries from clients on the Internet for zones for which the DNS server is authoritative. By limiting queries to local zones and disabling recursion, these services are protected from attacks. Resolver services in DNS handle queries forwarded from internal DNS servers and resolve the requests on behalf of the internal servers by querying external DNS servers.

•

Protection from DNS attacks: Resolver servers do not listen for queries from the Internet. They only listen for requests from the internal DNS servers. Therefore, they are protected from attacks originating on the Internet. Cache poisoning is one such attack that a split-split DNS design guards against. DNS poisoning involves providing bogus data to a DNS server in order to misdirect users. Cache poisoning works by sending a DNS query to a DNS server on the Internet for a zone that the DNS server is not authoritative for. If recursion is enabled on the DNS server, it will attempt to resolve the request for the client by finding the authoritative DNS server for the zone and then forwarding a request to it. If this authoritative DNS server is owned by a malicious individual or organization, it may respond with a valid answer, but also send an attack at the end of the answer that could potentially alter the DNS servers’ cache. In a split-split DNS design, all servers listening on the Internet have recursion disabled, so this type of attack is prevented.

Disadvantages

The disadvantages of split-split DNS include:

•	Administrative overhead: This type of design requires more careful planning and implementation than either a complete DNS or split DNS. Incorrect configuration may allow DNS attacks to get through or simply prevent name resolution from working.
•	Resource requirements: This design requires more hardware, as separate Advertiser and Resolver DNS servers are deployed in addition to the separate internal DNS root servers.

Recommendation for Best Practice

If possible, avoid the complete DNS design because this allows DNS traffic to pass between internal and external DNS servers. For security reasons a split DNS design is a better choice in most situations because it reduces the risk of external attack on the internal namespace. For large organizations, the security benefits of a split-split DNS design may often outweigh the additional resource requirements.

Design Options for DNS Technology

As DNS technology has evolved, new features have been added that are appropriate for some enterprises and inappropriate for others. The following options categorize DNS technology into four levels; it is important to choose the correct DNS for your enterprise requirements. If your DNS deployment involves DNS implementations from different vendors or uses different service versions, interoperability issues may need to be addressed. For more details on these issues, refer to the "DNS Interoperability" section in this blueprint.

Option 1—Standard DNS

Standard DNS as specified in RFC 1035 is supported by the Windows Server 2003 DNS service as well as previous versions of Windows and other platforms. For more details, refer to the "DNS Interoperability" section in this blueprint.

Advantages

The file-based zone replication method of standard DNS provides interoperability as it allows Windows 2000 and Windows Server 2003 DNS servers to replicate with other DNS servers such as Windows NT 4.0 and Berkeley Internet Name Daemon (BIND). It also allows Windows Server 2003 DNS servers to replicate with stand-alone servers running any DNS.

Disadvantages

The disadvantages of standard DNS include:

•	Update latency: File-based zone files used by standard DNS can only be updated on the DNS server that holds the primary copy. This means that in a large network there may be considerable latency before updates appear on the servers holding the secondary copies. Also, local administrators in one part of the enterprise cannot quickly update DNS records for their part of the network if the primary copy is held in another part of the network. However, the use of subdomains can help overcome this problem.
•	Single point of failure: Because DNS replication is single-master, a primary DNS server in a standard primary DNS zone can be a single point of failure.
•	Manual record creation and maintenance: The use of standard DNS requires network administrators to initially create each DNS host’s record and later edit these records as names and IP addresses change. Standard DNS does not provide automatic registration of host names for hosts that have IP addresses assigned by DHCP.
•	No Active Directory support: Standard DNS lacks support for the specific record types used by Active Directory and associated services.
•	Security: The DNS database must be protected from unauthorized access. If DNS records are changed or corrupted, access to network resources may be severely affected.

Option 2—Dynamic DNS

The DNS dynamic update protocol provides automatic registration of host names into the DNS database. The dynamic update mechanism enables DNS client computers to register and dynamically update their resource records with a DNS server whenever changes occur. This reduces the need for manual administration of zone records, especially for clients that frequently move or change locations or use DHCP to obtain an IP address.

The Windows Server 2003 DNS Server service allows dynamic updates to be enabled or disabled on a per-zone basis at each server configured to load either a standard primary or directory-integrated zone. By default, the DNS Client service dynamically updates host (A) resource records (RRs) in DNS when configured for TCP/IP for clients running Windows 2000 or greater.

If you are using the DNS service on a Windows Server 2003 domain controller, you have the choice of creating standard or Active Directory-integrated zones. If you create standard zones, they will be enabled for dynamic update by default and zone replication will operate in exactly the same way as for standard DNS servers.

Advantages

The advantages of DNS dynamic updates include:

•	Reduced administrative overhead: DNS dynamic updates significantly reduce the administrative overhead, as it is no longer necessary for network administrators to manually create and edit the host records. When DNS clients start, they contact a DNS server and inform the server of the IP address that is bound to the network adapter.
•	DHCP interoperability: DNS dynamic updates allow hosts with IP addresses provided by DHCP to register their names in the DNS database and maintain up-to-date IP address information.
•	Basic Active Directory support: DNS dynamic update in Windows Server 2003 provides support for the basic records required by Active Directory.

Disadvantages

The disadvantage of DNS dynamic updates is that they do not add any security to the zone replication process; it remains inherently insecure.

Option 3—Active Directory-integrated DNS

Active Directory-integrated DNS adds to the services that DNS dynamic update provides. In particular, it adds support for all Active Directory record types by making use of Active Directory security and replication mechanisms. Active Directory-integrated DNS runs on Windows 2000 and Windows Server 2003 domain controllers, and is not available on computers running Windows Server 2003 Web Edition.

Active Directory-integrated zones are located in the Active Directory tree. In Windows 2000 this means within the domain partition, but in Windows Server 2003 you must decide whether to store it in the application directory partition or in the domain partition. A partition is a data structure within Active Directory that is used to differentiate data for different replication purposes. Each directory-integrated zone is stored in a dnsZone container object identified with the name chosen when it was created. Active Directory-integrated primary zones are replicated with other Active Directory-integrated primary zones in a multimaster topology.

You can use the DNS service running on a Windows Server 2003 domain controller to host both Active Directory-integrated zones and file-based zones. However, you cannot store an Active Directory-integrated as well as a file-based primary copy of a zone on the same domain controller.

In this design, because Active Directory holds all DNS data, Active Directory replication automatically propagates zone changes between domain controllers. If you are using Active Directory-integrated zones in a Windows Server 2003 domain, you can select an Active Directory-integrated zone replication scope using the DNS Microsoft Management Console (MMC). This cannot be done in Windows 2000 domains where the replication scope is always to all domain controllers in a domain.

Advantages

The advantages of Active Directory-integrated DNS include:

•	Automatic operation: Name registration is automatic and works with DHCP.
•	Secure and fast replication: Active Directory-integrated DNS uses secure replication without the need for potentially risky standard DNS zone transfers. Directory replication is also faster and more efficient than standard DNS replication because Active Directory replication processing is performed on a per-property basis, which means only relevant changes are propagated and less data is transmitted in updates for directory-stored zones.
•	Network bandwidth optimization: Network traffic is reduced because domain controllers only send the final result of all DNS changes at the next replication event. Also, when Active Directory zone replication occurs between sites, zone data that is greater than the default transfer size is compressed before being transferred, which minimizes the network traffic load.
•	Multimaster replication: Active Directory-integrated DNS makes use of Active Directory's multimaster replication topology to improve DNS availability and name resolution performance. Any domain controller running a DNS server can be designated as a primary source for the zone. Because the master copy of the zone is maintained in the Active Directory database (which is fully replicated to all domain controllers), the zone can be updated by any DNS server in the domain.
•	Granular security: You can use an access control list (ACL) to secure a dnsZone container object in the directory tree. This feature provides granulated access to either the zone or a specified resource record in the zone. For example, an ACL for a zone resource record can restrict dynamic updates for a specified client computer or a secure group such as a domain administrators group. This security feature is not available with standard primary zones.
•	Automatic backup: Zones are replicated and synchronized to new domain controllers automatically whenever a new one is added to an Active Directory domain. Although DNS service can be selectively removed from a domain controller, directory-integrated zones are already stored at each domain controller, therefore zone storage and management is not an additional overhead. Changes to the DNS database are propagated on the same schedule, and subject to the same rules, as the replication of other Active Directory data.
•	Reduced administration: By integrating DNS storage, storage management and replication issues for both DNS and Active Directory are merged viewable as a single administrative entity.
•	Simplified Active Directory-DNS planning: By integrating zones, you can simplify network planning. For example, domain controllers for each Active Directory domain correspond in a direct one-to-one mapping to DNS servers, which can simplify planning and troubleshooting of DNS and Active Directory replication problems because the same server computers are used in both topologies.

Disadvantages

The disadvantages of Active Directory-integrated DNS include:

•	Active Directory dependency: Requires DNS administrators to be familiar with Active Directory. Also, Active Directory problems can lead to DNS availability issues.
•	No support for secondary zones: Only primary zones can be stored in the directory; secondary zones must be stored in standard text files. Because you cannot store secondary zones in Active Directory, use of Active Directory-integrated zones requires the running of the DNS service on domain controllers and exclusive use of primary zones on domain controllers. However, you can use secondary zones in conjunction with Active Directory-integrated zones as long as the secondary copy of the primary Active Directory-integrated zone is hosted on a standard DNS server (not on a domain controller). However, there can be a problem using an Active Directory-integrated zone as a master for a secondary zone because the zone serial numbers are not guaranteed to be consistent across domain controllers.
•	Default replication scope may be inappropriate: In Windows 2000, all DNS data is replicated to all domain controllers in the domain even if they are not running the DNS service, and this cannot be changed. This is also the case in Windows Server 2003 if the default replication scope is selected, but you should choose a replication scope that includes domain controllers within an application directory partition only, even though it will require additional planning and administrative overheads.

Option 4—Active Directory-integrated Primary Zones with File-based Secondary Zones

A secondary zone contains a complete read-only copy of a zone. Secondary zones can be used to improve zone availability at remote sites if you do not want zone data to be replicated across a wide area network (WAN) link by means of Active Directory replication. With this option, secondary zones are added for most, if not all, of the Active Directory-integrated primary zones. You would not choose this option if all your DNS servers were running on domain controllers, because in such a case Active Directory would handle the replication and zone transfers.

Advantages

The advantage of this option is its flexible deployment. This design enables secondary zones to be hosted on DNS servers that are not serving as domain controllers, providing fault tolerance, geographical distribution of network hosts, and load balancing without needing to configure all DNS servers as domain controllers.

Disadvantages

The disadvantages of this option include:

•	Complexity: In this design, there are two distinct replication mechanisms and topologies—Active Directory multimaster replication between the Active Directory-integrated primary zones and primary-to-secondary replication from the Active Directory-integrated primary zones to the file-based secondary zones. This design is more complex and demands more management overhead.
•	Potential replication inconsistencies: When an Active Directory-integrated zone acts as a master for a secondary zone, the Active Directory-integrated zone serial numbers are not guaranteed to be consistent across domain controllers, which means not all DNS servers hosting secondary zones will have the same data after replication.

Recommendation for Best Practice

Use Windows Server 2003 DNS with Active Directory-integrated zones wherever possible, unless the network is small or involves supporting clients and services that are incompatible with Windows Server 2003 DNS. Windows Server 2003 DNS with Active Directory-integrated zones provides automatic registration of name records in the DNS database along with secure database updates and replication across the enterprise. Use of the Active Directory multimaster replication topology means that administrators do not need to support, manage, and secure separate replication services for DNS and directory services.

If necessary, you can combine Active Directory-integrated zones and file-based zones in the same design. For example, if the DNS server that is authoritative for the private root zone is running on an operating system other than Windows Server 2003 or Windows 2000, it cannot act as an Active Directory domain controller. Therefore, you must use file-based zones on that server. However, you can delegate this zone to any domain controller running either Windows Server 2003 or Windows 2000. For example, if the authoritative DNS server for the name wingtiptoys.com is running on a BIND 4.9.7 server that does not support Active Directory, you can add a delegation from this file-based zone that refers to the authoritative DNS server for the corp.wingtiptoys.com subdomain running on Windows Server 2003 DNS. In this way, the zone, corp.wingtiptoys.com, is now Active Directory-integrated.

Design Options for DNS Zones

Several types of DNS zones can be deployed, but the types you can deploy are dependent on the DNS technology options you select; not all zone types are available for each DNS technology.

Zones are either forward lookup zones or reverse lookup zones. For either type of zone, the zone file can be one of three types; primary, secondary, or stub. The replication between zones can be planned once the zone types have been decided.

Zone Replication

Designing zone replication involves identifying where to use replicated zones for availability and redundancy. After careful analysis, you can partition and delegate your DNS zones based on what is required for providing efficient and fault tolerant name service to each location or site.

Windows Server 2003 and Windows 2000 DNS support both incremental and full zone transfer of file-based zones. Incremental zone transfer is the default method, but if this method is not supported by a non-Microsoft DNS server that is involved in the transfer, Windows Server 2003 and Windows 2000 DNS default to the full zone transfer method.

Incremental zone transfer (described in RFC 1995 "Incremental Zone Transfer in DNS") provides better use of available network bandwidth. Rather than send the entire contents of the zone file, the master server only transfers the incremental changes in the zone. This reduces the effect of DNS zone transfers on network traffic. Without incremental zone transfers, the master server transfers the entire zone file to the secondary server every time a DNS zone is updated.

File-based primary zones can be hosted on any standard DNS server; this makes them interoperable with other platforms and DNS server versions. File-based zone files are simple files that can be easily copied for backup and migration purposes and easily modified with command-line tools, scripts, and text editors. DNS administrators with skills on non-Windows platforms can perform similar management procedures on Windows-based DNS by using zone files.

The following guidelines will help you select the appropriate zone replication method:

•	If you use file-based zones, you can only use file-based zone transfer.
•	If you have Windows Server 2003 or Windows 2000 Active Directory-integrated zones, use Active Directory replication. You must establish the replication scope if you use Active Directory-integrated zones in a Windows Server 2003 domain.
•	If you have Windows Server 2003 or Windows 2000 Active Directory-integrated zones and you want to propagate DNS data to DNS servers that are not domain controllers, for example at branch office sites, use file-based zone transfer to get DNS data to these servers only.

Recommendation for Best Practice

Use Active Directory-integrated zones if possible, as Active Directory distributes data using a multimaster replication model that provides more security than the standard DNS. Add secondary zones at remote sites where network bandwidth limitations do not allow Active Directory replication for zone file updates. If you cannot use Active Directory-integrated zones throughout the enterprise, you can also consider:

•	Encrypting zone replication sent over public networks, such as the Internet.
•	Restricting zone transfers to authorized servers.

Design Options for Number of DNS Servers to Deploy

A working DNS requires a single DNS server, but if this server becomes unavailable or overloaded, name resolution will fail. The following design options consider the appropriate number of DNS servers to deploy in an enterprise, and consider the advantages and disadvantages of each.

Option 1—Single DNS Server per Zone

In this design, a single DNS server is deployed for each DNS zone. It is possible to host more than one zone of the same type (such as forward lookup or reverse lookup) on the same server; however, doing so may negate some of the benefits of using DNS zones, such as spreading the load across multiple servers. Tests have shown that one Windows Server 2003 DNS server can easily host 200,000 zones containing six resource records. If you have a routed LAN with reliable and high-speed links, one DNS server may be sufficient even for a large network area that includes multiple subnets. In a common configuration, a single DNS server hosts both forward and reverse lookup zones.

Advantages

The advantages of using a single DNS server per zone include:

•	Simplicity: This design is easy to maintain and manage.
•	Economy: This design's costs are minimal with regard to server hardware and software licenses.

Disadvantages

The disadvantage of using a single DNS server per zone is that there is no fault tolerance in this design. If the single DNS becomes unavailable, all name resolution (except from temporary client DNS caches) will fail. There is also no scope for distributing DNS load across the network in this design.

Option 2—Single DNS Server with Network Load Balancing

This design option is a variation of the single DNS server per zone design. In this design a Network Load Balancing cluster is used for the “single” DNS server and clients are configured with the address of the Network Load Balancing cluster.

Advantages

The advantages of using a single DNS with Network Load Balancing include:

•	Fault tolerance: This design provides availability and fault tolerance. If one of the servers in the cluster fails, the DNS service is still available. Clients are configured with a single DNS server address and yet they get fault tolerance.
•	Simplicity: This design is simple. There is no need to support zone replication between DNS servers, which can have security implications, particularly for non-Active Directory-integrated zones.

Disadvantages

The disadvantages of using a single DNS with Network Load Balancing include:

•

Configuration requirements: This design is more complex than a single server and requires more hardware and software configuration.

•

Potential point of failure: There is still a potential single point of failure; if the clustering fails in such a way that the shared network load balancing IP address fails too, then DNS will become unavailable. However, this can be avoided by configuring the DNS clients with the individual IP addresses of the DNS servers in the cluster as well as that of the cluster so that they can contact an individual server if the clustering fails.

Option 3—Two DNS Servers per Zone

In this design, a second DNS server is deployed for each DNS zone; this second server can be on the same subnet or placed in another location. If the zones are file-based, the second server will host a secondary zone file that is a read-only copy of the primary zone file. If the zones are Active Directory-integrated, both servers will hold primary copies of the data.

Advantages

The advantages of using two DNS servers per zone include:

•	Fault tolerance: If you have a high number of client nodes on a single subnet, placing more than one DNS server on the subnet allows for backup and failover in case the preferred DNS server stops responding.
•	Load balancing: Secondary servers can be used to distribute DNS query traffic across servers. They provide a means to load balance DNS query traffic on your network and reserve the primary DNS servers for exclusive use by clients that need to perform dynamic registration and updates of their host records.

Disadvantages

The disadvantages of using two DNS servers per zone include:

•	Replication requirement: The introduction of a second DNS server into the design elevates the need for efficient zone replication in order to minimize synchronization latency as much as possible.
•	Hardware requirement: This design requires more server hardware than the single DNS design.

Option 4—Multiple DNS Servers per Zone

In this design, more than two DNS servers are deployed for each zone. In the case of file-based zones, there will be two or more secondary zones for each primary zone. If the zones are Active Directory-integrated, all servers hold primary copies of the data. The additional DNS servers can be configured as stand-alone servers to handle large numbers of client queries. A stand-alone server can be set up as a caching only server, which forwards non-cached queries to another DNS server, or as a secondary server for an Active Directory-integrated zone.

Advantages

The advantages of using multiple DNS servers per zone include:

•	Availability: Multiple DNS servers provide redundancy when your namespace design requires greater DNS availability.
•	Response times: When better DNS performance is required, a good multi-server design can improve query response time by allowing clients to query a local server. This design can also reduce WAN traffic caused by DNS queries for remote locations.
•	Bandwidth management: A multi-server design can help reduce network bandwidth consumption in high-volume environments. High bandwidth consumption can particularly be an issue with file-based zones where zone transfers and DNS query traffic can overload slow links. If high-volume traffic is a consideration in your environment, add additional DNS servers to provide load balancing.

Disadvantages

The disadvantages of using multiple DNS servers per zone include:

•

Replication overhead: Although DNS is designed to help reduce broadcast traffic between local subnets, it does create some traffic between servers and clients; this consideration is important, particularly in complex routed environments. Traffic considerations sometimes remain an issue even though the DNS service supports incremental zone transfers (IXFRs) and clients and servers can cache recently used names. This is especially true with short DHCP leases, which require more frequent dynamic updates to DNS.

•

Primary DNS server performance: If your DNS design includes file-based primary and secondary zones and you run a large number of secondary servers for a zone, the primary master name server can become overloaded when the secondary servers poll to ensure that their zone data is current. You can solve this problem in one of three ways:

•	Use some of the secondary servers as master servers for the zone: Other secondary servers can poll and request zone updates from these master servers.
•	Increase the refresh interval so that the secondary servers poll less frequently: However, note that a longer refresh interval causes your secondary zones to be outdated more often.
•	Create caching-only DNS servers: Remote locations can benefit from local caching-only DNS servers in addition to the DNS servers that you have added to ensure availability.

Recommendation for Best Practice

To reduce administrative overhead, it is best to use the minimum number of DNS servers; however, the minimum must be at least two DNS servers authoritative for each zone to enable fault tolerance and load sharing. A single DNS server is not recommended because it provides no fault tolerance at all.

If you support a large number of clients, add additional DNS servers. Use expected number of queries and dynamic updates per second to determine the number of DNS servers that you need and whether these additional servers need to be standard servers or caching only.

If you have an Internet presence, DNS must work properly so that clients may access your Web servers, send mail, and locate other services without interruptions; therefore, it is recommended that you run a secondary DNS server offsite. If you have a business relationship with an organization on the Internet such as a business partner or ISP, they might agree to run a secondary server for you; however, ensure that the data on the organization's server is secure against Internet attackers.

Design Options for Optimizing DNS Queries—Client Configuration

The design options involve decisions on how clients are informed of DNS server addresses and how clients are configured for DNS dynamic update support and search suffix lists.

Clients can be configured to use DNS in several ways, including the following:

•	The addresses of DNS servers can be added as part of the IP configuration, through manual setups, DHCP scope properties, or Group Policies.
•	The client browser can be configured to point to a proxy server and use it for all DNS lookups. This can be done through manual configuration of the browser properties, automated browser rollouts using INS files, Web Proxy AutoDiscovery (WPAD), or PAC files.
•	The client can be configured to use a Winsock firewall client, such as that provided with Microsoft ISA Server. In such cases, rules can be used to redirect requests for Internet resources to the proxy server, which then issues and returns DNS queries on behalf of the Winsock client.

Clients are mainly configured for DNS dynamic update support and search suffix lists in the following two ways:

•	The DNS settings can be configured as part of the IP configuration, either through manual setups or DHCP scope properties.
•	The DNS settings can be propagated through the use of Group Policies, which are typically delivered to the client from Active Directory domain controllers.

Windows Server 2003 includes a new set of Group Policies to simplify the rollout of Windows Server 2003 DNS clients. For more information about these Group Policies, refer to the “Networking Guide” of the Windows Server 2003 Resource Kit at the following URL:

http://www.microsoft.com/windowsserver2003/techinfo/reskit/resourcekit.mspx

Recommendation for Best Practice

Configure your clients' DNS server lists and suffix search lists by including at least two DNS server IP addresses on the clients and domain controllers; the IP address for a preferred server and the IP address for an alternate server. Use a server in the local site as the preferred server. The alternate server may be in a local or remote site.

By default, the DNS suffix search list is populated based on the client's primary DNS suffix and any connection-specific DNS suffixes. You can modify the DNS suffix search list using the DNS manager or Group Policy. You should limit the size of your suffix search list, because a large list increases network traffic.

Design Options for Optimizing DNS Queries—Server Configuration

Large enterprises often have multiple internal namespaces, and your DNS design must be able to provide effective name resolution for any of these namespaces. There are several DNS server configuration options that can be used to provide name resolution across namespaces and efficient name resolution for external names, if required.

Option 1—Delegations

Once you have an internal DNS root you can add delegations within each top-level DNS zone; for example, corp.wingtiptoys.com as the root with a delegation of na.corp.wingtiptoys.com to another primary DNS server. In this way, the corp.wingtiptoys.com zone is aware of the na.corp.wingtiptoys.com zone and specifically knows the name servers responsible for the other zone. Depending on whether queries for the other zone are iterative or recursive, the DNS server can either return information on the relevant authoritative name server or carry out a query on the client's behalf.

Advantages

The advantages of using delegations include:

•	Simplicity: DNS delegations are easy to configure and manage.
•	Efficiency: Use of delegations is an efficient way to take advantage of the knowledge and awareness of other domains.

Disadvantage

The disadvantage of using delegations relates to traceability; in more complex configurations, records of which domains are aware of which others may be difficult to maintain.

Option 2—Forwarding

If a non-root server attempts to resolve a name for which it is neither authoritative nor has a delegation, and which it does not already have in its cache, it can attempt one of the following:

•

Query a root server: Root server addresses are configured by the root hints list. If there is no root hints list configured, a DNS server cannot query a root server. A root hints list contains information about well-known servers on the Internet that help DNS servers resolve name queries; these servers maintain information about the servers responsible for the global top-level domains (GLTDs), such as com, edu, net, us, uk, and au.

•

Forward queries to a forwarder: Forwarders are ordinary DNS servers and require no special configuration. A DNS server is called a forwarder because it is the recipient of a query forwarded by another DNS server.

Forwarding can be turned off by either leaving the list of forwarders blank so that there is no information on how to do forwarding or by disabling recursion. If recursion is disabled, the DNS server will only respond directly to a client’s DNS query, either with an authoritative answer or a failure; it will not attempt to query or forward the query to any other server.

Forwarding can be used for offsite or Internet traffic. For example, a branch office DNS server can forward all offsite traffic to a forwarder at the company headquarters, and an internal DNS server can forward all Internet traffic to a forwarder on the Internet. Forwarders also provide additional network security by minimizing the list of DNS servers that can communicate across a firewall.

In the case of multiple internal namespaces, the DNS servers that host the top-level DNS zones of one namespace can forward name resolution queries for a second namespace to the DNS servers that host the top-level DNS zones for that second namespace. Similarly, the DNS servers that host the top-level DNS zones of the second namespace can forward name resolution queries for the first namespace to the DNS servers that host the top-level DNS zones for the first namespace.

This forwarding can be achieved in three ways; by using standard forwarders, conditional forwarders, or stub zones.

Standard Forwarders

A standard forwarder design is where a DNS server is configured to forward all queries that cannot be resolved locally to another designated DNS server or servers. In this case, when the DNS client issues a recursive query (the default type of client query) the DNS server attempts to provide the client with an answer even if it cannot provide an authoritative answer itself.

Advantage

The advantage of standard forwarder design is that it can be configured on all DNS servers regardless of platform or version, which means that a forwarding design can be implemented in any DNS design.

Disadvantage

The disadvantage of standard forwarder design is that it is inefficient. In this design, it is not possible to control the forwarding; either the query is resolved by the local DNS server or it is forwarded to another server. Therefore, standard forwarding can generate additional network traffic. For example, a non-root server in Site A is configured to forward queries to a forwarder in Site B and it needs to resolve a name in a zone hosted by a server in Site C. Because the non-root server in Site A can forward queries only to Site B, it cannot directly query the server in Site C. Instead, it forwards the query to the forwarder in Site B and the forwarder queries the server in Site C. (This is the only forwarding method available if you are not running Windows Server 2003 DNS.)

Conditional Forwarders

With a conditional forwarding design you can control the name resolution process at a more granular level. When configuring the DNS server, you can specify the names of domains for which queries can be forwarded and the DNS servers to which the forwarding is to happen. For example, you can specify that queries for any name in the wingtiptoys.com domain are to be forwarded to DNS server A whereas queries for names in the tailspintoys.com are to be forwarded to DNS server B; all other queries are to be forwarded to DNS server C and so on. DNS servers that are configured to use conditional forwarding can perform name resolution without using recursion.

Advantages

The advantages of using conditional forwarder design include:

•	Reduced network traffic: Use of conditional forwarding allows you to configure your DNS servers to forward queries to different servers based on the domain name specified in the query. This eliminates steps in the forwarding chain and reduces network traffic. When conditional forwarding is applied, a server in Site A can forward queries to forwarders in Site B or Site C, as appropriate.
•	Configurable name resolution to other namespaces: If your internal network does not have a private root and your users need access to other namespaces, such as a network belonging to a partner company, conditional forwarding can be used to enable servers to query for names in other namespaces.

Disadvantages

The disadvantages of using conditional forwarder design include:

•	Limited support: Conditional forwarding is only supported in Windows Server 2003 DNS, which may present difficulties in a large cross-platform DNS design.
•	Management overhead: The configuration of conditional forwarders needs to be carefully planned and managed. If your network configuration changes, you may need to modify the conditional forwarders lists; otherwise, queries may get forwarded to servers that are no longer appropriate. In contrast, using standard forwarders, or root hints, requires minimal configuration and maintenance.

Forwarding Guidelines

If you are using standard or conditional forwarding, the following guidelines illustrate some examples of best practices:

•	Forward queries to more than one forwarder in order to ensure availability and to distribute the load on forwarders: The recursive queries that forwarders send to the Internet can require a significant amount of time to answer due to the nature of the Internet. With a large number of internal DNS servers using these forwarders for Internet queries, they can experience a substantial concentration of network traffic.
•	Use chain forwarders to limit the number of servers that must send queries offsite: Depending on your traffic patterns, using forwarders can minimize the amount of offsite traffic from your organization.
•	Avoid forwarder loops: If you have configured a DNS server named server-1 to forward queries for widgets.example.com to a DNS server named server-2, do not configure server-2 to forward queries for widgets.example.com to DNS server server-3. This is an inefficient resolution process and could result in errors if server-3 is accidentally configured to forward queries for widgets.microsoft.com to server-1, in which case you would have a forwarder loop.
•	Use conditional forwarding wherever possible: Doing so allows you to control how the forwarding operates.
•	Keep forwarder configuration uncomplicated: For every DNS server configured with a forwarder, queries can be sent to a number of different places. Each forwarder and each conditional forwarder must be administered for the benefit of DNS client queries, and this process can be time consuming. Use forwarders strategically where they are needed the most, such as to resolve offsite queries or share information between namespaces. If necessary, disable all recursion at the DNS server to disable forwarding where it is not needed.

Stub Zones

You can use Windows Server 2003 DNS stub zones to facilitate DNS data distribution between separate namespaces. A stub zone is a partial copy of a zone that can be hosted by a DNS server and used to resolve recursive or iterative queries. With stub zones, authoritative DNS servers for the parent zones automatically learn about new authoritative DNS servers for the child zones and can perform recursion to them. Stub zones can also be used as an alternative to other forwarding methods to allow DNS servers to be aware of other external namespaces. However, this is not their primary purpose. For more information on stub zones, refer to the Windows 2003 Server DNS Help files.

Advantages

The advantages of using stub zones include:

•

Automatic updates: Stub zones ensure that the DNS server that is authoritative for a parent zone automatically receives updates about the name servers that are authoritative for its child zones. This is done by adding the stub zone to the server that is hosting the parent zone. A conditional forwarder is not an efficient method of doing this, because whenever the authoritative DNS servers for the child zones change the conditional forwarder setting on the DNS server hosting the parent zone needs to be manually configured.

•

Alternative method for forwarding external queries: Stub zones , although less efficient, provide an alternative in case conditional forwarding cannot be used to provide information on other external namespaces.

Disadvantages

The disadvantages of using stub zones include:

•

Limited support: Stub zones are only implemented in Windows Server 2003 DNS, which may present interoperability challenges to your DNS design.

•

Inefficient for external name resolution: Using stub zones to provide information for external namespaces is inefficient; conditional forwarding should be used for this purpose whenever possible. A name server hosting a stub zone always responds with a complete list of the authoritative name servers for that zone, whereas conditional forwarding is, by definition, a configurable list of name servers.

Option 3—Secondary Zones

In this configuration, the DNS servers that host the top-level DNS zones in the first and second namespaces also host secondary zones of each other's top-level DNS namespaces. For example, the root name server for wingtiptoys.com would host a secondary zone for tailspintoys.com (if the enterprise has two distinct public namespaces).

Advantages

The advantage of the secondary zones in this configuration is that the DNS servers that host the top-level DNS zones in each namespace are automatically aware of the DNS servers in the other namespace.

Disadvantages

The disadvantages of using secondary zones include:

•	Increased storage requirements: This solution requires increased storage space for hosting secondary copies of top-level zones in different namespaces, because DNS servers now host two zones instead of one.
•	Increased network traffic: Using secondary zones increases network traffic, as any changes made to the root zone must be replicated to the secondary zone using some form of zone transfer.

Recommendation for Best Practice

Use delegation if you can; this is the simplest to manage and configure. If you cannot use delegation and do not run Windows Server 2003 DNS, use standard forwarding. However, if you are using Windows Server 2003 DNS, use stub zones to ensure that the parent zone's authoritative DNS server automatically receives updates about any child zone's authoritative name servers.

Secondary zones are not recommended because they require additional storage space for hosting secondary copies of top-level zones in different namespaces; they also generate increased zone transfer traffic.

Logical Design Example

The following figure illustrates how Active Directory-integrated zones and file-based secondary zones can be deployed together to provide enterprise DNS services.

Enterprise Design for DNS

On This Page

Service Definition

Assigning DNS Names

Namespace Planning

Naming Design Guidelines

Internal Subdomain Naming Guidelines

Computer Naming Design Guidelines

Service Design

Design Inputs

Design Options for Name Service Technology

Option 1—Static HOSTS Files

Advantages

Disadvantages

Option 2—DNS Service

Advantages

Disadvantages

Recommendation for Best Practice

Logical Design

Design Options for Namespace Design

Option 1—Single Namespace for the Enterprise

Advantages

Disadvantages

Option 2—Internal Domain as a Subdomain of External Domain

Advantages

Disadvantages

Option 3—Unrelated Names for Internal and External Domains

Advantages

Disadvantages

Option 4—Same Name for Internal and External Domains

Advantages

Disadvantages

Additional Option—Use of Subdomains

Advantages

Disadvantages

Recommendation for Best Practice

Design Options for DNS Hosting

Option 1—External Root

Advantages

Disadvantages

Option 2—Internal Root

Advantages

Disadvantages

Recommendation for Best Practice

Design Options for Hosting Internal and External Namespaces

Option 1—Complete DNS

Advantages

Disadvantages

Option 2—Split DNS

Advantage

Disadvantage

Option 3—Split-Split DNS

Advantages

Disadvantages

Recommendation for Best Practice

Design Options for DNS Technology

Option 1—Standard DNS

Advantages

Disadvantages

Option 2—Dynamic DNS

Advantages

Disadvantages

Option 3—Active Directory-integrated DNS

Advantages

Disadvantages

Option 4—Active Directory-integrated Primary Zones with File-based Secondary Zones

Advantages

Disadvantages

Recommendation for Best Practice

Design Options for DNS Zones

Zone Replication

Recommendation for Best Practice

Design Options for Number of DNS Servers to Deploy

Option 1—Single DNS Server per Zone

Advantages

Disadvantages

Option 2—Single DNS Server with Network Load Balancing

Advantages

Disadvantages

Option 3—Two DNS Servers per Zone