7119437 deploying dns

8/8/2019 7119437 Deploying DNS

1/68

C H A P T E R 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 infrastructureenables resources on a TCP/IP network to locate other resources on the network by using host name-to-IPaddress resolution and IP address-to-host name resolution. The Active Directory directory service requiresDNS 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.................................................... ...........154

Securing 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 athttp://www.microsoft.com/reskit).

Deploying DNS


2/68

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 operatingsystems (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 conjunctionwith planning your Active Directory logical structure. For more information about designing the ActiveDirectory logical structure, see Designing the Logical Structure in Designing and Deploying Directory and Security Services of this kit.


3/68

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 DNSwith 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


4/68


DNS ConceptsWindows Server 2003 DNS is based on Requests For Comments (RFCs) standards developed by the InternetEngineering Task Force (IETF) and is therefore interoperable with other standards-compliant DNSimplementations. DNS uses a distributed database that implements a hierarchical naming system. Thisnaming 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 Internetnamespace. Computers running Windows Server 2003 and Microsoft Windows 2000 also use DNS tolocate domain controllers and other servers running Active Directory.

DNS RolesDeploying a DNS infrastructure involves design, implementation, and maintenance tasks. The individualswho are responsible for these tasks include DNS designers and the DNS administrators. Before you begindesigning your DNS deployment, it is helpful to identify the individuals in your organization who areresponsible 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 DNSinfrastructure

Managing Active Directory integration

DNS designer roleIf you are deploying DNS to support Active Directory in an environment that does not already have a DNSinfrastructure, the DNS designer is responsible for the DNS integration with the entire Active Directoryforest. 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 DNSinfrastructure, the DNS designer works with the DNS administrator for Active Directory to delegate theforest root DNS name to Active Directory. The Active Directory forest administrator delegates managementof DNS to a DNS administrator.

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


5/68


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 aboutconditional forwarding, see Help and Support Center for Windows Server 2003.

DNS application directory partitions. DNS application directory partitions enable you toset the replication scope for Active Directoryintegrated DNS data. By limiting the scope of replication traffic to a subset of the servers running Active Directory in your forest, you canreduce 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 moreinformation about DNSSEC, see Help and Support Center for Windows Server 2003.

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

Tools for Deploying DNSWindows 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 aseries 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 WindowsSupport Tools

Nslookup.exeYou can use the Nslookup.exe command-line tool to perform query testing of the DNS domain namespaceand 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 sameas 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 byrunning Suptools.msi.


6/68


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 incontoso.com can be configured to forward queries for names in treyresearch.com to a DNS server hosting thetreyresearch.com zone.

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

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

The hierarchical naming structure of the domain tree. Each domain label that isused 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 queryresponses.

In DNS, the inverted hierarchical tree structure that is used to index domain nameswithin 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 authoritiesdelegate domains to organizations such as Internet Service Providers (ISPs), which in turn delegatesubdomains to their customers or host zones for their customers. For more information about publicnamespaces, see the Internet Assigned Numbers Authority (IANA) link on the Web Resources page athttp://www.microsoft.com/windows/reskits/webresources.

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

A DNS name that uniquely identifies a node in a DNSnamespace. 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 server

Conditional forwarding

Delegation

DNS client resolver

DNS namespace

DNS server

Domain tree

Public namespace

Forward lookup zone

Fully qualified domain name (FQDN)


7/68


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 createtheir own root servers and any subdomains as needed. The internal namespace can coexist with an externalnamespace.

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 DNSserver periodically checks for changes made to the zone on its configured primary DNS server, and performsfull 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 theDNS 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 nameDNSserverone.contoso.com or a namespace (NS) resource record can map the name contoso.com to theserver 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 tonetwork resource names.

A partial copy of a zone that can be hosted by a DNS server and used to resolve recursiveor iterative queries. Stub zones contain the Start of Authority (SOA) resource records of the zone, the DNSresource records that list the zones authoritative servers, and the glue address (A) resource records that arerequired for contacting the zones authoritative servers. Stub zones are used to reduce the number of DNSqueries 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 asingle separate entity by a DNS server. The zone contains resource records for all of the names within thezone.

A file that consists of the DNS database resource records that define the zone. DNS datathat is Active Directoryintegrated is not stored in zone files because the data is stored in Active Directory.However, DNS data that is not Active Directoryintegrated 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 namespace

Iterative query

Primary DNS server

Secondary DNS server

Recursive query

Resource record (RR)

Reverse lookup zone

Stub zone

Zone

Zone file

Zone transfer


8/68


Examining Your CurrentEnvironmentBefore you deploy Windows Server 2003 DNS, you must assess your current environment to determine theDNS 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 currentenvironment.

Figure 3.2 Examining Your Current Environment


9/68


Determining Internet StatusIf you want devices outside your private network to be able to resolve names belonging to your internalnamespace, your IP addresses and DNS domain names must be registered with an Internet registrationauthority (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 completecontrol of network resource allocation and security. Use an ISP if you have a small network that will not beexpanding 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 supportyour DNS deployment.

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


10/68


Analyzing Your Network TopologyAnalyze your existing network topology and plan your DNS namespace while accounting for the service andadministrative 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 placeholdersenables 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 amodified 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 beyondaccounting.

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

Identify Your Security PoliciesIdentify and document your organizations security policies before you begin to design and deploy your DNSinfrastructure. 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 aManaged Environment of this kit.

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


11/68


Figure 3.3 Designing a DNS Namespace


12/68


Identifying Your DNS NamespaceRequirementsThe 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 DNSinfrastructure from a version of Windowsearlier than Windows Server 2003.

DNS namespace design can remain thesame.

You are upgrading from a third-party DNSinfrastructure that uses DNS software thatadheres to standard DNS domain namingguidelines.

DNS namespace design can remain thesame.

Your existing DNS software does notconform to standard DNS domain namingguidelines.

Bring your existing DNS namespacedesign into compliance with DNS domainnaming guidelines before deploying aWindows Server 2003 DNS namespace.

You are integrating Windows Server 2003DNS into an existing third-party DNS

software that adheres to standard DNSdomain naming guidelines.

Integrate Windows Server 2003 DNSwith your current DNS infrastructure.

You do not need to change thenamespace design of the third-partyDNS infrastructure or your existingnamespace.

You are deploying a new WindowsServer 2003 DNS infrastructure.

Design a logical naming convention for your DNS namespace based on DNS

domain naming guidelines.You are deploying WindowsServer 2003 DNS to support ActiveDirectory.

Create a DNS namespace design that isbased on your Active Directory namingconvention.

You are modifying your existing DNS Ensure that Active Directory domain

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


13/68


namespace to support Active Directory,but you do not want to redesign your DNS

namespace.

names match your existing DNSnames. This enables you to deploy the

highest level of security by using thesimplest management techniques.


14/68


Creating Internal and External DomainsOrganizations that require an Internet presence as well as an internal namespace must deploy both an internaland an external DNS namespace and manage each namespace separately. You can create a mixed internal andexternal 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 thedesign options for deploying a mixed internal and external namespace and the level of managementcomplexity for each option, along with an example to illustrate each option.

Table 3.3 Mixed Internal and External DNS Namespace Design Options

Design Option ManagementComplexity Example

The internal domainis a subdomain of the external domain.

Easy to deploy andadminister.

An organization with anexternal namespacecontoso.com uses the internal

namespace corp.contoso.com.The internal andexternal domainnames are differentfrom each other.

More complicated thanprevious option.

An organization usescontoso.com for its externalnamespace, and corp.internalfor its internal namespace.

NoteYou can also use the same name for the internal domain and theexternal domain. However, this method is not recommended. It createsname resolution problems because it introduces DNS names that arenot unique. This method requires additional configuration to enableoptimized performance.


15/68


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 externalnamespace 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 nameof the parent. For example, a child domain for the human resources department that is added to theus.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 astand-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 namecorp.internal for their internal namespace.

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


16/68


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

If you use an internal DNS root, a private DNS root zone is hosted on a DNS server on your internalnetwork. This private DNS root zone is not exposed to the Internet. Just as the DNS root zone containsdelegations to all of the top-level domain names on the Internet, such as .com, .net, and .org, a private rootzone contains delegations to all of the top-level domain names on your network. The DNS server that hoststhe 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 bestmethod 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 anyname 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 delegationfrom your root zone to the top level of the DNS namespace of the partner organization.


17/68


If name resolution is required by computers that do not support software proxy, or by computers that supportonly LATs, then you cannot use an internal root for your DNS namespace. In this case, you must configureone 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 eachtype.

Table 3.4 Client Proxy Capabilities

Proxy Capability

Microsoft Software with

Corresponding ProxyCapabilities

ForwardsQueries

Can You Use

an InternalRoot?

No Proxy Generic Telnet

Local AddressTable (LAT)

Winsock Proxy (WSP) 1. x and later Microsoft Internet Securityand Acceleration (ISA)Server 2000 and later

Name ExclusionList

WSP 1. x and later Internet Security andAcceleration (ISA) Server 2000 and later, and allversions of Microsoft Internet Explorer

Proxy Auto-configuration(PAC) File

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

Configuring Name Resolution for

Disjointed NamespacesIf you need to create or merge two DNS namespaces when you deploy Windows Server 2003 DNS, this canresult in disjointed namespaces a DNS infrastructure that includes two or more top-level DNS domainnames. To configure internal name resolution for multiple DNS top-level domains, you must do one of thefollowing:

Important

Do not reuse names that exist on the Internet in your internalnamespace. If you repeat Internet DNS names on your intranet, it canresult in name resolution errors.


18/68


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


19/68


If you want to reduce cross-domain DNS query traffic, configure the DNS servers that hostthe DNS zones in the first and second namespaces to host secondary zones for the DNS

zones in each others namespaces. In this configuration, the DNS servers that host the DNSzones in each namespace are aware of the DNS servers in the other namespace. This solutionrequires increased storage space for hosting secondary copies of zones in differentnamespaces, and generates increased zone transfer traffic.

If storage capacity on DNS servers is a consideration, configure the DNS servers that hostthe DNS zones in one namespace to forward name resolution queries in a second namespaceto the DNS servers that are hosting the DNS zones for the second namespace. Thenconfigure the DNS servers that host the DNS zones in the second namespace to forwardname resolution queries in the first namespace to the DNS servers that are hosting the DNSzones for the first namespace. You can use Windows Server 2003 DNS conditionalforwarders 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 DNSInfrastructure Into an Existing DNSNamespaceWindows 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. Thecomplexity of your integration process depends, in part, on the DNS features that you need to support. If thecomputers in your DNS infrastructure are running versions of DNS that support the same features, thenintegrating the Windows Server 2003 DNS infrastructure is a simple process. If the computers in your DNSinfrastructure are running versions of DNS that do not support the same DNS features, then the integration

process is more complex.


20/68


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

BIND8.2

BIND8.1.2

BIND4.9.7

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

Dynamic update

Secure dynamic

update based onthe GSS-Transactionsignature (TSIG)algorithm

WINS andWINS-R records

Incremental zonetransfer

UTF-8 character encoding

DNS MMC snap-in

Dnscmd.exe

Active Directoryintegrated zones

Storage of zonesin the DNSapplicationdirectorypartition

Aging andscavenging of

obsolete recordsStub zones

Conditionalforwarding


21/68


Creating DNS Domain Names andComputer 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 namingconvention, 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, youmust 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-leveldomain 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 youselected 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.


22/68


3. Register your DNS domain name with an Internet registrar, and supply the registrar with theDNS 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 NameRegistration Example

The internal domainname is a subdomainof the external domain.

Register only the externaldomain name.

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

corp.contoso.com is usedfor the internalnamespace.

The internal andexternal domain namesare different from eachother.

Register the externaldomain name, and then,if you want the internaldomain to be publiclyaccessible, also register the internal domainname.

The domain namecontoso.com is used for the external namespace.The domain namecorp.contoso.com is usedfor the internalnamespace.

When you register your DNS domain name, the Internet registrar creates a delegation in the DNS zone that isauthoritative for the top-level domain that you selected. This is the top-level domain for the DNS servers thatare authoritative for your organizations Internet DNS domain name.


23/68


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 InternetDNS domain name. For example, if you have registered the Internet DNS domain namecontoso.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 nameresolution 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 theseacronyms 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 reducesadministrative costs.

If you are deploying DNS in a private network and do not plan to create an external namespace, it isrecommended that you register the DNS domain name that you create for your internal domain. If you do notregister the name and later attempt to use it on the Internet, or connect to a network that is connected to theInternet, 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 usersto remember the names of computers on public and private networks easily, and therefore facilitates access toresources on your network.

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

Note

If 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 inanother top-level domain, such as .net, then people who are searchingfor your domain name on the Internet might assume that computersand services in the wrong top-level domain belong to your company.


24/68


Creating Computer Names in a New Windows Server 2003 DNS

InfrastructureUse the following guidelines when creating names for the DNS computers in your new WindowsServer 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 aboutdesigning the Active Directory logical structure, see Designing the Active DirectoryLogical 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 characterslisted in RFC 1123: Requirements for Internet Hosts Application and Support , whichinclude AZ, az, 09, and the hyphen (-). Windows Server 2003 DNS supports almost anyUTF-8 character in a name; however, do not use extended ASCII or UTF-8 characters unlessall of the DNS servers in your environment support them.

Creating Computer Names in an Integrated DNS InfrastructureIf you are integrating Windows Server 2003 DNS with an existing third-party DNS infrastructure, you do notneed to make any changes to your third-party DNS host names. If you are migrating to WindowsServer 2003 DNS from a third-party DNS infrastructure, you must ensure that the host names that are used inthe third-party DNS infrastructure conform to the DNS Internet naming standards.

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


25/68


26/68


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, thenetwork must rely on Active Directory for browsing resources. This can have a significant impact on clientsthat are running applications that require NetBIOS support, even if the client operating system does notrequire NetBIOS support. When WINS is installed, performance monitor counters for WINS are alsoinstalled. 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 necessaryto support NetBIOS names on the network.

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

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

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

Important

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


27/68


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

providing name resolution services for Internet hosts.

Creating SubdomainsIf you are deploying DNS on a large enterprise network, or if you expect your network to expand to includeadditional subnets and sites, consider distributing the management of portions of your DNS namespace to theadministrators for the different subnets and sites in your network. To distribute the management of your DNSnamespace, create subdomains of your initial DNS domain and delegate the authority for these subdomainsto DNS servers located on different subnets or sites. In this way, you can create any number of separate andautonomous entities within a DNS namespace, each of which is authoritative for a portion of the overallnamespace.

Example: Merging DNS NamespacesContoso Corporation merged with Trey Research Corporation. Before the merger, each corporation usedinternal 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 theInternet, rather than using a private root.

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

The Contoso division and the Trey Research division each use a different method to support name resolutionfor names in their namespace. The Contoso division uses the name contoso.com externally andcorp.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.

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


28/68


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 organizations internal

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

Figure 3.4 Name Resolution in the Contoso Division


29/68


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 zonesor 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 toDNS 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 rootservers contain a delegation to the top level of the DNS namespace of the Trey Researchdivision, the internal DNS servers recursively resolve the query by contacting the DNSservers 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.cominternally. The server InternalDNS.treyresearch.com hosts the corp.treyresearch.com zone. The TreyResearch division does not have a private root.

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

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

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


30/68


Figure 3.5 shows this configuration.

Figure 3.5 Conditional Forwarding in the Trey Research Division


31/68


Designing a DNS Server InfrastructureDNS servers store information about the DNS namespace and use the information to answer queries fromDNS 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 datadistribution and update topology while minimizing query and zone transfer network traffic. The DNSadministrators 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


32/68


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 DNSServersTo reduce administrative overhead, use the minimum number of DNS servers required. Be sure to make atleast 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 todetermine 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 IIImicroprocessor running at 700 MHz.

For information about capacity planning, see Allocating Hardware Resources earlier inthis chapter.

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

If you plan to host Active Directoryintegrated zones, you must place these zones onWindows 2000based or Windows Server 2003based domain controller.


33/68


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 routedenvironments. In addition, although the DNS service supports incremental zone transfers(IXFRs) and clients and servers can cache recently used names, traffic considerations canstill remain an issue, depending on available bandwidth. This is especially true when usingshort Dynamic Host Configuration Protocol (DHCP) leases, which require more frequentdynamic updates.

If you have a high number of client nodes on a single subnet, placing more than one DNSserver 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 serversfor a zone, the primary DNS server can become overloaded when the secondary servers poll to ensure thattheir 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 secondaryservers 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 outdatedmore often.

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

Placing DNS Servers for AvailabilityTo 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 alternateDNS server. In a LAN configuration, place the pair of authoritative DNS servers on separate subnets. In aWAN configuration, place the pair of authoritative DNS servers on different networks, and then ensure that atleast 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 enablecommunications 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 allnetwork services. If a router goes down and your clients cannot access any network services, then DNSfailure 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.


34/68


If you have an Internet presence, DNS must be working properly for Internet clients to access your Webservers, 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 theorganizations server is secured against Internet attackers.

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

For more information about how to place DNS servers to maximize Active Directory availability, seeDesigning the Active Directory Logical Structure in Designing and Deploying Directory and SecurityServices 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 queryto another DNS server, known as a forwarder . Forwarders are ordinary DNS servers and require no specialconfiguration; 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 Internettraffic to a forwarder on the external network. To ensure fault tolerance, forward queries to more than oneforwarder.

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

You can use conditional forwarding to more precisely control the name resolution process. Conditionalforwarding enables you to designate specific forwarders for specific DNS names. You can use conditionalforwarding 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-SiteInternal Domains

In Windows Server 2003 DNS, non-root servers resolve names for which they are not authoritative, do nothave 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 isconfigured to forward queries to a forwarder in Site B, and it must resolve a name in a zone hosted by aserver in Site C. Because the non-root server can forward queries only to Site B, it cannot directly query theserver in Site C. Instead, it forwards the query to the forwarder in Site B, and the forwarder queries the server in Site C.


35/68


When you use conditional forwarding, you can configure your DNS servers to forward queries to differentservers 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 toforwarders 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 usea 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 allqueries that it could not resolve to its parent server, DNS1.corp.contoso.com, in Seattle. When the server inSeville 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 forwardqueries destined for the Hong Kong site directly to a server in that site, instead of first detouring to Seattle, asshown 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 toDNS5.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 athttp://www.microsoft.com/reskit).


36/68


Using Conditional Forwarding to Query for Names in Other

NamespacesIf your internal network does not have a private root and your users need access to other namespaces, such asa network belonging to a partner company, use conditional forwarding to enable servers to query for namesin 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 domainname.

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

Before upgrading to Windows Server 2003, the Trey Research division created secondary zones to ensurethat computers in both the Contoso and Trey Research namespace can resolve names in the Contoso, TreyResearch, 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 WindowsServer 2003 DNSThe procedure you need to follow to upgrade DNS servers to Windows Server 2003 depends on whether youwant to support Active Directory or not. If you are upgrading to Windows Server 2003 DNS and might notsupport Active Directory, for information about upgrading your existing DNS servers or migrating third-partyDNS servers, see Migrating servers in Help and Support Center for Windows Server 2003. Migrationinvolves the following:

Plan your migration schedule to ensure that your DNS clients have access to a DNS server atall 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 DirectoryLogical 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 inHelp 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).


37/68


Designing DNS ZonesEach zone type that is available in Windows Server 2003 DNS has a specific purpose. The DNS designer inyour organization selects the type of zones to deploy based on the practical purpose of each zone. The DNSadministrators 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


38/68


Choosing a Zone TypeDesign zones to correspond to your network administration infrastructure. If a site in your network isadministered locally, deploy a zone for the subdomain. If a department has a subdomain, but noadministrator, keep the subdomain in the parent zone. Decide whether or not to store your zones in ActiveDirectory. Active Directory distributes data using a multimaster replication model that provides more securitythan 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 morethan 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 Directoryintegrated zones.

Primary Zones

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

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

Stub ZonesA stub zone is a copy of a zone that contains only the original zones start of authority (SOA) resourcerecord, the name server (NS) resource records listing the authoritative servers for the zone, and the glueaddress (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 fromwhich 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 areferral 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 zones primary servers for SOA resourcerecords, NS resource records at the zones root, and glue address (A) resource records. The DNS server attempts to update its resource records at the end of the SOA resource records refresh interval. To update itsrecords, the DNS server queries the primary servers for the resource records listed earlier.


39/68


You can use stub zones to ensure that the DNS server that is authoritative for a parent zone automaticallyreceives 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 Directoryintegrated.If you use Active Directoryintegrated stub zones, you can configure them on one computer and let ActiveDirectory 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 andSupport 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 therouting of DNS traffic over a network. These features enable a DNS server to respond to a query by doingone 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 theDNS root servers. If the stub zone for a child zone is hosted on the same DNS server as the parent zone, theDNS server that is hosting the stub zone receives a list of all new authoritative DNS servers for the childzone when it requests an update from the stub zones 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 theauthoritative DNS servers are added and removed.

Use conditional forwarding if you want DNS servers in one network to perform name resolution for DNSclients in another network. You can configure DNS servers in separate networks to forward queries to eachother without querying DNS servers on the Internet. If DNS servers in separate networks forward DNS clientnames 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 serverson the query/resolution path must have port 53 open. However, if you are using conditional forwarding andyou have a firewall between DNS servers in each of the networks, the requirement to have port 53 open onlyapplies to the two DNS servers on either side of the firewall.

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


40/68


Active DirectoryIntegrated Zones

If your DNS topology includes Active Directory, use Active Directoryintegrated 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 Directoryintegrated zone is always replicated.

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

Enable you to secure zones by using secure dynamic update. Provide increased fault tolerance. Every Active Directoryintegrated zone can be replicated

to all domain controllers within the Active Directory domain or forest. All DNS serversrunning on these domain controllers can act as primary servers for the zone and acceptdynamic updates.

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

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

You can combine Active Directoryintegrated 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 thanWindows 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 DirectoryIntegrated Zones in Application DirectoryPartitions

Windows Server 2003 Active Directory enables you to configure an application directory partition that limitsthe scope of replication. Data stored in an application directory partition is replicated to a subset of domaincontrollers. 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 domaincontrollers that run the DNS Server service. By storing Active Directoryintegrated zones in an applicationdirectory partition, you can reduce the number of objects that are stored in the global catalog, and you canreduce the amount of replication traffic within a domain.


41/68


In contrast, Active Directoryintegrated zones that are stored in domain directory partitions are replicated toall domain controllers in the domain. Storing Active Directoryintegrated 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 2003domain 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 ForestDNSZoneswill be created, and for each domain in the forest, a domain-wide DNS application directory partition calledDomainDNS 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 havea distributed network, avoid using subdomains when possible.

In Windows Server 2003, zones are propagated by means of file-based zone transfer or Active Directoryreplication. If you use file-based zones, file-based zone transfer is the method of propagation. If you haveWindows Server 2003 and Windows 2000 Active Directoryintegrated zones, use Active Directoryreplication.

File-Based Zone Transfer Windows Server 2003 and Windows 2000 DNS support both incremental and full zone transfer of file-basedzones. Incremental zone transfer is the default method, but if this method is not supported by a third-partyDNS server that is involved in the transfer, DNS servers running Windows Server 2003 and Windows 2000transfer 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 onlytransfers 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 secondaryserver every time a DNS zone is updated.

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

Active Directory ReplicationActive Directory replication propagates zone changes between domain controllers. Replication processingdiffers 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 sincethe last change.


42/68


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. Thiscompression 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 Directoryintegrated zones in a Windows Server 2003 domain, you must select anActive Directoryintegrated 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 ActiveDirectoryintegrated DNS zone data to all DNS servers in the forest, this produces greater network trafficthan 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 DNSadministrators in your organization are responsible for managing zone replication.

Table 3.8 lists the replication options for Active Directoryintegrated zone data.

Table 3.8 Replication Options for Active DirectoryIntegrated Zone Data

Option Description When to Use

All DNSservers in theActiveDirectory

forest

The zone data replicates toall the DNS servers runningon Windows Server 2003based domain controllers in

all domains of the ActiveDirectory forest.

You want the broadest scope of replication. This option generallyproduces the most zonereplication traffic. Note that you

can choose this option only if allDNS servers hosting an ActiveDirectoryintegrated copy of thiszone run Windows Server 2003.

All DNSservers in aspecifiedActiveDirectorydomain

The zone data replicates toall DNS servers running onWindows Server 2003based domain controllers inthe specified ActiveDirectory domain. Thisoption is the default settingfor Active Directoryintegrated DNS zone

replication.(The specified ActiveDirectory domain is thedomain hosted by thedomain controller on whichthe DNS server hosting the

You do not need the zone to bereplicated throughout the forestand you want to limit zonereplication traffic. This optionproduces less zone replicationtraffic than replicating the zoneto all DNS servers in the forestor to all domain controllers inthe domain. If you choose this

option, the zone data does notreplicate to DNS servers runningon Windows 2000based domaincontrollers.


43/68


zone is running.)

(continued)


44/68


Table 3.8 Replication Options for Active DirectoryIntegrated Zone Data (continued)

Option Description When to UseAll domaincontrollers inthe ActiveDirectorydomain

The zone data replicates toall domain controllers in thespecified Active Directorydomain, whether or not theDNS Server service runs onthe domain controllers in thedomain.

You host an Active Directoryintegrated copy of this zone on aDNS server running on aWindows 2000based domaincontroller.

All domaincontrollersspecified inthereplication

scope of aDNSapplicationdirectorypartition

The zone data replicates toall the domain controllersspecified in the replicationscope of the DNS applicationdirectory partition.

You want to customize zonereplication scope for your organization. With this option,you can minimize zonereplication traffic while

maximizing functionality.However, this option requiresmore administrative overhead.

You can choose this option onlyif all DNS servers hosting anActive Directoryintegrated copyof this zone run WindowsServer 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 thatyou use to migrate zones, you must decide whether to take the original DNS server offline, or to use it as asecondary server. If you determine that the original third-party DNS server causes interoperability problemson 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 runningWindows Server 2003.

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


45/68


Configuring and ManagingDNS ClientsWhen you configure DNS clients, you must specify a list of DNS servers for clients to use when resolvingDNS names. You can also specify a DNS suffix search list to be used by the clients when performing DNSquery 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


46/68


Configuring Client DNS Server Lists andSuffix Search ListsConfigure your clients DNS server lists and suffix search list by including at least two DNS server IPaddresses on the clients and domain controllers: the IP address for a preferred server and the IP address for analternate server. Use a server running in the local site for the preferred server. The alternate server can berunning 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 theDNS 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 ClientConfigurationWindows Server 2003 includes a new set of Group Policy settings to simplify the rollout of WindowsServer 2003 DNS clients. You can use them to set your suffix search lists, dynamic update configuration, andmany 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 WindowsServer 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. WindowsServer 2003 DNS provides improved security features to decrease this vulnerability. The DNS designer inyour 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 securitythreats.


47/68


Figure 3.10 shows the process for securing your DNS infrastructure.

Figure 3.10 Securing Your DNS Infrastructure


48/68


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 DNSserver 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 DNSare 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 hasalready been foot printed. If the attack is successful, the packets appear to be coming from a valid IP addresson the network. This is commonly called IP spoofing. With a valid IP address (an IP address within the IPaddress 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 thatare under the control of the attacker. One method of redirection involves the attempt to pollute the DNScache of a DNS server with erroneous DNS data that might direct future queries to servers that are under thecontrol 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 datato resolve a query for the external name. Redirection can be accomplished when an attacker has writableaccess 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 .

Footprinting

Denial-of-service attack

Data modification

Redirection


49/68


Developing a DNS Security PolicyIf your DNS data is compromised, attackers can gain information about your network that can be used tocompromise 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 inyour network.

By using denial-of-service attacks, attackers can prevent e-mail from being delivered to andfrom 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 islower and the possibility of discovering the intruder is greater. For a DNS server that is exposed to theInternet, 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 PolicyLow-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 DNSdata, or in a private network in which no external connectivity is possible. A low-level security policyincludes 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.


50/68

162 Chapter

7119437 deploying dns

Documents