Secondary zones cannot be stored in AD. Active Directory-integrated zones pro- vide enhanced security for DNS updates and zone replication traffic in several ways: all DNS servers hosting Active Directory-integrated zones must be registered in AD, AD replication traffic is encrypted, and you can use access control lists (ACLs) to restrict the hosts that are allowed to update RRs using DDNS (secure dynamic updates). ■ Stealth servers When you register the name servers that are authoritative for your Internet domain namespace, you must supply at least one or two name servers that are authoritative for the zone, so that authority can be delegated from the parent domain (.com, .net, and so on) to your servers. It is possible, however, for these servers to be sec- ondary, or slave, servers to a primary master server that is not listed in the registered NS records for the zone listed by the registrar as being authoritative for your domain. Usually, the primary master server is located behind a firewall, and access to the primary server itself and zone transfers to the secondary servers are tightly controlled by access rules on the firewall. ■ Caching name servers A caching name server performs queries on behalf of DNS, but the server itself is not authoritative for any zones. When you first set up a Windows DNS server with the root hints file, it is a caching name server that can resolve queries for Internet hosts using information it possesses about the name servers that are authoritative for the root zone.After time, the caching name server builds up a list of commonly queried names in its cache, which is subsequently used to answer queries on behalf of clients. ■ Forwarding servers A forwarding server is a kind of caching name server that sends queries to a predetermined list of name servers, known as forwarders, which can perform recursive queries on its behalf.The forwarding server will send its query to each forwarder in its list until it receives a positive or negative response. After it exhausts the name servers in its list, it can be configured to send requests to servers on the Internet using its root hints file. Alternatively, a forwarder can be configured to stop at this point, by disabling recursion, and send a negative response back to the original DNS requester if the for- warder cannot resolve the query. If recursion is disabled on the forwarding server, it is referred to as a forward-only server.There are a number of uses for forwarding servers and forwarders. They are often used when you want to tightly control which DNS servers (the forwarders) are able to send and receive DNS traffic through your firewall. Another common use of forwarders is to handle DNS queries performed across relatively slow WAN links on a corporate network. In the remote network, a name server is configured to forward queries to a more powerful caching name server that has a larger cache and is better able to resolve DNS queries as result of having access to more bandwidth, rather than send its queries directly to the Internet. A new feature of Windows Server 2003 DNS allows the configuration of conditional forwarding. Conditional forwarding allows the DNS administrator to configure the forwarding server to contact specific name servers based on the domain name specified in the query.To configure a conditional forwarder, you specify the domain name and the IP addresses of the servers that are responsible for resolving host 676 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 676 names in these domains. Conditional forwarders provide intelligent name resolution and are typically used to reduce the amount of traffic related to recursion on your network. ■ Nonrecursive servers A nonrecursive server is one on which you have disabled recur- sion so that it is not able to perform recursive queries on behalf of DNS requesters. Disabling recursion on a name server also prevents it from using forwarders to resolve queries. Usually, recursion is disabled on authoritative name servers that provide name res- olution for DNS requesters on the Internet, performing queries to locate your Internet hosts, such as your Web and mail servers. By disabling recursion on these name servers, you ensure that the servers will respond positively only to queries for RRs in zones for which they are authoritative, and hence tighten the security of these servers. DNS clients on the Internet will not be able to configure their TCP/IP settings to point to your DNS servers for name resolution. These name server roles are only logically separate from one another. It is possible to combine roles on a single name server. For example, a DNS server can be configured to be a primary master for one domain zone file and as a secondary for other domain zone files. However, it is often advanta- geous to separate these roles and place them on separate servers. By doing so, you are better able to design your DNS infrastructure to take into account the contingencies of your network infrastructure, such as the speed of your WAN links, the presence of firewalls, the need for security, and so on. Domain Controller versus Member Server In an AD environment, you have the choice to install and configure DNS on your domain con- trollers or on member servers. If you install DNS on your domain controllers, you can configure Active Directory-integrated zones. Active Directory-integrated zones provide the following advantages over standard DNS zones: ■ There is not a single point of failure for the primary zone. In a standard DNS environ- ment, if the primary master DNS server fails and is not brought online within a particular amount of time (specified in the SOA record), the secondary servers will remove the RRs from their zone, and name resolution will fail for the entire domain. ■ In large environments where DHCP servers and clients are updating RRs, this load can be distributed among domain controllers that store zone information in AD. ■ Active Directory-integrated zones provide enhanced security for zone replication in that DNS servers must be registered in AD and AD replication traffic is encrypted. ■ You can use secure dynamic updates with Active Directory-integrated zones to tighten security further. ■ Synchronization of zone information occurs automatically through AD replication. No further configuration is necessary to facilitate transfer of zone information among partici- pating servers. ■ AD replication is more efficient than the standard zone transfer mechanisms. For example, AD replication propagates only the last changes. Even though an incremental zone transfer Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 677 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 677 copies only the changes to the RRs, it propagates all the incremental changes to the RRs that have occurred since the last update. If you are not using IXFR, the entire zone file is copied whenever an update is made. ■ AD replication will compress replication traffic in certain circumstances, further reducing the bandwidth needed for DNS-related traffic. Active Directory-integrated zones can be used in combination with secondary servers. For example, you can use secondary zones on servers that are not configured as domain controllers.This is advantageous in situations where you do not want AD traffic replicated across a WAN link, but you do want to have an authoritative DNS server available at a remote location.You cannot simulta- neously load a standard text-based primary zone file and an Active Directory-integrated zone for the same domain on the same domain controller. However, you can combine primary, secondary, and Active Directory-integrated zones on the same domain controller. On a stand-alone or member server, primary and secondary zones can be combined on the same server. Furthermore, if you have multiple IP addresses bound to the server, you can emulate a secondary server on the same com- puter where the primary is located.This configuration is useful in very small environments where you have only one server. Planning for Zone Replication In planning your DNS infrastructure, you need to decide on the number and placement of your DNS servers. In particular, you must decide which servers will host zone files for your domains. Distributing zone files across your network has a number of advantages. For example, distributed zone files reduce the network traffic caused by DNS queries, increase availability and fault tolerance, provide load balancing, and result in shorter query response times. However, distributing zone files requires that you replicate zone information among your DNS servers, increasing traffic associated with zone transfers or AD replication (if you have enabled Active Directory-integrated zones). Zone files also increase the storage space requirements on DNS servers. Furthermore, replicating zone information increases the administrative effort required to maintain the DNS infrastructure. In planning for zone replication, you must decide which mechanism you will use for zone repli- cation: either standard DNS zone transfers or AD replication.This decision will depend on a number of factors, including the storage location (file-based or AD), the type of zone information (primary, secondary, or stub), and whether you need enhanced security. If you are using stand-alone, member servers, or other implementations of DNS, such as BIND, you must use standard DNS mechanisms for zone transfers. Depending on the version of DNS or BIND you are using, you can use either full (AXFR) or incremental (IXFR) zone transfers to prop- agate zone information. Incremental zone transfers reduce traffic by propagating only the incre- mental changes since the last update. Microsoft and other DNS servers optimize traffic associated with standard zone transfers by compressing the zone transfer information and including multiple RRs in individual TCP packets. This mechanism is referred to as fast zone transfers (it should not be confused with IXFR). Versions of BIND earlier than 4.9.4 do not support fast zone transfers. Support for fast zone transfers to BIND secondaries is enabled by default on Microsoft DNS servers, but it can be disabled. 678 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 678 A zone transfer is initiated when the secondary servers determine that the version number in their SOA RR is lower than the version number in the primary’s SOA RR, indicating an update to the primary zone.The secondary servers will compare the SOA version number in the following situations: ■ When they are notified of a change by the primary server. ■ When the refresh interval specified in the SOA has elapsed. ■ When the DNS service on the secondary server is started. ■ When a zone transfer is manually initiated by the administrator. When the secondary server determines it needs to update its zone file, it will make a request for an incremental zone transfer (IXFR) or a full zone transfer (AXFR). The notify list should contain only the IP addresses of secondary servers. It is not necessary to use this list to notify other domain controllers that have a copy of the Active Directory-integrated zone. Active Directory-integrated zones poll approximately every 15 minutes for updates. In fact, adding domain controllers to the notify list can actually degrade performance. Figure 20.3 shows the property pages for configuring a secondary zone transfer notify list. Active Directory-integrated Zone Replication Scope In a Windows Server 2003 environment, you must specify an Active Directory-integrated scope.The choices for the replication scope are described in Table 20.1. Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 679 Figure 20.3 Configuring a Notify List for Zone Transfers 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 679 Table 20.1 Active Directory-integrated Zone Replication Scope Options DNS Zone Replication Scope Description and Usage All DNS servers in the AD forest This is the broadest scope for DNS zone repli- cation and produces the most replication traffic. Zone data is replicated to all Windows Server 2003 domain controllers on which the DNS service is installed in the entire forest. You can use this option only when all your domain controllers are running Windows Server 2003. All DNS servers in a specified AD domain This is the default zone replication setting for DNS installed on Windows Server 2003 domain controllers. Zone information is repli- cated to all the Windows Server 2003 domain controllers on which the DNS service is installed in the domain. This option is desir- able when you want to limit or restrict replica- tion of zone information to only the domain controllers in your AD domain. Zone informa- tion is not replicated to Windows 2000 domain controllers. All domain controllers in the AD domain This option replicates DNS zone information to all domain controllers in the AD domain, regardless of whether or not the DNS service is installed on them. This option is desirable in mixed environment where Windows 2000 domain controllers are used. All domain controllers specified in the This option allows the customization of your replication scope of a DNS application zone replication environment. To use this directory partition option, your Windows Server 2003 domain controllers running DNS must be enlisted in the application directory partition. You can use the Dnscmd command-line utility to enlist DNS servers. The syntax for the command is dnscmd [DNS_server_name] /EnlistDirectoryPartition [FQDN of partition]. All fields are required. A significant advantage of using the application directory partition to store zone data is that the data is not replicated throughout the AD forest in the Global Catalog.This would be the case if AD zone data were stored in the domain partition, as it is in Windows 2000. When using intersite repli- cation (replication between different sites), the application directory partition is replicated according to the same schedule as the domain partition. To change the replication scope, you can use the DNS console, which presents the choices indi- cated in Figure 20.4.There are four choices, corresponding to the descriptions in Table 20.1.The 680 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 680 choices are to replicate zone data to all DNS server in the AD forest, to all DNS servers in the AD domain, to all domain controllers in the AD domain, and to all domain controllers specified in the scope of [a specified] application directory partition.The last choice to customize the zone replica- tion environment is grayed out and unavailable because the server has not been enlisted in other partitions. By default, when you first create an Active Directory-integrated zone and an application direc- tory partition has not been created, you have the option of creating the partition using the DNS console utility.You can also use the Ntds utility to create or delete application directory partitions and the Dnscmd utility to create the default application directory partitions. If the default partitions have already been created, you will get an error message indicating that the partition already exists. When you use the DNS console utility to create the application directory partition, you are pre- sented with two exclusive choices: ■ To create a single application directory partition that stores DNS zone data and replicates that data to all DNS servers in the domain. If you respond No to this choice, you will be presented with the second choice. ■ To create a single application directory partition that stores DNS zone data and replicates that data to all DNS servers in the forest.This creates the broadest scope for replication of DNS zone data. Figure 20.5 shows the choices for creating an application directory partition using the DNS console.The two dialog boxes below the DNS console window appear when you use the DNS console to create the default application directory partitions. Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 681 Figure 20.4 Changing Replication Scope for Windows Server 2003 Active Directory- integrated Zones 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 681 Security for Zone Replication To secure zone replication, you can configure Microsoft DNS to transfer zone information to only those servers that are found in the zone’s name server list. However, you can further tighten security by specifying individual IP addresses that are allowed to receive zone transfers. In situations where you are transferring zone transfer information over the Internet or you are concerned that this traffic can be intercepted, you should also consider using virtual private network (VPN) tunnels or Internet Protocol Security (IPSec) to encrypt this traffic. Using Active Directory-integrated zones also increases the security of your replication data by ensuring that all DNS servers are registered in AD and by using the security mechanisms inherent in AD replication.The security for zone transfers arises from the security of AD when you use Active Directory-integrated zones. Where possible, you should use Active Directory-integrated zones exclusively to improve performance and security of zone replication traffic. General Guidelines for Planning for Zone Replication You should keep the following guidelines in mind when planning for the distribution of zone files in your infrastructure: ■ Limiting the number of zones of authority in your DNS infrastructure simplifies adminis- tration. For each subdomain that has a separate zone of authority, you must ensure that the delegation of authority is correct for the subdomain and plan for the appropriate zone replication for each of these subdomains. ■ Distributing zone files increases the traffic associated with zone transfers or AD replication. 682 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy Figure 20.5 Creating the application directory partition using the DNS console 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 682 ■ Distributing zone files reduces the amount of traffic associated with name resolution queries. ■ Distributing zone files provides a means for supporting a disjointed namespace. ■ Distributing zone files increases availability and fault tolerance. It also reduces query response times. ■ If you are using Active Directory-integrated zones and all your DNS servers are installed on Windows Server 2003 domain controllers, you can use an application directory parti- tion to reduce the replication traffic associated with the transfer of zone information. ■ You can minimize the bandwidth consumed by standard zone transfers by modifying the schedule for transfers to secondary zones. ■ You should configure a primary server to notify only secondary servers. However, you should note that configuring the notify list to transfer zone information with the IP addresses of servers hosting the Active Directory-integrated zone can actually degrade per- formance. ■ If you are using standard DNS zone transfers, you should try to implement incremental zone transfers and fast zone transfers where possible. ■ A DNS server that is hosting an Active Directory-integrated zone or a standard primary zone can also host a standard secondary zone for another domain. ■ A stub zone is a synchronized copy of a subset of an authoritative zone’s RRs: the SOA, NS, and glue address records that identify authoritative name servers for a particular domain. ■ A stub zone can reduce cross-domain referral and other DNS traffic. ■ Security of zone data should be a consideration in your design and implementation. Active Directory-integrated zones provide more security than standard zone types. If you are using standard zone types, security can be enhanced by restricting the hosts that are allowed to receive zone transfers and by encrypting zone transfer traffic using VPN tunnels or IPSec, using the strongest level of encryption possible. Planning for Forwarding Distributing zone files throughout your infrastructure provides one means of ensuring efficient DNS name resolution. However, it is not always desirable or possible to distribute zone files to facilitate efficient DNS name resolution. A forwarder is simply a DNS server that receives queries that are forwarded to it by other DNS servers that are not capable of resolving the DNS query. Whenever a DNS server receives a query, it will try to answer the query from the data stored in its zone files or cache. Unless it has been con- figured otherwise (that is, as a nonrecursive server or a root-level server), if the DNS server cannot answer the query from its data, it will either contact authoritative root servers or forward the query to a forwarder. Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 683 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 683 Servers that are configured to not use recursion are called forward-only servers.You configure a forward-only server by checking the box labeled Do not use recursion for this domain in the Forwarders property page (see Figure 20.7 in the next section). Using forwarders can help reduce the amount of DNS traffic related to recursion, in addition to reducing the traffic related to zone replication.Their use can also help to enhance security by mini- mizing the number of DNS servers that need to communicate with one another across firewalls. Other advantages can be realized by using conditional forwarding, a new feature of Windows Server 2003 DNS. Conditional Forwarding Conditional forwarding adds intelligence to the forwarding of DNS queries. In previous versions of Microsoft DNS, you could configure a forwarding server to forward queries for all domains it could not resolve to only a single set of forwarders. In this setup, the list of forwarders was responsible for resolving names for the entire domain namespace on behalf of the forwarding server. With condi- tional forwarding, it is possible for the DNS administrator to configure a forwarding server to con- tact different sets of forwarders based on the domain name in the query. Figure 20.6 shows a possible design configuration for conditional forwarding. In Figure 20.6, dns1.syngress.net has been configured to send any query requests for hosts in the corp.tacteam.net domain directly to a dns1.corp.tacteam.net, which is authoritative for the zone. If conditional forwarding had not been configured, dns1.syngress.net would need to send a set of iter- ative queries to the root servers and dns1.tacteam.net in order to find the server that is authoritative for corp.tacteam.net.This configuration helps to eliminate network traffic related to DNS name res- 684 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy Figure 20.6 Conditional Forwarding Configured to Send Queries Directly to an Authoritative Server dns1.tacteam.net authoritative for tacteam.net dns1.corp.tacteam.net authoritative for corp.tacteam.net dns1.shinder.net DNS conditional forwarding configured to send queries for corp.tacteam.net directly to dns1.corp.tacteam.net DNS client Query for host on corp.tacteam.net Root DNS servers delegation of authority delegation of authority 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 684 olution and reduces DNS query response time. Also, since dns1.syngress.net is a direct point of con- tact with dns1.corp.tacteam.net, over time, it would acquire a significant number of cached RRs for hosts in the corp.tacteam.net domain. Figure 20.7 shows conditional forwarding configured for the corp.tacteam.net domain. Note that you can disable recursion on a per-domain basis. General Guidelines for Using Forwarders The following guidelines might assist you in planning to use forwarders as part of a DNS infrastructure: ■ Forwarders can eliminate the need to host secondary zone files across slow WAN links that might otherwise saturate bandwidth during zone replication. ■ Conditional forwarders can directly query authoritative name servers based on the domain name in the query. ■ Conditional forwarders can assist in providing support for a disjointed namespace and are a preferred solution over using stub zones for the same purpose. ■ Fault tolerance can be enhanced by specifying multiple forwarders and by enabling recur- sion if queries to forwarders fail. ■ Using forwarders can enhance security by minimizing the number of DNS servers that need to communicate with each other across firewalls. Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 685 Figure 20.7 Conditional Forwarding for the corp.tacteam.net Domain 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 685 . when the secondary servers determine that the version number in their SOA RR is lower than the version number in the primary’s SOA RR, indicating an update to the primary zone .The secondary servers. the default zone replication setting for DNS installed on Windows Server 2003 domain controllers. Zone information is repli- cated to all the Windows Server 2003 domain controllers on which the. the forwarding server to contact specific name servers based on the domain name specified in the query.To configure a conditional forwarder, you specify the domain name and the IP addresses of the