Deploying DNS

99
CHAPTER 3 Microsoft® Windows® Server 2003 Domain Name System (DNS) provides efficient name resolution and interoperability with standards-based technologies. Deploying DNS in your client/server infrastructure enables resources on a TCP/IP network to locate other resources on the network by using host name-to-IP address resolution and IP address-to-host name resolution. The Active Directory® directory service requires DNS for locating network resources. In This Chapter Overview of DNS Deployment........................................114 Examining Your Current Environment................................120 Designing a DNS Namespace.........................................122 Designing a DNS Server Infrastructure.............................141 Designing DNS Zones...............................................147 Configuring and Managing DNS Clients..............................154 Securing Your DNS Infrastructure..................................155 Integrating DNS with Other Windows Server 2003 Services...........164 Implementing Windows Server 2003 DNS..............................168 Additional Resources..............................................174 Related Information For more information about DNS, the Windows Server 2003 DNS Server service, and Windows Server 2003 DNS Client service, see the Networking Guide of the Microsoft® Windows® Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit). Deploying DNS

Transcript of Deploying DNS

Page 1: Deploying DNS

C H A P T E R 3Microsoft® Windows® Server 2003 Domain Name System (DNS) provides efficient name resolution and interoperability with standards-based technologies. Deploying DNS in your client/server infrastructure enables resources on a TCP/IP network to locate other resources on the network by using host name-to-IP address resolution and IP address-to-host name resolution. The Active Directory® directory service requires DNS for locating network resources.

In This Chapter

Overview of DNS Deployment.............................................................................114Examining Your Current Environment.................................................................120Designing a DNS Namespace..............................................................................122Designing a DNS Server Infrastructure................................................................141Designing DNS Zones..........................................................................................147Configuring and Managing DNS Clients...............................................................154Securing Your DNS Infrastructure........................................................................155Integrating DNS with Other Windows Server 2003 Services................................164Implementing Windows Server 2003 DNS...........................................................168Additional Resources...........................................................................................174

Related Information

For more information about DNS, the Windows Server 2003 DNS Server service, and Windows Server 2003 DNS Client service, see the Networking Guide of the Microsoft® Windows® Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Deploying DNS

Page 2: Deploying DNS

114   Chapter 3   Deploying DNS

Overview of DNS DeploymentDNS is the primary method for name resolution in the Microsoft® Windows® Server 2003, Standard Edition; Windows® Server 2003, Enterprise Edition; and Windows® Server 2003, Datacenter Edition operating systems (collectively referred to as “Windows Server 2003” in this chapter). DNS is also a requirement for deploying Active Directory, but Active Directory is not a requirement for deploying DNS. However, integrating DNS with Active Directory enables DNS servers to take advantage of the security, performance, and fault tolerance capabilities of Active Directory.

If you are planning to deploy DNS to support Active Directory, plan your DNS namespace in conjunction with planning your Active Directory logical structure. For more information about designing the Active Directory logical structure, see “Designing the Logical Structure” in Designing and Deploying Directory and Security Services of this kit.

Page 3: Deploying DNS

Implementing Windows Server 2003 DNS   115

Process for Deploying DNSDeploying DNS involves planning and designing your DNS infrastructure, including the DNS namespace, DNS server placement, DNS zones, and DNS client configuration. In addition, if you are integrating DNS with Active Directory, you must plan the level of integration and identify your security, scalability, and performance requirements. Figure 3.1 shows the DNS deployment process.

Figure 3.1   Deploying DNS

Page 4: Deploying DNS

116   Chapter 3   Deploying DNS

DNS ConceptsWindows Server 2003 DNS is based on Requests For Comments (RFCs) standards developed by the Internet Engineering Task Force (IETF) and is therefore interoperable with other standards-compliant DNS implementations. DNS uses a distributed database that implements a hierarchical naming system. This naming system enables an organization to expand its presence on the Internet and enables the creation of names that are unique both on the Internet and on private TCP/IP-based intranets.

By using DNS, any computer on the Internet can look up the name of any other computer in the Internet namespace. Computers running Windows Server 2003 and Microsoft® Windows® 2000 also use DNS to locate domain controllers and other servers running Active Directory.

DNS Roles

Deploying a DNS infrastructure involves design, implementation, and maintenance tasks. The individuals who are responsible for these tasks include DNS designers and the DNS administrators. Before you begin designing your DNS deployment, it is helpful to identify the individuals in your organization who are responsible for these roles. Table 3.1 lists the responsibilities of the DNS designer and DNS administrator roles.

Table 3.1   DNS Roles

Role Responsibility

DNS designer Designing the DNS namespace

Placing DNS servers and zones within the DNS namespace

Creating a secure DNS infrastructure

Designing DNS integration with Active Directory

DNS administrator Deploying, configuring, and managing the DNS infrastructure

Managing Active Directory integration

DNS designer roleIf you are deploying DNS to support Active Directory in an environment that does not already have a DNS infrastructure, the DNS designer is responsible for the DNS integration with the entire Active Directory forest. The DNS designer works closely with the DNS administrator for Active Directory.

If you are deploying DNS to support Active Directory in an environment that has an existing DNS infrastructure, the DNS designer works with the DNS administrator for Active Directory to delegate the forest root DNS name to Active Directory. The Active Directory forest administrator delegates management of DNS to a DNS administrator.

DNS administrator roleDNS administrators manage and maintain the DNS namespace, DNS servers, DNS clients, DNS zones, and zone propagation. DNS administrators are also responsible for maintaining network security by anticipating and mitigating new security threats. In addition, DNS administrators are responsible for DNS integration with other Windows Server 2003 services.

Page 5: Deploying DNS

Implementing Windows Server 2003 DNS   117

New in Windows Server 2003

Windows Server 2003 DNS includes several new features, including:

Conditional forwarding. Conditional forwarding enables a DNS server to forward DNS queries based on the DNS domain name in the query. For more information about conditional forwarding, see Help and Support Center for Windows Server 2003.

DNS application directory partitions. DNS application directory partitions enable you to set the replication scope for Active Directory–integrated DNS data. By limiting the scope of replication traffic to a subset of the servers running Active Directory in your forest, you can reduce replication traffic.

DNSSEC. DNS provides basic support for the DNS Security Extensions (DNSSEC) protocol as defined in RFC 2535: Domain Name System Security Extensions. For more information about DNSSEC, see Help and Support Center for Windows Server 2003.

EDNS0. Extension Mechanisms for DNS (EDNS0) enable DNS requestors to advertise the size of their UDP packets and facilitate the transfer of packets larger than 512 octets, the original DNS limit for UDP packet size. For more information about EDNS0, see Help and Support Center for Windows Server 2003.

Tools for Deploying DNS

Windows Server 2003 includes a number of tools to assist you in deploying a DNS infrastructure.

Netdiag.exeThe Netdiag.exe tool assists you in isolating networking and connectivity problems. Netdiag.exe performs a series of tests that you can use to determine the state of your network client. For more information about Netdiag.exe, in Help and Support Center for Windows Server 2003, click Tools, and then click Windows Support Tools

Nslookup.exeYou can use the Nslookup.exe command-line tool to perform query testing of the DNS domain namespace and to diagnose problems with DNS servers.

Dnscmd.exeYou can use the Dnscmd.exe command-line tool to perform administrative tasks on the DNS server the same as you can by using the DNS Microsoft Management Console (MMC) snap-in.

DNSLintDNSLint is a command-line tool that you can use to address some common DNS name resolution issues, such as lame delegation and DNS record verification. DNSLint is in the Support.cab file in the \Support\Tools folder on the Windows Server 2003 operating system CD. You can install DNSLint by running Suptools.msi.

Page 6: Deploying DNS

118   Chapter 3   Deploying DNS

Terms and Definitions

The following are some important DNS-related terms.

A DNS server that hosts a primary or secondary copy of zone data. Each zone has at least one authoritative DNS server.

A DNS query setting that enables a DNS server to route a request for a particular name to another DNS server by specifying a name and IP address. For example, a DNS server in contoso.com can be configured to forward queries for names in treyresearch.com to a DNS server hosting the treyresearch.com zone.

The process of using resource records to provide pointers from parent zones to child zones in a namespace hierarchy. This enable DNS servers in a parent zone to route queries to DNS servers in a child zone for names within their branch of the DNS namespace. Each delegation corresponds to at least one zone.

A service that runs on client computers and sends DNS queries to a DNS server. Some resolvers use a cache to improve name resolution performance.

The hierarchical naming structure of the domain tree. Each domain label that is used in a fully qualified domain name (FQDN) indicates a node or branch in the domain tree. For example, host1.contoso.com is an FQDN that represents the node host1, under the node Contoso, under the node com, under the DNS root.

A computer that hosts DNS zone data, resolves DNS queries, and caches the query responses.

In DNS, the inverted hierarchical tree structure that is used to index domain names within a namespace. Domain trees are similar in purpose and concept to the directory trees used by computer filing systems for disk storage.

A namespace on the Internet, such as www.microsoft.com, that can be accessed by any connected device. Beneath the top-level domains, the Internet Corporation for Assigned Names and Numbers (ICANN), the Internet Assigned Numbers Authority (IANA), and other Internet naming authorities delegate domains to organizations such as Internet Service Providers (ISPs), which in turn delegate subdomains to their customers or host zones for their customers. For more information about public namespaces, see the Internet Assigned Numbers Authority (IANA) link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

An authoritative DNS zone that is primarily used to resolve network resource names to IP addresses.

A DNS name that uniquely identifies a node in a DNS namespace. The FQDN of a computer is a concatenation of the computer name (for example, client1) and the primary DNS suffix of the computer (for example, contoso.com), and a terminating dot (for example, contoso.com.).

Authoritative DNS serverConditional forwardingDelegatiDNS client resolverDNS namespacDNS servDomain Public namespaceForward lookup zoneFully qualified domain name (FQDN)

Page 7: Deploying DNS

Implementing Windows Server 2003 DNS   119

A namespace internal to an organization to which it can control access. Organizations can use the internal namespace to shield the names and IP addresses of its internal computers from the Internet. A single organization might have multiple internal namespaces. Organizations can create their own root servers and any subdomains as needed. The internal namespace can coexist with an external namespace.

A query made by a client to a DNS server for an authoritative answer that can be provided by the server without generating additional server-side queries to other DNS servers.

A DNS server that hosts read-write copies of zone data, has a DNS database of resource records, and resolves DNS queries.

A DNS server that hosts a read-only copy of zone data. A secondary DNS server periodically checks for changes made to the zone on its configured primary DNS server, and performs full or incremental zone transfers, as needed.

A query made by either a client or a DNS server on behalf of a client, the response to which can be an authoritative answer or a referral to another server. Recursive queries continue until the DNS server receives an authoritative answer for the queried name. By default, recursion is enabled for Windows Server 2003 DNS.

A DNS database structure containing name information for a particular zone. For example, an address (A) resource record can map the IP address 172.16.10.10 to the name DNSserverone.contoso.com or a namespace (NS) resource record can map the name contoso.com to the server name DNS1.contoso.com. Most of the basic RR types are defined in RFC 1035: Domain Names — Implementation and Specification, but additional RR types are defined in other RFCs.

An authoritative DNS zone that is primarily used to resolve IP addresses to network resource names.

A partial copy of a zone that can be hosted by a DNS server and used to resolve recursive or iterative queries. Stub zones contain the Start of Authority (SOA) resource records of the zone, the DNS resource records that list the zone’s authoritative servers, and the glue address (A) resource records that are required for contacting the zone’s authoritative servers. Stub zones are used to reduce the number of DNS queries on a network, and to decrease the network load on the primary DNS servers hosting a particular name.

In a DNS database, a contiguous portion of the domain tree that is administered as a single separate entity by a DNS server. The zone contains resource records for all of the names within the zone.

A file that consists of the DNS database resource records that define the zone. DNS data that is Active Directory–integrated is not stored in zone files because the data is stored in Active Directory. However, DNS data that is not Active Directory–integrated is stored in zone files.

The process of copying the contents of the zone file located on a primary DNS server to a secondary DNS server. Using zone transfer provides fault tolerance by synchronizing the zone file in a primary DNS server with the zone file in a secondary DNS server. The secondary DNS server can continue performing name resolution if the primary DNS server fails.

Internal namespaceIterative queryPrimary DNS serverSecondary DNS serverRecursive queryResource record (RR)Reverse lookup zoneStub ZoneZoZone transfe

Page 8: Deploying DNS

120   Chapter 3   Deploying DNS

Examining Your Current EnvironmentBefore you deploy Windows Server 2003 DNS, you must assess your current environment to determine the DNS needs and constraints of your organization. After that, create a Windows Server 2003 DNS deployment plan to match those needs and constraints. Figure 3.2 shows the process for examining your current environment.

Figure 3.2   Examining Your Current Environment

Page 9: Deploying DNS

Implementing Windows Server 2003 DNS   121

Determining Internet StatusIf you want devices outside your private network to be able to resolve names belonging to your internal namespace, your IP addresses and DNS domain names must be registered with an Internet registration authority (Internet registrar). Internet registrars are organizations that are responsible for:

Assigning IP addresses.

Registering DNS domain names.

Keeping public records of registered IP addresses and domain names.

If your network is currently or will be connected to the Internet, you must ensure that the domain name of your organization is valid and registered to you.

Identifying the DNS Data HostDetermine who will host your DNS data. You can either host your DNS data on your own DNS servers or you can have an external ISP host your DNS data. By hosting your own DNS data, you have complete control of network resource allocation and security. Use an ISP if you have a small network that will not be expanding rapidly in the near future.

If you decide to use an ISP to host your DNS data, ensure that the DNS infrastructure of the ISP can support your DNS deployment.

Even if you decide to host your own DNS data, you might consider using an ISP to resolve names outside your private network. For example, the company contoso.com might decide to host all names belonging to the internal namespace corp.contoso.com on its own DNS servers while using an ISP to enable its employees to resolve external Web addresses such as www.microsoft.com.

Page 10: Deploying DNS

122   Chapter 3   Deploying DNS

Analyzing Your Network TopologyAnalyze your existing network topology and plan your DNS namespace while accounting for the service and administrative goals of your organization.

Allow for anticipated expansion of the number of nodes in your DNS hierarchy by including domain name placeholders between the domain names that you are initially deploying. Adding domain name placeholders enables you to avoid having to redesign your DNS infrastructure to accommodate additional domain names.

Anticipate the possibility of changes to your business model by assigning domain names that can be used in a modified context. For example, instead of using the domain name accounting.contoso.com, you might use finance.contoso.com, in anticipation of the possibility of expanding into additional financial services beyond accounting.

Diagram Your Existing DNS Infrastructure

If you are upgrading to Windows Server 2003, rolling out a new DNS deployment, or integrating Windows Server 2003 DNS with Active Directory, you might not need to make any changes to your existing DNS infrastructure. However, if you are migrating from a third-party DNS infrastructure or integrating Windows Server 2003 DNS with an existing third-party DNS infrastructure, create a diagram of your existing DNS infrastructure, including domains, servers, and clients. Use this diagram to assist you in deciding whether to make changes to your current DNS infrastructure when you deploy Windows Server 2003 DNS.

Identify Your Security Policies

Identify and document your organization’s security policies before you begin to design and deploy your DNS infrastructure. In this way, you can ensure that your DNS servers, zones, and resource records support these policies. For more information about security policies, see “Deploying Security Policy” in Designing a Managed Environment of this kit.

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

Page 11: Deploying DNS

Implementing Windows Server 2003 DNS   123

Figure 3.3   Designing a DNS Namespace

Page 12: Deploying DNS

124   Chapter 3   Deploying DNS

Identifying Your DNS Namespace RequirementsThe 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.

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

Table 3.2   DNS Namespace Design Requirements

Scenario Design Requirements

You are upgrading an existing DNS infrastructure from a version of Windows earlier than Windows Server 2003.

DNS namespace design can remain the same.

You are upgrading from a third-party DNS infrastructure that uses DNS software that adheres to standard DNS domain naming guidelines.

DNS namespace design can remain the same.

Your existing DNS software does not conform to standard DNS domain naming guidelines.

Bring your existing DNS namespace design into compliance with DNS domain naming guidelines before deploying a Windows Server 2003  DNS namespace.

You are integrating Windows Server 2003 DNS into an existing third-party DNS software that adheres to standard DNS domain naming guidelines.

Integrate Windows Server 2003 DNS with your current DNS infrastructure. You do not need to change the namespace design of the third-party DNS infrastructure or your existing namespace.

You are deploying a new Windows Server 2003 DNS infrastructure.

Design a logical naming convention for your DNS namespace based on DNS domain naming guidelines.

You are deploying Windows Server 2003 DNS to support Active Directory.

Create a DNS namespace design that is based on your Active Directory naming convention.

You are modifying your existing DNS namespace to support Active Directory,

Ensure that Active Directory domain names match your existing DNS

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

Page 13: Deploying DNS

Implementing Windows Server 2003 DNS   125

but you do not want to redesign your DNS namespace.

names. This enables you to deploy the highest level of security by using the simplest management techniques.

Page 14: Deploying DNS

126   Chapter 3   Deploying DNS

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

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

By using different names for the internal and external domains.

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

Table 3.3   Mixed Internal and External DNS Namespace Design Options

Design Option Management Complexity Example

The internal domain is a subdomain of the external domain.

Easy to deploy and administer.

An organization with an external namespace contoso.com uses the internal namespace corp.contoso.com.

The internal and external domain names are different from each other.

More complicated than previous option.

An organization uses contoso.com for its external namespace, and corp.internal for its internal namespace.

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

Page 15: Deploying DNS

Implementing Windows Server 2003 DNS   127

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

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

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

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

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

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

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

Page 16: Deploying DNS

128   Chapter 3   Deploying DNS

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

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

Using an internal DNS root provides the following benefits:

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

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

Page 17: Deploying DNS

Implementing Windows Server 2003 DNS   129

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

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

Table 3.4   Client Proxy Capabilities

Proxy CapabilityMicrosoft Software with Corresponding Proxy

Capabilities

Forwards Queries

Can You Use an Internal

Root?

No Proxy Generic Telnet

Local Address Table (LAT)

Winsock Proxy (WSP) 1.x and later

Microsoft® Internet Security and Acceleration (ISA) Server 2000 and later

Name Exclusion List

WSP 1.x and later

Internet Security and Acceleration (ISA) Server 2000 and later, and all versions of Microsoft® Internet Explorer

Proxy Auto-configuration (PAC) File

WSP 2.x, Internet Security and Acceleration Server (ISA) Server 2000 and later, Internet Explorer 3.01 and later

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

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

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

Page 18: Deploying DNS

130   Chapter 3   Deploying DNS

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

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

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

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

Page 19: Deploying DNS

Implementing Windows Server 2003 DNS   131

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

Table 3.5   Feature Support in Different Implementations of DNS

FeatureWindows

Server 2003

Windows 200

0

Windows NT 

4.0

BIND 9

BIND 8.2

BIND 8.1.2

BIND 4.9.7

Supports RFC 2782: A DNS RR for specifying the location of services (DNS SRV)

Dynamic update

Secure dynamic update based on the GSS-Transaction signature (TSIG) algorithm

WINS and WINS-R records

Incremental zone transfer

UTF-8 character encoding

DNS MMC snap-in

Dnscmd.exe

Active Directory–integrated zones

Storage of zones in the DNS application directory partition

Aging and scavenging of obsolete records

Stub zones

Conditional forwarding

Page 20: Deploying DNS

132   Chapter 3   Deploying DNS

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

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

An internal DNS domain name for your organization.

A DNS resource naming convention.

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

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

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

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

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

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

Page 21: Deploying DNS

Implementing Windows Server 2003 DNS   133

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

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

Table 3.6   Internet DNS Domain Name Registration

Namespace Design Domain Name Registration Example

The internal domain name is a subdomain of the external domain.

Register only the external domain name.

The domain name contoso.com is used for the external namespace.

The domain name corp.contoso.com is used for the internal namespace.

The internal and external domain names are different from each other.

Register the external domain name, and then, if you want the internal domain to be publicly accessible, also register the internal domain name.

The domain name contoso.com is used for the external namespace.

The domain name corp.contoso.com is used for the internal namespace.

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

Page 22: Deploying DNS

134   Chapter 3   Deploying DNS

Creating Internal DNS Domain NamesWhen creating names for your internal domains, use the following guidelines:

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

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

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

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

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

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

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

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

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

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

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

Page 23: Deploying DNS

Implementing Windows Server 2003 DNS   135

Creating Computer Names in a New Windows Server 2003 DNS Infrastructure

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

Select computer names that are easy for users to remember.

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

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

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

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

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

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

Creating Computer Names in an Integrated DNS Infrastructure

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

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

Page 24: Deploying DNS

136   Chapter 3   Deploying DNS

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

Creating Computer Names When Upgrading a DNS Infrastructure

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

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

Table 3.7   Character Set Restrictions

Character Set

Restriction

Standard DNS (Including

Windows NT 4.0)

DNS in Windows 2000 and Windows Server 2003 NetBIOS

Characters permitted

Supports RFC 1123, which permits A–Z, a–z, 0–9, and the hyphen (-).

Supports RFC 1123 and UTF-8. On a per-server basis, You can configure the Windows 2000 DNS Server service to allow or disallow the use of UTF-8 characters on your DNS server.

Not allowed: Unicode characters, numbers, white space, symbols: / \ [ ] : | < > + = ; , ? and *)

Maximum host name and FQDN length.

63 octets per label. 255 bytes per FQDN (254 bytes for the FQDN plus one byte for the terminating dot).

The same as standard DNS with the addition of UTF-8 support. Character count is insufficient to determine size because some UTF-8 characters exceed one octet in length. Domain controllers are limited to 155 bytes for an FQDN.

16 bytes in length.

Page 25: Deploying DNS

Implementing Windows Server 2003 DNS   137

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

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

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

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

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

Page 26: Deploying DNS

138   Chapter 3   Deploying DNS

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

Creating Subdomains

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

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

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

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

Page 27: Deploying DNS

Implementing Windows Server 2003 DNS   139

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

Page 28: Deploying DNS

140   Chapter 3   Deploying DNS

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

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

Figure 3.4   Name Resolution in the Contoso Division

Page 29: Deploying DNS

Implementing Windows Server 2003 DNS   141

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

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

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

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

External clients:

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

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

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

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

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

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

Page 30: Deploying DNS

142   Chapter 3   Deploying DNS

Figure 3.5 shows this configuration.

Figure 3.5   Conditional Forwarding in the Trey Research Division

Page 31: Deploying DNS

Implementing Windows Server 2003 DNS   143

Designing a DNS Server InfrastructureDNS servers store information about the DNS namespace and use the information to answer queries from DNS clients. The size of the DNS zone data, how many DNS clients you have, and where these clients are physically located all impact your DNS server topology.

The DNS designer in your organization designs DNS servers that enable you to create an effective DNS data distribution and update topology while minimizing query and zone transfer network traffic. The DNS administrators in your organization manage and maintain your DNS servers. Figure 3.6 shows the process for designing DNS servers.

Figure 3.6   Designing a DNS Server Infrastructure

Page 32: Deploying DNS

144   Chapter 3   Deploying DNS

Allocating Hardware ResourcesA typical recommendation for DNS server hardware includes the following:

Single-processor computers with 400 megahertz (MHz) Pentium II CPUs.

256 megabytes (MB) of RAM for each processor.

At least 4 gigabytes (GB) of available hard disk space.

A network adapter.

Using faster CPUs, more RAM, and larger hard drives improves the scalability and performance of your DNS servers. DNS servers use approximately 100 bytes of RAM for each resource record. Using this figure, you can calculate how much memory you need.

Determining the Number of Required DNS ServersTo reduce administrative overhead, use the minimum number of DNS servers required. Be sure to make at least two DNS servers authoritative for each zone to enable fault tolerance and load sharing.

Add additional DNS servers in order to:

Provide redundancy when your namespace design requires greater DNS availability.

Improve query response time when better DNS performance is required.

Reduce WAN traffic for remote locations.

Use the following guidelines to determine the number of DNS servers that you need to deploy:

If the ratio of DNS servers to clients is very low and you are experiencing significant name resolution delays, add additional DNS servers to host secondary or Active Directory–integrated zones. Use your anticipated number of queries and dynamic updates per second to determine the number of DNS servers that you need. The Windows Server 2003 DNS Server service is capable of responding to more than 10,000 queries per second on a Pentium III microprocessor running at 700 MHz.

For information about capacity planning, see “Allocating Hardware Resources” earlier in this chapter.

If you delegate zones, add additional DNS servers to handle the delegated zones. Note that you do not need to delegate zones when you have multiple zones. You can host all zones on the same server or servers. One DNS server running Windows Server 2003 can host 20,000 small zones.

If you plan to host Active Directory–integrated zones, you must place these zones on Windows 2000–based or Windows Server 2003–based domain controller.

Page 33: Deploying DNS

Implementing Windows Server 2003 DNS   145

If high-volume traffic is a consideration in your environment, add additional DNS servers to balance the workload. Although DNS helps reduce broadcast traffic between local subnets, it does create some traffic between servers and clients, particularly in complex routed environments. In addition, although the DNS service supports incremental zone transfers (IXFRs) and clients and servers can cache recently used names, traffic considerations can still remain an issue, depending on available bandwidth. This is especially true when using short Dynamic Host Configuration Protocol (DHCP) leases, which require more frequent dynamic updates.

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 the event that the primary DNS server stops responding.

If your DNS design includes primary and secondary zones and you run a large number of secondary servers for a zone, the primary DNS 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 DNS servers as primary servers for the zone. Other secondary servers can poll and request zone updates from these primary servers.

Increase the refresh interval so that the secondary servers poll less frequently. Note, however, that a longer refresh interval might cause your secondary zones to be outdated more often.

Determining DNS Server PlacementThe placement of your DNS servers and the number of DNS servers that you deploy affects the availability of DNS. It is important to ensure that you plan the placement of your DNS servers to allow for DNS availability and Active Directory availability.

Placing DNS Servers for Availability

To ensure that DNS is always available, make sure that your DNS infrastructure does not include any single points of failure. To improve fault tolerance and load sharing have clients point to a primary and alternate DNS server. In a LAN configuration, place the pair of authoritative DNS servers on separate subnets. In a WAN configuration, place the pair of authoritative DNS servers on different networks, and then ensure that at least one DNS server is available for each network. This configuration removes routers as potential points of failure. Whenever possible, distribute your DNS servers across different geographic locations to enable communications to continue in the event of a natural disaster.

If you identify single points of failure in your network, determine whether they affect only DNS or all network services. If a router goes down and your clients cannot access any network services, then DNS failure is not an issue. If a router goes down and local DNS servers are unavailable but other network services are available, then your clients cannot access required network resources because they cannot look up DNS names.

Page 34: Deploying DNS

146   Chapter 3   Deploying DNS

If you have an Internet presence, DNS must be working properly for Internet clients to access your Web servers, send mail, and locate other services; therefore, it is recommended that you run a secondary DNS server offsite. If you have a business relationship with an organization on the Internet, either business partners or ISPs, they might agree to run a secondary server for you; however, ensure that the data on the organization’s server is secured against Internet attackers.

To ensure that DNS is available if your offsite primary DNS servers are down, consider deploying a secondary DNS server offsite.

For more information about how to place DNS servers to maximize Active Directory availability, see “Designing the Active Directory Logical Structure” in Designing and Deploying Directory and Security Services of this kit.

Using ForwardingIf a DNS server does not have the data to resolve a query in its cache or in its zone data, it forwards the query to another DNS server, known as 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.

Use forwarding for off-site or Internet traffic. For example, a branch office DNS server can forward all off-site traffic to a forwarder at the company headquarters, and an internal DNS server can forward all Internet traffic to a forwarder on the external network. To ensure fault tolerance, forward queries to more than one forwarder.

Forwarders can increase network security by minimizing the list of DNS servers that communicate across a firewall.

You can use conditional forwarding to more precisely control the name resolution process. Conditional forwarding enables you to designate specific forwarders for specific DNS names. You can use conditional forwarding to resolve the following:

Queries for names in off-site internal domains

Queries for names in other namespaces

Using Conditional Forwarding to Query for Names in Off-Site Internal Domains

In Windows Server 2003 DNS, non-root servers resolve names for which they are not authoritative, do not have a delegation, and do not have in their cache by doing one of the following:

Querying a root server.

Forwarding queries to a forwarder.

Both of these methods 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 must resolve a name in a zone hosted by a server in Site C. Because the non-root server 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.

Page 35: Deploying DNS

Implementing Windows Server 2003 DNS   147

When you use conditional forwarding, you can 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, the server in Site A can forward queries to forwarders in Site B or Site C, as appropriate.

For example, the computers in the Seville site need to query computers in the Hong Kong site. Both sites use a common DNS root server, DNS3.corp.fabrikam.com, located in Seville.

Before the Contoso Corporation upgraded to Windows Server 2003, the server in Seville forwarded all queries that it could not resolve to its parent server, DNS1.corp.contoso.com, in Seattle. When the server in Seville queried for names in the Hong Kong site, the server in Seville first forwarded those queries to Seattle.

After upgrading to Windows Server 2003, administrators configured the DNS server in Seville to forward queries destined for the Hong Kong site directly to a server in that site, instead of first detouring to Seattle, as shown in Figure 3.7.

Figure 3.7   Conditional Forwarding to an Off-Site Server

Administrators configured DNS3.corp.fabrikam.com to forward any queries for corp.treyresearch.com to DNS5.corp.treyresearch.com or DNS6.corp.treyresearch.com. DNS3.corp.fabrikam.com forwards all other queries to DNS1.corp.contoso.com or DNS2.corp.contoso.com.

For more information about conditional forwarding in Windows Server 2003 DNS, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Page 36: Deploying DNS

148   Chapter 3   Deploying DNS

Using Conditional Forwarding to Query for Names in 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, use conditional forwarding to enable servers to query for names in other namespaces. Conditional forwarding in Windows Server 2003 DNS eliminates the need for secondary zones by configuring DNS servers to forward queries to different servers based on the domain name.

For example, the Contoso Corporation includes two namespaces: Contoso and Trey Research. Computers in each division need access to the other namespace. In addition, computers in both divisions need access to computers in the Supplier private namespace.

Before upgrading to Windows Server 2003, the Trey Research division created secondary zones to ensure that computers in both the Contoso and Trey Research namespace can resolve names in the Contoso, Trey Research, and Supplier namespaces. After upgrading to Windows Server 2003, the Trey Research division deleted its secondary zones and configured conditional forwarding instead.

Upgrading DNS Servers to Windows Server 2003 DNSThe procedure you need to follow to upgrade DNS servers to Windows Server 2003 depends on whether you want to support Active Directory or not. If you are upgrading to Windows Server 2003 DNS and might not support Active Directory, for information about upgrading your existing DNS servers or migrating third-party DNS servers, see “Migrating servers” in Help and Support Center for Windows Server 2003. Migration involves the following:

Plan your migration schedule to ensure that your DNS clients have access to a DNS server at all times.

Back up your existing configuration.

Migrate data from existing DNS servers to Windows Server 2003 DNS.

If you are upgrading your DNS servers to support Active Directory, see “Designing the Active Directory Logical Structure” in Designing and Deploying Directory and Security Services of this kit.

After you have upgraded or migrated your servers, test them to ensure that they are resolving correctly. For more information about DNS troubleshooting and testing DNS server performance, see “Monitor servers” in Help and Support Center for Windows Server 2003, and the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Page 37: Deploying DNS

Implementing Windows Server 2003 DNS   149

Designing DNS ZonesEach zone type that is available in Windows Server 2003 DNS has a specific purpose. The DNS designer in your organization selects the type of zones to deploy based on the practical purpose of each zone. The DNS administrators in your organization manage and maintain your DNS zones. Figure 3.8 shows the process for designing DNS zones.

Figure 3.8   Designing DNS Zones

Page 38: Deploying DNS

150   Chapter 3   Deploying DNS

Choosing a Zone TypeDesign zones to correspond to your network administration infrastructure. If a site in your network is administered locally, deploy a zone for the subdomain. If a department has a subdomain, but no administrator, keep the subdomain in the parent zone. Decide whether or not to store your zones in Active Directory. Active Directory distributes data using a multimaster replication model that provides more security than standard DNS. With the exception of secondary zones, you can store all zone types in Active Directory because all other zones are considered primary zones. When designing DNS zones, host each zone on more than one DNS server.

Decide which type of zone to use, based on your domain structure. For each zone type, with the exception of secondary zones, decide whether to deploy file-based zones or Active Directory–integrated zones.

Primary Zones

Deploy primary zones that correspond to your planned DNS domain names. You cannot store both an Active Directory–integrated and a file-based primary copy of the same zone on the same DNS server.

Secondary Zones

Add secondary zones if you do not have an Active Directory infrastructure. If you do have an Active Directory infrastructure, use secondary zones on DNS servers that are not serving as domain controllers. A secondary zone contains a complete copy of a zone. Therefore, use secondary zones to improve zone availability at remote sites if you do not want zone data propagated across a WAN link by means of Active Directory replication.

Stub Zones

A stub zone is a copy of a zone that contains only the original zone’s start of authority (SOA) resource record, the name server (NS) resource records listing the authoritative servers for the zone, and the glue address (A) resource records that are needed to identify these authoritative servers.

A DNS server that is hosting a stub zone is configured with the IP address of the authoritative server from which it loads. DNS servers can use stub zones for both iterative and recursive queries. When a DNS server hosting a stub zone receives a recursive query for a computer name in the zone to which the stub zone refers, the DNS server uses the IP address to query the authoritative server, or, if the query is iterative, returns a referral to the DNS servers listed in the stub zone.

Stub zones are updated at regular intervals, determined by the refresh interval of the SOA resource record for the stub zone. When a DNS server loads a stub zone, it queries the zone’s primary servers for SOA resource records, NS resource records at the zone’s root, and glue address (A) resource records. The DNS server attempts to update its resource records at the end of the SOA resource record’s refresh interval. To update its records, the DNS server queries the primary servers for the resource records listed earlier.

Page 39: Deploying DNS

Implementing Windows Server 2003 DNS   151

You can use stub zones to ensure that the DNS server that is authoritative for a parent zone automatically receives updates about the DNS servers that are authoritative for a child zone. To do this, add the stub zone to the server that is hosting the parent zone. Stub zones can be either file-based or Active Directory–integrated. If you use Active Directory–integrated stub zones, you can configure them on one computer and let Active Directory replication propagate them to other DNS servers running on domain controllers.

Although conditional forwarding is the recommended method for making your servers aware of other namespaces, you can also use stub zones for this. For more information about using stub zones, see Help and Support Center for Windows Server 2003.

Stub Zones and Conditional Forwarding

Stub zones and conditional forwarding are Windows Server 2003 DNS features that enable you to control the routing of DNS traffic over a network. These features enable a DNS server to respond to a query by doing one of the following:

Providing a referral to another DNS server.

Forwarding the query to another DNS server.

A stub zone enables a DNS server that is hosting a parent zone to be aware of the names and IP addresses of DNS servers that are authoritative for a child zone, even if the DNS server does not have a complete copy of the child zone. In addition, when a stub zone is used, the DNS server does not have to send queries to the DNS root servers. If the stub zone for a child zone is hosted on the same DNS server as the parent zone, the DNS server that is hosting the stub zone receives a list of all new authoritative DNS servers for the child zone when it requests an update from the stub zone’s primary server. In this way, the DNS server that is hosting the parent zone maintains a current list of the authoritative DNS servers for the child zone as the authoritative DNS servers are added and removed.

Use conditional forwarding if you want DNS servers in one network to perform name resolution for DNS clients in another network. You can configure DNS servers in separate networks to forward queries to each other without querying DNS servers on the Internet. If DNS servers in separate networks forward DNS client names to each other, the DNS servers cache this information. This enables you to create a direct point of contact between DNS servers in each network and reduces the need for recursion.

If you are using a stub zone and you have a firewall between DNS servers in the networks, then DNS servers on the query/resolution path must have port 53 open. However, if you are using conditional forwarding and you have a firewall between DNS servers in each of the networks, the requirement to have port 53 open only applies to the two DNS servers on either side of the firewall.

NoteOnly DNS servers running Windows Server 2003 and BIND 9 support stub zones.

Page 40: Deploying DNS

152   Chapter 3   Deploying DNS

Active Directory–Integrated Zones

If your DNS topology includes Active Directory, use Active Directory–integrated zones. Active Directory–integrated zones enable you to store zone data in the Active Directory database. Zone information on any primary DNS server within an Active Directory–integrated zone is always replicated.

Because DNS replication is single-master, a primary DNS server in a standard primary DNS zone can be a single point of failure. In an Active Directory–integrated zone, a primary DNS server cannot be a single point of failure because Active Directory uses multimaster replication. Updates that are made to any domain controller are replicated to all domain controllers and the zone information on any primary DNS server within an Active Directory–integrated zone is always replicated. Active Directory–integrated zones:

Enable you to secure zones by using secure dynamic update.

Provide increased fault tolerance. Every Active Directory–integrated zone can be replicated to all domain controllers within the Active Directory domain or forest. All DNS servers running on these domain controllers can act as primary servers for the zone and accept dynamic updates.

Enable replication that propagates changed data only, compresses replicated data, and reduces network traffic.

If you have an Active Directory infrastructure, you can only use Active Directory–integrated zones on Active Directory domain controllers. If you are using Active Directory–integrated zones, you must decide whether or not to store Active Directory–integrated zones in the application directory partition.

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.

Storing Active Directory–Integrated Zones in Application Directory Partitions

Windows Server 2003 Active Directory enables you to configure an application directory partition that limits the scope of replication. Data stored in an application directory partition is replicated to a subset of domain controllers. This subset is determined by the replication scope of the data. In the default configuration of Windows Server 2003 Active Directory, DNS application directory partitions are present only on the domain controllers that run the DNS Server service. By storing Active Directory–integrated zones in an application directory partition, you can reduce the number of objects that are stored in the global catalog, and you can reduce the amount of replication traffic within a domain.

Page 41: Deploying DNS

Implementing Windows Server 2003 DNS   153

In contrast, Active Directory–integrated zones that are stored in domain directory partitions are replicated to all domain controllers in the domain. Storing Active Directory–integrated zones in an application directory partition allows replication of DNS data to domain controllers anywhere in the same Active Directory forest.

When you are setting up your Active Directory environment and installing the first Windows Server 2003 domain controller in the forest, if you install DNS, two Windows Server 2003 DNS application directory partitions are created by default. A forest-wide DNS application directory partition called ForestDNSZones will be created, and for each domain in the forest, a domain-wide DNS application directory partition called DomainDNS Zones will be created.

Choosing a Propagation MethodAfter you decide which zone each DNS server hosts, decide how to propagate the zones among the servers. Propagated zones provide higher availability, improve query response time, and reduce network traffic produced by name queries. However, propagated zones require storage space and increase network traffic. If your network is distributed and managed at different sites, use subdomains for these sites. If you do not have a distributed network, avoid using subdomains when possible.

In Windows Server 2003, zones are propagated by means of file-based zone transfer or Active Directory replication. If you use file-based zones, file-based zone transfer is the method of propagation. If you have Windows Server 2003 and Windows 2000 Active Directory–integrated zones, use Active Directory replication.

File-Based Zone Transfer

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 third-party DNS server that is involved in the transfer, DNS servers running Windows Server 2003 and Windows 2000 transfer the full zone.

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

Windows Server 2003 DNS uses full zone transfer when zones must be transferred to DNS servers that do not support incremental zone transfer, such as DNS servers running on Windows NT 4.0 or earlier versions of BIND 8.

Active Directory Replication

Active Directory replication propagates zone changes between domain controllers. Replication processing differs from DNS full zone transfers, in which the DNS server transfers the entire zone. Replication processing also differs from incremental zone transfers, in which the server transfers all changes made since the last change.

Page 42: Deploying DNS

154   Chapter 3   Deploying DNS

Active Directory zone replication provides the following additional benefits:

Network traffic is reduced because the domain controllers only send the final result of all changes.

When a zone is stored in Active Directory, replication occurs automatically. No additional configuration is required.

When Active Directory zone replication occurs between sites, zone data that is greater than the default transfer size is automatically compressed before it is transferred. This compression decreases the network traffic load.

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.

If you are using Active Directory–integrated zones in a Windows Server 2003 domain, you must select an Active Directory–integrated zone replication scope. When selecting a replication scope, note that network traffic increases as you broaden the replication scope. For example, if you choose to replicate Active Directory–integrated DNS zone data to all DNS servers in the forest, this produces greater network traffic than replicating the DNS zone data to all DNS servers in a single Active Directory domain in that forest. Balance your need to minimize replication traffic against your need to minimize zone query traffic. The DNS administrators in your organization are responsible for managing zone replication.

Table 3.8 lists the replication options for Active Directory–integrated zone data.

Table 3.8   Replication Options for Active Directory–Integrated Zone Data

Option Description When to Use

All DNS servers in the Active Directory forest

The zone data replicates to all the DNS servers running on Windows Server 2003–based  domain controllers in all domains of the Active Directory forest.

You want the broadest scope of replication. This option generally produces the most zone replication traffic. Note that you can choose this option only if all DNS servers hosting an Active Directory–integrated copy of this zone run Windows Server 2003.

All DNS servers in a specified Active Directory domain

The zone data replicates to all DNS servers running on Windows Server 2003–based  domain controllers in the specified Active Directory domain. This option is the default setting for Active Directory–integrated DNS zone replication.

(The specified Active Directory domain is the domain hosted by the domain controller on which

You do not need the zone to be replicated throughout the forest and you want to limit zone replication traffic. This option produces less zone replication traffic than replicating the zone to all DNS servers in the forest or to all domain controllers in the domain. If you choose this option, the zone data does not replicate to DNS servers running on Windows 2000–based domain controllers.

Page 43: Deploying DNS

Implementing Windows Server 2003 DNS   155

the DNS server hosting the zone is running.)

(continued)

Page 44: Deploying DNS

156   Chapter 3   Deploying DNS

Table 3.8   Replication Options for Active Directory–Integrated Zone Data (continued)

Option Description When to Use

All domain controllers in the Active Directory domain

The zone data replicates to all domain controllers in the specified Active Directory domain, whether or not the DNS Server service runs on the domain controllers in the domain.

You host an Active Directory–integrated copy of this zone on a DNS server running on a Windows 2000–based domain controller.

All domain controllers specified in the replication scope of a DNS application directory partition

The zone data replicates to all the domain controllers specified in the replication scope of the DNS application directory partition.

You want to customize zone replication scope for your organization. With this option, you can minimize zone replication traffic while maximizing functionality. However, this option requires more administrative overhead. You can choose this option only if all DNS servers hosting an Active Directory–integrated copy of this zone run Windows Server 2003.

Migrating Zones to Windows Server 2003 DNS ServersYou can migrate zones to DNS servers running Windows Server 2003 in one of two ways:

By using zone transfer.

By copying the zone files.

If you copy the zone files, you must manually verify the integrity of the zones. Regardless of the method that you use to migrate zones, you must decide whether to take the original DNS server offline, or to use it as a secondary server. If you determine that the original third-party DNS server causes interoperability problems on your network, or if you need to use that server hardware for another purpose, take the server offline. Otherwise, keep the server on you network to provide backup for your primary DNS server running Windows Server 2003.

For more information about using zone transfer, see “Initiate a zone transfer at a secondary server” in Help and Support Center for Windows Server 2003.

Page 45: Deploying DNS

Implementing Windows Server 2003 DNS   157

Configuring and Managing DNS ClientsWhen you configure DNS clients, you must specify a list of DNS servers for clients to use when resolving DNS names. You can also specify a DNS suffix search list to be used by the clients when performing DNS query searches for short, unqualified domain names.

Figure 3.9 shows the process for configuring and managing DNS clients.

Figure 3.9   Configuring and Managing DNS Clients

Page 46: Deploying DNS

158   Chapter 3   Deploying DNS

Configuring Client DNS Server Lists and Suffix Search ListsConfigure your clients’ DNS server lists and suffix search list 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 running in the local site for the preferred server. The alternate server can be running in either a local or a remote site.

The DNS suffix search list is populated based on the primary DNS suffix of the client and any connection-specific DNS suffixes. The client uses these suffixes to try to resolve unqualified names. You can modify the DNS suffix search list manually, or by using Group Policy. Limit the size of your suffix search list if you can, because a large suffix search list increases network traffic.

Using Group Policy to Simplify Client ConfigurationWindows Server 2003 includes a new set of Group Policy settings to simplify the rollout of Windows Server 2003 DNS clients. You can use them to set your suffix search lists, dynamic update configuration, and many other settings. As with all Group Policy settings, you can specify different settings based on site, domain, or OU.

For more information about these Group Policy settings, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Securing Your DNS InfrastructureBecause DNS was designed to be an open protocol, DNS data can be vulnerable to security attacks. Windows Server 2003 DNS provides improved security features to decrease this vulnerability. The DNS designer in your organization is responsible for creating a secure DNS infrastructure. The DNS administrators in your organization are responsible for maintaining network security by anticipating and mitigating new security threats.

Page 47: Deploying DNS

Implementing Windows Server 2003 DNS   159

Figure 3.10 shows the process for securing your DNS infrastructure.

Figure 3.10   Securing Your DNS Infrastructure

Page 48: Deploying DNS

160   Chapter 3   Deploying DNS

Identifying DNS Security ThreatsA DNS infrastructure is vulnerable to a number of types of security threats.

The process of building a diagram, or footprint, of a DNS infrastructure by capturing DNS zone data such as domain names, computer names, and IP addresses for sensitive network resources. DNS domain and computer names often indicate the function or location of domains and computers.

An attack in which the attacker attempts to deny the availability of network services by flooding one or more DNS servers in the network with recursive queries. When a DNS server is flooded with queries, its CPU usage eventually reaches its maximum and the DNS Server service becomes unavailable. Without a fully operating DNS server on the network, network services that use DNS are unavailable to network users.

The use of valid IP addresses in IP packets that an attacker has created to destroy data or conduct other attacks. Data modification is typically attempted on a DNS infrastructure that has already been foot printed. If the attack is successful, the packets appear to be coming from a valid IP address on the network. This is commonly called IP spoofing. With a valid IP address (an IP address within the IP address range of a subnet), an attacker can gain access to the network.

An attack in which an attacker is able to redirect queries for DNS names to servers that are under the control of the attacker. One method of redirection involves the attempt to pollute the DNS cache of a DNS server with erroneous DNS data that might direct future queries to servers that are under the control of an attacker. For example, if a query is made to example.contoso.com and a referral answer provides a record for a name that is outside of the contoso.com domain, the DNS server uses the cached data to resolve a query for the external name. Redirection can be accomplished when an attacker has writable access to DNS data, such as with non-secure dynamic updates.

For more information about common types of attacks, developing a security policy, and evaluating your level of risk, see “Designing an Authentication Strategy” and “Designing a Resource Authorization Strategy” in Designing and Deploying Directory and Security Services of this kit.

FootprintinDenial-of-service attackData modificatioRedirectio

Page 49: Deploying DNS

Implementing Windows Server 2003 DNS   161

Developing a DNS Security PolicyIf your DNS data is compromised, attackers can gain information about your network that can be used to compromise other services. For example, attackers can harm your organization in the following ways:

By using zone transfer, attackers can retrieve a list of all the hosts and their IP addresses in your network.

By using denial-of-service attacks, attackers can prevent e-mail from being delivered to and from your network, and they can prevent your Web server from being visible.

If attackers can change your zone data, they can set up fake Web servers, or cause e-mail to be redirected to their servers.

Your risk of attack varies depending on your exposure to the Internet. For a DNS server in a private network that uses a private namespace, a private addressing scheme, and an effective firewall, the risk of attack is lower and the possibility of discovering the intruder is greater. For a DNS server that is exposed to the Internet, the risk is higher.

Developing a DNS security policy involves:

Deciding what access your clients need, what tradeoffs you want to make between security and performance, and what data you most want to protect.

Familiarizing yourself with the security issues common to internal and external DNS servers.

Studying your name resolution traffic to see which clients can query which servers.

You can choose to adopt a low-level, mid-level, or high-level DNS security policy.

Low-Level DNS Security Policy

Low-level security does not require any additional configuration of your DNS deployment. Use this level of DNS security in a network environment in which you are not concerned about the integrity of your DNS data, or in a private network in which no external connectivity is possible. A low-level security policy includes the following characteristics:

All DNS servers in your network perform standard DNS resolution.

All DNS servers are configured with root hints that point to the root servers for the Internet.

All DNS servers permit zone transfers to any server.

All DNS servers are configured to listen on all of their IP addresses.

Secure cache against pollution is disabled on all DNS servers.

Dynamic update is allowed for all DNS zones.

User Datagram Protocol (UDP) and TCP/IP port 53 is open on the firewall for your network for both source and destination addresses.

Page 50: Deploying DNS

162   Chapter 3   Deploying DNS

Mid-Level DNS Security Policy

Mid-level DNS security consists of the DNS security features that are available without running DNS servers on domain controllers and storing DNS zones in Active Directory. A mid-level security policy includes the following characteristics:

The DNS infrastructure of your organization has limited exposure to the Internet.

All DNS servers are configured to use forwarders to point to a specific list of internal DNS servers when they cannot resolve names locally.

All DNS servers limit zone transfers to servers listed in the NS records in their zones.

DNS servers are configured to listen on specified IP addresses.

Secure cache against pollution is enabled on all DNS servers.

Secure dynamic update is allowed for all DNS zones.

Internal DNS servers communicate with external DNS servers through the firewall with a limited list of allowed source and destination addresses.

External DNS servers in front of your firewall are configured with root hints pointing to the root servers for the Internet.

All Internet name resolution is performed by using proxy servers and gateways.

High-Level DNS Security Policy

High-level DNS security uses the same configuration as mid-level security and also uses the security features available when the DNS Server service is running on a domain controller and DNS zones are stored in Active Directory. Also, high-level security completely eliminates DNS communication with the Internet. This is not a typical configuration, but it is recommended whenever Internet connectivity is not required. High-level security policy includes the following characteristics:

The DNS infrastructure of your organization has no Internet communication by means of internal DNS servers.

Your network uses an internal DNS root and namespace, where all authority for DNS zones is internal.

DNS servers that are configured with forwarders use internal DNS server IP addresses only.

All DNS servers limit zone transfers to specified IP addresses.

DNS servers are configured to listen on specified IP addresses.

Secure cache against pollution is enabled on all DNS servers.

Internal DNS servers are configured with root hints that point to the internal DNS servers hosting the root zone for your internal namespace.

Page 51: Deploying DNS

Implementing Windows Server 2003 DNS   163

Secure dynamic update is configured for all DNS zones except for the top-level and root zones, which do not allow dynamic updates at all.

All DNS servers are running on domain controllers. An access control list (ACL) is configured on the DNS Server service to allow only specific individuals to perform administrative tasks on DNS servers.

All DNS zones are stored in Active Directory. An ACL is configured to allow only specific individuals to create, delete, or modify DNS zones.

ACLs are configured on DNS resource records to allow only specific individuals to create, delete, or modify DNS data.

Cache Pollution Protection

When cache pollution protection is enabled, the DNS server disregards DNS resource records that originate from DNS servers that are not authoritative for the resource records. Cache pollution protection is a significant security enhancement; however, when cache pollution protection is enabled, the number of DNS queries can increase.

In Windows Server 2003 DNS, cache pollution protection is enabled by default. You can disable cache pollution protection to reduce the number of DNS queries; however, to ensure the security of your system, it is strongly recommended that you leave cache pollution protection enabled on your DNS servers.

For information about cache pollution protection, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Securing DNS Servers That Are Exposed to the InternetDNS servers that are exposed to the Internet are especially vulnerable to attack. You can secure your DNS servers that are exposed to the Internet by doing the following:

Place the DNS server on a perimeter network instead of your internal network.

For more information about perimeter networks, see “Deploying ISA Server” in this book.

NoteWindows Server 2003 DNS does not support the use of DACLs on zones to control which clients or users can send queries to the DNS server.

Page 52: Deploying DNS

164   Chapter 3   Deploying DNS

Use one DNS server for publicly accessed services inside your perimeter network and a separate DNS server for your private internal network. This reduces the risk of exposing your private namespace, which can expose sensitive names and IP addresses to Internet-based users. It also increases performance because it decreases the number of resource records on the DNS server.

Add a secondary server on another subnet or network, or on an ISP. This protects you against denial-of-service attacks.

Eliminate single points of failure by securing your routers and DNS servers, and distributing your DNS servers geographically. Add secondary copies of your zones to at least one offsite DNS server.

Encrypt zone replication traffic by using Internet Protocol security (IPSec) or virtual private network (VPN) tunnels to hide the names and IP addresses from Internet-based users.

Configure firewalls to enforce packet filtering for UDP and TCP port 53.

Restrict the list of DNS servers that are allowed to initiate a zone transfer on the DNS server. Do this for each zone in your network.

Monitor the DNS logs and monitor your external DNS servers by using Event Viewer.

Securing Internal DNS ServersInternal DNS servers are less vulnerable to attack than external DNS servers, but you still need to protect them. To secure your internal DNS servers:

Eliminate any single point of failure. Note, however, that DNS redundancy cannot help you if your clients cannot access any network services. Think about where the clients of each DNS zone are located, and how they resolve names if the DNS server is compromised and unable to answer queries.

Prevent unauthorized access to your servers. Allow only secure dynamic update for your zones and limit the list of DNS servers that are allowed to obtain a zone transfer.

Monitor the DNS logs and monitor your internal DNS servers by using Event Viewer. Monitoring your logs and your server can help you detect unauthorized modifications to your DNS server or zone files.

Implement Active Directory–integrated zones with secure dynamic update.

Page 53: Deploying DNS

Implementing Windows Server 2003 DNS   165

Securing Dynamically Updated DNS ZonesUse Active Directory–integrated zones and configure them for secure dynamic update. Secure dynamic update resolves the security risks associated with using dynamic update. Because dynamic update allows any computer to modify any record, an attacker can modify zone data, then impersonate existing servers.

For example, if you install the Web server, web.contoso.com, and it registers its IP address in DNS by using dynamic update, an attacker can install a second Web server, also name it web.contoso.com, and use dynamic update to modify the corresponding IP address in the DNS record. In this way, the attacker can impersonate the original Web server and capture secure information.

To prevent server impersonation, implement secure dynamic update. By using secure dynamic update, only the computers and users specified in an access control list (ACL) can modify objects within a zone.

If your security policy demands stricter security, modify these settings to further restrict access. Restrict access by computer, group, or user account, and assign permissions for the entire DNS zone and for the individual DNS names within the zone.

For more information about securing dynamically updated DNS zones, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Securing DNS Zone ReplicationZone replication can occur either by means of zone transfer or as part of Active Directory replication. If you do not secure zone replication, you run the risk of exposing the names and IP addresses of your computers to attackers. You can secure DNS zone replication by doing the following:

Using Active Directory replication.

Encrypting zone replication sent over public networks such as the Internet.

Restricting zone transfer to authorized servers.

Page 54: Deploying DNS

166   Chapter 3   Deploying DNS

Using Active Directory Replication

Replicating zones as part of Active Directory replication provides the following security benefits:

Active Directory replication traffic is encrypted; therefore zone replication traffic is encrypted automatically.

The Active Directory domain controllers that perform replication are mutually authenticated, and impersonation is not possible.

Encrypting Replication Traffic Sent Over Public Networks

Encrypt all replication traffic sent over public networks by using IPSec or VPN tunnels. When encrypting replication traffic sent over public networks:

Use the strongest level of encryption or VPN tunnel authentication that your servers can support.

Use the Windows Server 2003 Routing and Remote Access service to create the IPSec or VPN tunnel.

Restricting Zone Transfer to Authorized Servers

If you have secondary servers and you replicate your zone data by using zone transfer, configure your DNS servers to specify the secondary servers that are authorized to receive zone transfers. This prevents an attacker from using zone transfer to download zone data. If you are using Active Directory–integrated zones instead, configure your servers to disallow zone transfer.

NoteUse Active Directory–integrated zones whenever possible, because they are replicated as part of Active Directory replication, which is more secure than file-based zone transfer.

Page 55: Deploying DNS

Implementing Windows Server 2003 DNS   167

Integrating DNS with Other Windows Server 2003 ServicesWhen you deploy Windows Server 2003 DNS, it is important to integrate the DNS service with other Windows Server 2003 services, such as DHCP and WINS. DNS administrators are responsible for integrating DNS with WINS and DHCP. Figure 3.11 shows the process for integrating Windows Server 2003 DNS with other Windows Server 2003 services.

Figure 3.11   Integrating DNS with Other Windows Server 2003 Services

Page 56: Deploying DNS

168   Chapter 3   Deploying DNS

Integrating DNS with DHCPWindows Server 2003 DNS supports DHCP by means of the dynamic update of DNS zones. By integrating DHCP and DNS in a DNS deployment, you can provide your network resources with dynamic addressing information stored in DNS. To enable this integration, you can use the Windows Server 2003 DHCP service.

The dynamic update standard, specified in RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE), automatically updates DNS records. Both Windows Server 2003 and Windows 2000 support dynamic update, and both clients and DHCP servers can send dynamic updates when their IP addresses change.

Dynamic update enables a DHCP server to register address (A) and pointer (PTR) resource records on behalf of a DHCP client by using DHCP Client FQDN option 81. Option 81 enables the DHCP client to provide its FQDN to the DHCP server. The DHCP client also provides instructions to the DHCP server describing how to process DNS dynamic updates on behalf of the DHCP client.

The DHCP server can dynamically update DNS A and PTR records on behalf of DHCP clients that are not capable of sending option 81 to the DHCP server. You can also configure the DHCP server to discard client A and PTR records when the DHCP client lease is deleted. This reduces the time needed to manage these records manually and provides support for DHCP clients that cannot perform dynamic updates. In addition, dynamic update simplifies the setup of Active Directory by enabling domain controllers to dynamically register SRV resource records.

If the DHCP server is configured to perform DNS dynamic updates, it performs one of the following actions:

The DHCP server updates resource records at the request of the client. The client requests the DHCP server to update the DNS PTR record on behalf of the client, and the client registers A.

The DHCP server updates DNS A and PTR records regardless of whether the client requests this action or not.

By itself, dynamic update is not secure because any client can modify DNS records. To secure dynamic updates, you can use the secure dynamic update feature provided in Windows Server 2003. To delete outdated records, you can use the DNS server aging and scavenging feature.

Page 57: Deploying DNS

Implementing Windows Server 2003 DNS   169

Integrating DNS with WINSWhen you upgrade to Windows Server 2003 DNS from an earlier version of Windows, you might need to continue support an existing WINS infrastructure. Windows Server 2003 DNS enables you to support an existing WINS deployment by allowing you to configure a DNS server to query a WINS server as a DNS zone setting.

WINS provides dynamic NetBIOS name resolution. If your organization supports clients and applications that use WINS for NetBIOS name resolution, you need to continue to support WINS. If some of your clients are registered in WINS and other clients need to resolve their names but are not capable of NetBIOS name resolution, you can use WINS lookup to enable your DNS server to look up names in the WINS namespace.

This feature is particularly useful if some of your clients that require NetBIOS name resolution cannot use WINS or if some of your clients cannot register with DNS (for example, clients that run the Microsoft® Windows® 95 or Windows® 98 operating system). Use WINS referral if some of your DNS servers do not support the resource records used for WINS lookup and WINS reverse lookup.

WINS Lookup and WINS Reverse Lookup

By configuring your DNS server for WINS lookup, you can direct DNS to query WINS for name resolution, so that DNS clients can look up the names and IP addresses of WINS clients. To direct DNS to query WINS for name resolution, add a WINS lookup record to the authoritative zone. An authoritative DNS server checks that zone when it receives a query for a name. If the DNS server does not find the name in the authoritative zone, but the zone contains a WINS lookup record, the DNS server queries the WINS server. If the name is registered with WINS, the WINS server returns the associated record to the DNS server.

The DNS server then compiles and returns the corresponding DNS record in response to the original DNS request. DNS clients do not need to know whether a client is registered with WINS or DNS, and they do not need to query the WINS server.

You can also configure your DNS server for WINS reverse lookups. Reverse lookups work slightly differently. When an authoritative DNS server is queried for a nonexistent PTR record, and the authoritative zone contains the WINS-R record, the DNS server uses a NetBIOS node adapter status lookup.

Page 58: Deploying DNS

170   Chapter 3   Deploying DNS

Configuring WINS Referral

Computers that are running third-party implementations of DNS do not support the records used for WINS lookup and WINS reverse lookup. If you attempt to use a combination of Microsoft and third-party DNS servers to host a zone containing these records, the mixture can cause data errors or failed zone transfers at the third-party DNS servers.

If you have such a combination, you can use WINS referral to create and delegate a special WINS zone that refers DNS lookups to WINS. This zone does not perform any registrations or updates. Next, you configure all DNS clients to append the WINS referral zone name to unqualified queries. That way, the client can query both DNS and WINS at the same time, using a DNS query. To simplify administration, you can use DHCP or Group Policy to configure the clients to perform the configuration. Deploying this configuration overrides the default DNS client resolver behavior, requiring you to finish populating the suffix search order with combinations of suffixes, such as the primary DNS suffix, the primary DNS suffix devolved, and connection specific suffixes.

For more information about DHCP, see “Deploying DHCP” in this book. For more information about Group Policy, see “Designing a Group Policy Infrastructure” in Designing a Managed Environment of this kit.

NoteFor fault tolerance, you can specify multiple WINS servers in the WINS lookup record. The server that is running the Windows 2000 or Windows Server 2003 DNS Server service tries to locate the name by searching the WINS servers in the order specified by the list.

Page 59: Deploying DNS

Implementing Windows Server 2003 DNS   171

Implementing Windows Server 2003 DNSAfter you have tested your configuration in a pilot lab, you can implement your changes in your production environment. Figure 3.12 shows the process for implementing Windows Server 2003 DNS.

Figure 3.12   Implementing Windows Server 2003 DNS

NoteThe WINS zone must be hosted on a DNS server that is running Windows Server 2003 or Windows 2000 and must not be propagated to third-party DNS servers. Third-party DNS servers do not support WINS resource records and might not be able to host the zone.

Page 60: Deploying DNS

172   Chapter 3   Deploying DNS

Page 61: Deploying DNS

Implementing Windows Server 2003 DNS   173

Preparing to Deploy Windows Server 2003 DNSPrepare your environment for Windows Server 2003 DNS deployment by ensuring that you have reliable backups of anything that you plan to change, including servers and zones. Test your backups before you proceed with your deployment. In addition, create a recovery plan for contingencies such as data loss, server failure, and failure of network connections.

Before implementing your DNS deployment, ensure that routing links between the servers that you plan to deploy are in place and are working correctly. Depending on how your DNS infrastructure is configured, your DNS servers might need to query the following:

Root servers.

Forwarders.

Servers hosting parent zones.

Servers hosting child zones.

Servers on an external network or the Internet.

If you expect clients to query for names on the Internet and you plan to use a proxy server, ensure that the proxy server is in place and that a proxy-client/firewall-client is installed on the client. In addition, ensure that the Web client configuration is set in a Conseil Européen pour la Recherche Nucléaire (CERN)–compliant Internet browser. Microsoft Internet Explorer is an example of a CERN–compliant Internet browser.

Setting up the DNS ServerBefore you install DNS, ensure that your computer is named correctly and that you can ping other computers in the network that your DNS servers might need to query. Because clients locate DNS servers by IP address, assign a static IP address to each DNS server.

You can set up your DNS server in one of four ways:

Install DNS on a server by using the Active Directory Installation Wizard to install Active Directory.

The Active Directory Installation Wizard automatically creates an Active Directory–integrated copy of the forward lookup zone that corresponds to the name of the Active Directory domain, and configures the zone for secure dynamic update. In addition, the wizard creates the standard reverse lookup zones recommended by the DNS RFCs.

You can start the Active Directory Installation Wizard by running dcpromo.exe at a command prompt. For more information about Active Directory installation and removal, see the Directory Services Guide of the Windows Server 2003 Resource Kit (or see the Directory Services Guideon the Web at http://www.microsoft.com/reskit).

Page 62: Deploying DNS

174   Chapter 3   Deploying DNS

Before or after you install Active Directory on the server, you can use the Add or Remove Programs tool to install the DNS Server service and then run the Configure DNS Server Wizard to configure your zones. As with the Active Directory Installation Wizard, the Configure DNS Server Wizard creates the standard reverse lookup zones recommended by the DNS RFCs, and either configures the server as a root server or initializes the root hints.

You can use the command-line tool Dnscmd.exe to configure the DNS server.

You can use Microsoft® Visual Basic® Scripting Edition (VBScript) or other scripting languages through the Windows Management Instrumentation (WMI) provider packaged with Windows Server 2003.

For more information about these setup options and for information about Windows Server 2003 DNS, including how the Active Directory Installation Wizard and the Configure DNS Server Wizard determine whether or not to initialize the root hints, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at www.microsoft.com/reskit).

Setting up ZonesIf you install DNS by using the Active Directory Installation Wizard, the wizard creates DNS zones that correspond to the Active Directory domains that you specify. If the zones that you specified during the zone planning phase of your deployment do not already exist, create them now. Note that the default DNS installation by the Active Directory Installation Wizard includes secure dynamic update and an Active Directory–integrated zone. If this is not the configuration you want to deploy, change the default settings.

If the zone that the wizard creates is not the type of zone that you want, change it now.

If you want to push updates to secondary DNS servers for a zone, configure DNS notify at the primary DNS server.

For more information about how to add and remove zones, see Help and Support Center for Windows Server 2003.

NoteConverting any zone to an Active Directory–integrated zone can increase the use of DNS server resources and network resources. This is because converting a zone can trigger Active Directory replication.

Page 63: Deploying DNS

Implementing Windows Server 2003 DNS   175

Configuring ForwardingIf any of your servers need to forward queries to any other server, configure forwarding on the servers that must forward queries. If you want your server to forward queries to different servers depending on the DNS suffix specified in the query, configure conditional forwarding appropriately.

For more information about conditional forwarding, see “Using Forwarding” earlier in this chapter, and see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Configuring the DNS Server for Dynamic UpdateDepending on how you deploy your server and zones, your zones might already be configured for dynamic update or secure dynamic update. If the zones are not configured as you intend, make any necessary changes. You can configure your zones to perform dynamic updates, secure dynamic updates, or no updates. However, configuring your zones to perform unsecured dynamic updates is a security risk and is not recommended.

For information about how to configure dynamic updates, see “Dynamic update” in Help and Support Center for Windows Server 2003. For information about how to allow only secure dynamic updates, see “Allow only secure dynamic updates” in Help and Support Center for Windows Server 2003.

Configuring Aging and ScavengingWith dynamic update, whenever a computer joins the network and registers with DHCP, the DNS server automatically adds resource records to the zone. However, in some cases, the DNS server does not automatically delete them, and they can become outdated. Outdated resource records use disk space on the server, and a server might use an outdated resource record to answer a query. As a result, DNS server performance suffers. To solve these problems, the Windows Server 2003 DNS Server service can scavenge outdated records by searching the database for records that are obsolete and deleting them.

You can configure aging and scavenging from DNS Manager or by using Dnscmd.exe.

For more information about configuring aging and scavenging in Windows Server 2003 DNS, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Page 64: Deploying DNS

176   Chapter 3   Deploying DNS

Configuring Zone Transfer and Replication ScopeIf you use file-based primary or secondary zones, configure each primary server for a zone to allow zone transfers to each secondary server for a zone. Next, configure each secondary server for a zone with a list of primary servers for that zone.

If you use Active Directory replication in a Windows Server 2003 domain, configure the zone replication scope as described in Table 3.8.

If the DNS server is a domain controller, you can change the zone type to Active Directory–integrated. However, if the DNS server is not a domain controller, this option is not available. Active Directory–integrated zone data is stored and replicated as part of the Active Directory database.

For more information about DNS zone storage and replication in Active Directory, enlisting a DNS server in a DNS application directory partition, removing a DNS server from a DNS application directory partition, or changing zone replication scope, click the Index button in Help and Support for Windows Server 2003, and then in the keyword box, type DNS zones.

Verifying that the DNS Server is Operating CorrectlyAfter you install and configure the DNS server, verify that it is operating correctly. Use the monitoring features of the DNS MMC snap-in, such as simple or recursive query testing. You can also examine the event log or use the DNSLint Windows Server 2003 command-line support tool to test DNS servers for problems with delegations and missing Active Directory replication records. In addition, you can use the Nslookup.exe command-line tool to attempt queries. To access the monitoring features of the DNS MMC snap-in, click Properties on the Action menu, and then click the Monitoring tab.

For more information about DNS troubleshooting and verifying DNS server operation, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Page 65: Deploying DNS

Implementing Windows Server 2003 DNS   177

Setting Up DNS ClientsSet up each DNS client with the following:

Host name and DNS suffix.

Preferred and alternate DNS servers.

Optionally, Proxy Auto-Configuration file or name exclusion list (if a proxy client).

You can use any of the following methods to set up your DNS clients:

Use the TCP/IP settings of the client.

Use Group Policy to configure groups of clients.

Use the DHCP Server service to configure some client settings automatically.

For more information about how to install and configure DNS clients, see “Configuring DNS client settings” in Help and Support Center for Windows Server 2003.

Using Command-Line Tools to Deploy DNSYou can use the command-line tool Dnscmd.exe to perform most of the tasks that you can perform from the DNS MMC snap-in. By using Dnscmd.exe, you can create, delete, and view zones and records and reset server and zone properties. You can also perform routine administration operations, such as creating or updating a zone, reloading the zone, refreshing the zone, writing the zone back to a file or Active Directory, pausing and resuming the zone, clearing the cache, adding records to root hints, stopping and starting the DNS service, and viewing statistics.

You can also use Dnscmd.exe to write batch file scripts and for remote administration. For more information about Dnscmd.exe, in Help and Support Center for Windows Server 2003, click Tools, and then click Windows Support Tools. For information about installing and using the Windows Server 2003 Support Tools and Support Tools Help, see the Sreadme.doc file in the \Support\Tools folder on the Windows Server 2003 operating system CD.

You can use the Nslookup.exe command-line tool to perform query testing of the DNS domain namespace and to display configuration information.

Page 66: Deploying DNS

178   Chapter 3   Deploying DNS

Additional ResourcesThese resources contain additional information and tools related to this chapter.

Related Information “Designing a Resource Authorization Strategy” in Designing and Deploying

Directory and Security Services of this kit for information about establishing security policies.

“Designing the Active Directory Logical Structure” in Designing and Deploying Directory and Security Services of this kit for information about how to deploy DNS specifically for Active Directory.

“Deploying Security Policy” in Designing a Managed Environment of this kit for more information about security policies.

“Designing an Authentication Strategy” in Designing and Deploying Directory and Security Services of this kit.

“Deploying ISA Server” in this book for more information about perimeter networks.

“Deploying DHCP” in this book.

“Designing a Group Policy Infrastructure” in Designing a Managed Environment of this kit.

The Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit) for more information about the DNS Server service and DNS troubleshooting .

The Directory Services Guide of the Windows Server 2003 Resource Kit (or see the Directory Services Guide on the Web at http://www.microsoft.com/reskit) for more information, about Active Directory installation and removal.

RFC 1035: Domain Names — Implementation and Specification.

DNS and BIND, 4th ed., by Paul Albitz and Cricket Liu, 2001, Sebastopol, CA: O’Reilly & Associates for more information about DNS.

Windows 2000 TCP/IP Protocols and Services, by Thomas Lee and Joseph Davies, 2000, Redmond, Washington: Microsoft Press for more information about the DNS wire protocol.

The Internet Engineering Task Force (IETF) link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources for more information about Request for Comments (RFC) documents and IETF Internet-Drafts.

Page 67: Deploying DNS

Implementing Windows Server 2003 DNS   179

Related ToolsFor information about installing and using the Windows Server 2003 Support Tools and Support Tools Help, see the file Sreadme.doc in the \Support\Tools folder of the Windows Server 2003 operating system CD.

Dnscmd.exe

You can use the Dnscmd.exe command-line tool to perform most of the tasks that you can perform from the DNS MMC snap-in.

DNSLint

DNSLint is a command-line tool that you can use to address some common DNS name resolution issues, such as lame delegation, DNS record verification, and verifying DNS records that are used for Active Directory replication.

Netdiag.exe

Netdiag.exe helps you to isolate networking and connectivity problems by performing a series of tests to determine the state of your network client and whether it is functional.

Nslookup.exe

You can use the Nslookup.exe command-line tool to submit DNS queries and display the results of the queries.

Related Help TopicsFor best results in identifying Help topics by title, in Help and Support Center, under the Search box, click Set search options. Under Help Topics, select the Search in title only checkbox.

“Migrating servers” in Help and Support Center for Windows Server 2003 for information about upgrading your existing DNS servers or migrating third-party DNS servers.

“Monitor servers” in Help and Support Center for Windows Server 2003 for more information about testing DNS server performance.

“Initiate a zone transfer at a secondary server” in Help and Support Center for Windows Server 2003 for more information about using zone transfer.

“Dynamic update” in Help and Support Center for Windows Server 2003 for information about how to configure dynamic updates.

“Allow only secure dynamic updates” in Help and Support Center for Windows Server 2003 for information about how to allow only secure dynamic updates.

“Configuring DNS client settings” in Help and Support Center for Windows Server 2003 for more information about how to install and configure DNS clients.

Page 68: Deploying DNS