Windows Sever 2003 : Implementing a DNS Name Resolution Strategy

11/6/2012 1:01:59 AM
Once you have determined your network’s name resolution requirements and designed your DNS namespace, it is time to actually implement the name resolution services by installing and configuring servers. Toward this end, you must first decide how many servers you need and where you are going to locate them, and then determine how you are going to configure the servers.

How Many DNS Servers?

A Windows Server 2003 DNS server running on a computer with a 700 MHz Pentium III processor can handle up to 10,000 name resolution queries per second, so in most instances, private networks use multiple DNS servers for reasons other than a heavy client load. Some other reasons for deploying multiple DNS servers on your network are as follows:

  • Providing redundancy For a network that relies heavily on DNS name resolution, having a single DNS server means having a single point of failure. You should plan to deploy a sufficient number of DNS servers so that at least two copies of every zone are always online.

  • Improving performance For a DNS client, the combination of a nearby DNS server and a reduced traffic load on that server means improved name resolution performance.

  • Balancing traffic load Even when a single server is capable of handling the name resolution requests for your entire network, the network might not be up to the task. Having all the network’s DNS traffic converge on a single subnet can overload the LAN and slow down the name resolution process, as well as interfere with the other computers sharing the network. Deploying multiple servers on different subnets enables you to balance the DNS traffic between them and avoid creating bottlenecks.

  • Reducing WAN traffic When your network consists of LANs at multiple sites, connected by multiple wide area network (WAN) links, it is usually best to have a DNS server at each site. WAN links are relatively slow compared to LAN connections, and their bandwidth can be quite expensive. Having a DNS server at each site prevents name resolution traffic from monopolizing the WAN connections. This practice also prevents router or WAN connection failures from interrupting name resolution services.

  • Delegating authority In a large organization, it might be impractical for a single administrative team to maintain the DNS namespace for the entire enterprise. It is often more efficient to split the namespace into several domains and have the administrative staff in each department, division, or office location maintain their own DNS resource records. While it is not essential that you allocate a separate DNS server to each domain, circumstances usually dictate this setup.

  • Supporting Active Directory The Active Directory directory service relies heavily on DNS. Active Directory clients use DNS to locate domain controllers and browse the network. You should deploy enough DNS servers to support the needs of Active Directory and its clients.

You should consider all these factors when deciding how many DNS servers you need, and when balancing them against factors such as hardware and software costs and the administrative burden of running multiple servers.

Understanding DNS Server Types

You can deploy Windows Server 2003 DNS servers in a number of different configurations, depending on your infrastructure design and your users’ needs.

Using Caching-Only Servers

It is not essential for a DNS server to be the authoritative source for a domain. In its default configuration, a Windows Server 2003 DNS server can resolve Internet DNS names for clients immediately after its installation. A DNS server that contains no zones and is hosting no domains is called a caching-only server. If you have Internet clients on your network but you do not have a registered domain name and are not using Active Directory, you can deploy caching-only servers that simply provide Internet name resolution services for your clients.

In some instances, you might want to use some caching-only servers on your network, even if you are hosting domains. For example, if you want to install a DNS server at a branch office for the purpose of Internet name resolution, you are not required to host a part of your namespace there. You can simply install a caching-only server in the remote location and configure it to forward all name resolution requests for your company domains to a DNS server at the home office, while the caching-only server resolves all Internet DNS names itself.

Using Forwarders

A forwarder is a DNS server that receives queries from other DNS servers that are explicitly configured to send them. With Windows Server 2003 DNS servers, the forwarder requires no special configuration. However, you must configure the other DNS servers to send queries to the forwarder. To do this, from the Action menu in the DNS console, click Properties to display the server’s Properties dialog box, click the Forwarders tab, and then supply the IP address of the DNS server that will act as a forwarder. (See Figure 1.) You can also specify multiple forwarder IP addresses to provide fault tolerance.

Figure 1. The Forwarders tab in a DNS server’s Properties dialog box

You can use forwarders in a variety of ways to regulate the flow of DNS traffic on your network. As explained earlier, a DNS server that receives recursive queries from clients frequently has to issue numerous iterative queries to other DNS servers on the Internet to resolve names, generating a significant amount of traffic on the network’s Internet connection.

There are several scenarios in which you can use forwarders to redirect this Internet traffic. For example, if a branch office is connected to your corporate headquarters using a T-1 leased line and the branch office’s Internet connection is a much slower shared dial-up modem, you can configure the DNS server at the branch office to use the DNS server at headquarters as a forwarder, as shown in Figure 2. The recursive queries generated by the clients at the branch office then travel over the T-1 to the forwarder at the headquarters, which resolves the names in the usual manner and returns the results to the branch office DNS server. The clients at the branch office can then use the resolved names to connect to Internet servers directly, over the dial-up connection. No DNS traffic passes over the branch office’s Internet connection.

Figure 2. Using a forwarder to reroute DNS traffic

You can also use forwarders to limit the number of servers that transmit name resolution queries through the firewall to the Internet. If you have five DNS servers on your network, all of which provide both internal and Internet name resolution services, you have five points where your network is vulnerable to attacks from the Internet. By configuring four of the DNS servers to send all their Internet queries to the fifth server, you create only one point of vulnerability.

Chaining Forwarders

One DNS server that is functioning as a forwarder can also forward its queries to another forwarder. To combine the two scenarios described in the previous section, you can configure your branch office servers to forward name resolution requests to various DNS servers at headquarters, and then have the headquarters servers forward all Internet queries to the one server that transmits through the firewall.

Using Conditional Forwarding

One of the new features in Windows Server 2003 is the ability to configure the DNS server to forward queries conditionally, based on the domain specified in the name resolution request. By default, the forwarder addresses you specify in the Forwarders tab in a DNS server’s Properties dialog box apply to all other DNS domains. However, when you click New and specify a different domain, you can supply different forwarder addresses so that requests for names in that domain are sent to different servers.

As an example of conditional forwarding, consider a network that uses a variety of registered domain names, including When a client tries to resolve a name in the domain and sends a query to a DNS server that is not an authoritative source for that domain, the server normally must resolve the name in the usual manner, by first querying one of the root name servers on the Internet. However, using conditional forwarding, you can configure the client’s DNS server to forward all queries for the domain directly to the authoritative server for that domain, which is on the company network. This configuration keeps all the DNS traffic on the private network, speeding up name resolution and conserving the company’s Internet bandwidth.

You can also use conditional forwarding to minimize the network traffic that internal name resolution generates by configuring each of your DNS servers to forward queries directly to the authoritative servers for their respective domains. This practice is an improvement even over creating an internal root, because there is no need for the servers to query the root name server to determine the addresses of the authoritative servers for a particular domain.

Using conditional forwarding extensively on a large enterprise network has two main drawbacks: the amount of administrative effort needed to configure all the DNS servers with forwarder addresses for all the domains in the namespace, and the static nature of the forwarding configuration. If your network is expanding rapidly and you are frequently adding or moving DNS servers, the need to continually reconfigure the forwarder addresses might be more trouble than the savings in network traffic are worth.

Creating Zones

A zone is an administrative entity you create on a DNS server to represent a discrete portion of the namespace. Administrators typically divide the DNS namespace into zones to store them on different servers and to delegate their administration to different people. Zones always consist of entire domains or subdomains. You can create a zone that contains multiple domains, as long as those domains are contiguous in the DNS namespace. For example, you can create a zone containing a parent domain and its child because they are directly connected, but you cannot create a zone containing two child domains without their common parent because the two children are not directly connected. (See Figure 3.)

Figure 3. Valid zones must consist of contiguous domains

You can divide the DNS namespace into multiple zones and host them on a single DNS server if you want to, although there is usually no persuasive reason to do so. The DNS server in Windows Server 2003 can support as many as 200,000 zones on a single server, although it is hard to imagine what scenario would require this many. In most cases, an administrator creates multiple zones on a server and then delegates most of them to other servers, which then become responsible for hosting them.

Every zone consists of a zone database, which contains the resource records for the domains in that zone. The DNS server in Windows Server 2003 supports three zone types (as shown in Figure 4), which specify where the server stores the zone database and what kind of information it contains.

Figure 4. The Zone Type page of the New Zone Wizard

The three zone types are as follows:

  • Primary zone A primary zone contains the master copy of the zone database, where administrators make all changes to the zone’s resource records. If the Store The Zone In Active Directory (Available Only If DNS Server Is A Domain Controller) check box is cleared, the server creates a primary master zone database file on the local drive. This is a simple text file that is compliant with most non-Windows DNS server implementations.

  • Secondary zone A duplicate of a primary zone on another server, the secondary zone contains a backup copy of the primary master zone database file, stored as an identical text file on the server’s local drive. You cannot modify the resource records in a secondary zone manually; you can only update them by replicating the primary master zone database file, using a process called a zone transfer. You should always create at least one secondary zone for each primary zone in your namespace, both to provide fault tolerance and to balance the DNS traffic load.

  • Stub zone A copy of a primary zone that contains Start Of Authority (SOA) and Name Server (NS) resource records, plus the Host (A) resource records that identify the authoritative servers for the zone. The stub zone forwards or refers requests. When you create a stub zone, you configure it with the IP address of the server that hosts the zone from which you created the stub. When the server hosting the stub zone receives a query for a name in that zone, it either forwards the request to the host of the zone or replies with a referral to that host, depending on whether the query is recursive or iterative.

You can use each of these zone types to create forward lookup zones or reverse lookup zones. Forward lookup zones contain name-to-address mappings and reverse lookup zones contain address-to-name mappings. If you want a DNS server to perform name and address resolutions for a particular domain, you must create both forward and reverse lookup zones containing that domain.

Using File-Based Zones

When you create primary and secondary zones, you must configure zone transfers from the primary to the secondaries to keep them updated. In a zone transfer, the server hosting the primary zone copies the primary master zone database file to the secondary zone, so that their resource records are identical. This enables the secondary zone to perform authoritative name resolutions for the domains in the zone, just as the primary can. You can configure zone transfers to occur when you modify the contents of the primary master zone database file, or at regular intervals.

Originally, the DNS standards defined the zone transfer process as a complete replication of the entire zone database file. At specified times, the DNS server hosting the primary zone transmits the file to all the servers hosting secondary copies of that zone. File-based zone transfers use a relatively simple technique in which the servers transmit the zone database file in its native form, or sometimes with compression. You must manually create secondary zones and configure the servers to perform the zone transfers. A later DNS standard document (RFC 1995, “Incremental Zone Transfer in DNS”) defines a new replication method called incremental zone transfers. An incremental zone transfer consists of only the data that has changed since the last zone transfer. The Windows Server 2003 DNS server supports incremental zone transfers, but reverts to full transfers when one of the servers does not support the new standard.

Using Active Directory–Integrated Zones

When you are running the DNS server service on a computer that is an Active Directory domain controller and you select the Store The Zone In Active Directory (Available Only If DNS Server Is A Domain Controller) check box while creating a zone in the New Zone Wizard, the server does not create a zone database file. Instead, the server stores the DNS resource records for the zone in the Active Directory database. Storing the DNS database in Active Directory provides a number of advantages, including ease of administration, conservation of network bandwidth, and increased security.

In Active Directory–integrated zones, the zone database is replicated automatically, along with all other Active Directory data. Active Directory uses a multiple master replication system so that copies of the database are updated on all domain controllers in the domain. You don’t have to create secondary zones or manually configure zone transfers because Active Directory performs the database replication automatically.

By default, Windows Server 2003 replicates the database for a primary zone stored in Active Directory to all the other domain controllers running the DNS server in the Active Directory domain where the primary is located. You can also modify the scope of zone database replication to keep copies on all domain controllers throughout the enterprise, or on all domain controllers in the Active directory domain, whether or not they are running the DNS server.

If all your domain controllers are running Windows Server 2003, you can also create a custom replication scope that copies the zone database to the domain controllers you specify. To modify the replication scope for an Active Directory–integrated zone, open the zone’s Properties dialog box in the DNS console, and in the General tab, click the Change button with the label Replication: All DNS Servers In the Active Directory Domain to display the Change Zone Replication Scope dialog box.

Active Directory conserves network bandwidth by replicating only the DNS data that has changed since the last replication, and by encrypting the data before transmitting it between servers. The zone replications also use the full security capabilities of Active Directory, which are considerably more robust than those of file-based zone transfers.

Because Windows Server 2003 automatically replicates the Active Directory database to other domain controllers, creating secondary zones is not a prerequisite for replication. Indeed, you cannot create an Active Directory–integrated secondary zone. However, you can create a file-based secondary zone from an Active Directory–integrated primary zone, and there are occasions when you might want to do this. For example, if no other domain controllers are running DNS in the Active Directory domain, there are no other domain controllers in the domain, or your other DNS servers are not running Windows Server 2003, you might have to create a standard secondary zone instead of relying on Active Directory replication. If you do this, you must manually configure the DNS servers to perform zone transfers in the normal manner.

Most View
Looking Good, Sounding Great (Part 1) : Q Acoustics Q7000i 5.1, Bowers & Wilkins MT-50, Canton Movie 1050
Booting on HP 9000 Servers (part 2) - The setboot Command, Boot Console Handler (BCH) and Processor Dependent Code (PDC)
Sony Xperia ZL Review - A Powerhouse Phone In An Amazingly Compact Chassis (Part 3)
Long Awaited Canon Super Telephoto Emerges From The Wild
Sling Media Slingbox Pro-HD
Ouya Gaming Machine Review - Founding Backer Version (Part 1)
Seasonic And Enhance Junior PSUs - Compact Power Supply (Part 5) : Enhance ENP-7025E
SQL Server 2008 : Common performance problems (part 1) - Procedure cache bloating
ECS Z77H2-A2X v1.0 - Golden LGA 1155 Mainboard From The Black Series (Part 6)
Booting on HP 9000 Servers (part 4) - HPUX Secondary System Loader (hpux)
Top 10
SQL Server 2012 : Consolidating Data Capture with SQLdiag - Getting Friendly with SQLdiag (part 2) - Using SQLdiag as a Service
SQL Server 2012 : Consolidating Data Capture with SQLdiag - Getting Friendly with SQLdiag (part 1) - Using SQLdiag as a Command-line Application
SQL Server 2012 : Consolidating Data Capture with SQLdiag - The Data Collection Dilemma, An Approach to Data Collection
SQL Server 2012 : Troubleshooting Methodology and Practices - Data Analysis, Validating and Implementing Resolution
SQL Server 2012 : Troubleshooting Methodology and Practices - Data Collection
SQL Server 2012 : Troubleshooting Methodology and Practices - Defining the Problem
SQL Server 2012 : Troubleshooting Methodology and Practices - Approaching Problems
Windows 8 : Accessing System Image Backup and Recovery Functionality with Windows Backup, Cloud Backup
Windows 8 : Using the Windows 8 Recovery Tools (part 2) - Push Button Reset
Windows 8 : Using the Windows 8 Recovery Tools (part 1) - Creating a System Recovery Disc, Booting to the Windows Recovery Environment