Chasing the DNS Zone Location Problem

When you use Active Directory (AD)–integrated DNS servers and zones on Windows Server 2003 and later, an individual DNS zone's data can be stored in one of three locations in Active Directory. Zone Data can be replicated to 1) every domain controller (DC) in the domain, 2) every DNS server in the domain, or 3) every DNS server in the forest. A problem can occur when a single DNS zone is stored in more than one location and replication is attempted. To avoid such problems, it's helpful to know some background about AD–integrated DNS zones and replication. I'll cover these areas, then show you an example DNS zone-location problem and steps you can take to solve it.

A Bit About DNS Zones
DNS zones can be stored in AD in three unique places based on how the DNS administrator wants zone information to be replicated throughout the AD environment. With Windows 2000, zones were stored in the domain naming context (domain partition)—meaning that zone information was replicated to every DC in the domain. Even if the DNS component had not been installed and running on a specific DC, this same DC would still have DNS zone information replicated to its domain partition.

Windows 2003 introduced the concept of an application partition that facilitated two unique places where DNS zones can be stored. Windows 2003 and Windows Server 2008 store zone information in either the DomainDNSZones or ForestDNSZones of an application directory partition. Zone data stored in DomainDNSZones is replicated to every DNS server in the domain. DNS zone data stored in ForestDNSZone is replicated to every DNS server in the contiguous AD forest.

If the zones weren't stored in AD, they would be stored in flat files (i.e., non–AD integrated). In a flat-file storage scenario, one primary zone exists, and for redundancy or load dispersion a secondary zone is created on a separate second DNS server. This DNS server's purpose is to host the secondary zone that's used when the DNS server hosting the primary zone is offline or unavailable to respond. In the flat-file scenario, A, PTR, and SRV records and the SOA record for the specific zone could be edited only on the DNS server hosting the primary zone. The second server hosting the secondary zone would pull a copy of the primary zone from the first DNS server hosting the primary zone.

When a specific zone—for example, town.local—is stored in AD, instead of the primary zone being hosted on a single server as in the flat-file zone-storage model, AD-integrated DNS servers can have multiple authoritative DNS servers that host a replica of the single primary zone town.local.

To ensure that AD-integrated zone replication works correctly, an administrator must make sure that a single zone is stored in the exact same place in AD. That is, regardless of whether you choose to store the forward or reverse lookup zone in the domain naming context of Windows 2000 or in the DomainDNSZones or ForestDNSZones application partition of Server 2008/Windows 2003, you must verify that the settings for zone storage are the same across all DNS servers.