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.

DNS Zone-Replication Settings
You configure DNS zone-replication settings using the Microsoft Management Console (MMC) DNS snap-in (Start, Administrative Tools, DNS). We'll walk through zone-replication setup using the example town.local primary zone. In the DNS console under Forward Lookup Zones, right-click the town.local zone, then click Properties, and the domain.local Properties (in this example, town.local) dialog box will be displayed. On the General Tab you'll see two options: Type, which is set to Active Directory-Integrated, and Replication (i.e., where the zones are kept in AD), which is set to All DNS servers in this domain. Clicking Change takes you to the Change Zone Replication Scope dialog box, which Figure 1 shows, in which three of the four options are available to store DNS zone information:

Figure 1: Change Zone Replication Scope dialog box

    I strongly recommend that you plan ahead of time where your zone information will be stored in AD before you configure it. The _msdcs.domain.local zone should be stored in the ForestDNSZones application partition. Each DC will register a GUID CNMANE record in the ForestDNSZones, and this information should be replicated to every DNS server in the forest, not just the domain. Other forward lookup zones and reverse lookup zones can be stored in ForestDNSZones, but to stay consistent and in line with an inverted DNS tree topology, where label hierarchy goes from top-level label to a period-delineated multiple-label hierarchy (as outlined in the IETF RFC 1033 and RFC 1034), store the other forward and reverse lookup zones in DomainDNSZones within the Server 2008/Windows 2003 application partition.

Zone-Location Problem
Now we'll look at how a problem might occur when zone settings are changed. Let's say you decided to place _msdcs.domain.local in the ForestDNSZones within the application partition and the forward lookup zone town.local and reverse lookup zone 1.268.192.in-addr.arpa in the DomainDNSZones partition. A couple of months go by, and DNS name resolution within your AD environment has been working like a champ. And then you get this event:

Event IDs 4521 and 4011

But at this point, someone with enterprise administrator rights makes changes to the environment that affect the location of the DNS zones. The admin created a new DC, installed DNS, and allowed replication to pull ForestDNSZones and DomainDNSZones residing in the application partition over from a DNS server already in the domain environment. After a few weeks, the enterprise administrator returned to this DC/DNS server and changed DNS zone town.local to reside within ForestDNSZones—instead of DomainDNSZones. However, time was needed for the _msdcs.domain.local zone to be removed from other DNSDomainZones partition on the other DC/DNS servers and for town.local to be placed in ForestDNSZones by AD replication. The EventID 4521 and EventID 4011 errors occur, indicating that a problem is occurring with DNS A, PTR, and SRV registration. Furthermore, on one of the DNS servers, no town.local zone is displaying in the DNS console. Users are complaining that DNS resolution is not successful.

Possible Solutions
There are a couple of possible solutions for this problem. The first is the best-case scenario: Simply wait a bit longer for replication to finish. You can check on replication status by using the command repadmin /showreps or repadmin /showrepl servername.town.local. Note that you can queue up a forced replication by drilling down to the server object and the NTDS object in the MMC AD Sites and Services snap-in (I'll explain how to do this shortly).

If allowing replication to finish doesn't solve the problem, your next step is to use ADSI Edit to view the three locations in AD where the zone information can be stored—that is, to view ForestDNSZones and DomainDNSZones in the application partition and domain naming context (Windows 2000 storage location). For details on how to do this, see the Microsoft article "Event ID 4515 is logged in the DNS Server log in Windows Server 2003".

You want to determine where the town.local zone is located. Is town.local located in two different storage locations—say in ForestDNSZones and in DomainDNSZones? Or is town.local showing up in the ForestDNSZones on one Server 2008 DC/DNS server and in DomainDNSZones on another Server 2008 DC/DNS server?

Back in the earlier days of Windows 2003, Microsoft documented an issue in dns.exe regarding conflicts caused by a Microsoft DNS container being created prior to full replication of the application partition (see support.microsoft.com/kb/836534). Dns.exe 5.2.3790.125 and later versions solved this problem. Figure 2 shows what this type of conflict on a Server 2008 server might look like when observed through ADSI Edit.

Figure 2: Viewing information about town.local zone in ADSI Edit

The presence of a CNF (conflict) object indicates the existence of a conflict. In Figure 2, you can see that DC=town.local resides in both the ForestDNSZones partition and the DomainDNSZones partition. In DomainDNSZones, notice the object DC=..InProgress-57548AC124357A8-town.local located under DC=domaindnszones,dc=town,dc=local, as well as the object CN=MicrosoftDNS0CNF54ce21bc-81e8-5af5-d112ebc8115, which indicates the conflict.

To remedy the conflict, first take a quick view of the zone information stored in the MicrosoftDNS0CNF object. Under this CNF object, view the contents of the town.local and 1.168.192.in-addr.arpa objects and compare with the ..InProgress and town.local objects located under MicrosoftDNS. If the CNF object under DomainDNSZones contains all the record objects needed, and the DC=town.local object under ForestDNSZomes contains only a few record objects, then do the steps in either option 1 or option 2, as follows:

Option 1

Figure 3: Forcing DNS zone replication

Option 2
Get your system state backup and restore the town.local zone from a previously successful backup. Any server resource records that are not on the town.local zone backup can be registered by pointing the unregistered server to the DNS Server. Then from the command line issue the following commands, in sequence. (Make sure each command returns successfully before executing the next command.)

ipconfig registerdns
net stop netlogon && netstart Netlogon
net stop dns && net start dns

Know Where Your Zones Are
Always make sure you know where you intend to store your DNS zone information. Remember that the _msdcs.domain.local zone should be in ForestDNSZones within the application partition, and be sure to place forward and reverse lookup zones in DomainDNSZones within the application partition. Always have a valid system state backup that includes your DNS zones, just in case. You can use ADSI Edit to view where zone information is stored in AD. Become familiar with your DNS environment, and be cognizant of your DNS hierarchy and how your DNS servers are configured.

References