Choosing a Zone Type

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

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

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

Primary Zones

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

Secondary Zones

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

Stub Zones

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

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

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

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

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

Note

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

Stub Zones and Conditional Forwarding

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

  • Providing a referral to another DNS server.

  • Forwarding the query to another DNS server.

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

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

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

Active Directory–Integrated Zones

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

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

  • Enable you to secure zones by using secure dynamic update.

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

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

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

You can combine Active Directory–integrated zones and file-based zones in the same design. For example, if the DNS server that is authoritative for the private root zone is running on an operating system other than Windows Server 2003 or Windows 2000, it cannot act as an Active Directory domain controller. Therefore, you must use file-based zones on that server. However, you can delegate this zone to any domain controller running either Windows Server 2003 or Windows 2000.

Storing Active Directory–Integrated Zones in Application Directory Partitions

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

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

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