Problem solve Get help with specific problems with your technologies, process and projects.

Active Directory-integrated DNS zones and the case of the disappearing zones!

If you've had zones disappear in your Active Directory-integrated DNS, you know the frustration of trying to find them again. Expert Gary Olsen gives you guidance on how to fix the problem or avoid it entirely.

Because the Active Directory-integrated primary zone provides multiple writeable copies of the zone information,...

much like domain controllers all hold writeable copies of the AD database, they must replicate that information to the other primaries. Occasionally these zones become corrupt or in some cases, they disappear.

The disappearing zone is actually a feature! By design, if a domain controller (DC) hosts a secondary zone that is a copy of an ADI zone, then when that DC reboots, it will convert the secondary into an ADI primary. Thus, the secondary seems to disappear. That is because the zone information is held in the AD, which every DC has a copy of, so a DC that has the zone information in the AD (populated by another DC/DNS server), as well as a secondary copy of that same zone, has to choose which one to use.

How can you get yourself into this fix? Pretty easily! Suppose you have a standard primary/secondary zone as shown in Figure 1. In this example, we have a single primary zone, and several secondary zones, all hosted on DCs. You decide to convert to an ADI primary configuration, so you go to the DC hosting the standard primary zone, (DC1 in London) and select the option to make the zone Active Directory Integrated. At that point, all the DNS records will be moved to the AD database (as shown in Figure 2) and replicated to the other DCs. The DCs, which also are DNS servers hosting secondary copies of the zone from the initial configuration, now have both copies. As long as they aren't rebooted, they will resolve names using the secondary zone. However, when they are rebooted, they will see both -- and have to make a choice either to use the secondary or the ADI primary version of the zone. They will always choose the latter. Thus, after booting, when you open up the DNS snap-in, you will notice that the secondary zone is gone, but the ADI Primary version of the zone is there. This is an absolute and can be reproduced at will. It's just the way it works. Figure 3 shows the DNS structure after you have converted to ADI primary on DC1 / London and rebooted DC3 and DC4 in Denver and Boston respectively. Note that DC3 and DC4 have ADI Primary zones while DC2 in Seattle still has the standard secondary – at least until it is rebooted

Figure 1 Standard Primary/Secondary DNS configuration

Figure 2 Viewing the DNS records in the AD using the LDP.exe tool

Figure 3 DNS configuration after DC1 converting to ADI primary and rebooting DC3 and DC4

There are of course other, shall we say "nonstandard", ways of having zones disappear and become corrupt. ADI zones present the same challenge all multi-master replication applications have -- trying to get it fixed while the bad stuff is still getting replicated. If you have an ADI zone that is corrupt -- that is, records disappear or updates don't work or name resolution doesn't work and it seems to be configured correctly, or zones disappear off of DNS servers -- then the best way to get control is to convert it back to a standard primary and start over.

Let's say we have 4 DC/DNS servers, DC1, DC2, DC3, DC4 hosting the ADI zone. To make it interesting, let's say we also have SRV1 hosting a standard secondary zone (SRV1 is a member server in the domain). The ADI zone is corrupt, and we want to clean it up. The procedure is as follows:  

1. Identify one of the DNS servers that has the "best" copy of the zone. For sake of argument, let's say it's DC1 in our example.
2. Delete the zone from DC2, DC3 and DC4. (Warning! If you go to the DNS snap-in and delete an ADI zone, it will warn you that if you continue, it will delete the zone from the AD. This is not good! Do not delete the zone using the DNS Snap-in.)
Delete the zone in this manner:

a. Go to Control Panel –> Add/Remove Programs –> Windows Components and uncheck the DNS component boxes. This action will uninstall DNS from that server and remove the DC's copy of the zone file as you would view it in the snap-in.
b. Repeat this for all DCs EXCEPT DC1.

3. Delete the secondary zone from SRV1.
4. On DC1, open the DNS snap-in and go to the zone properties page. On the General Tab, change the zone to a Standard Primary. Now you have a single writeable source of the zone.
5. Make any DNS repairs needed (missing host records, delegations and so on).
6. On DC2, 3, 4 and SRV1, create standard secondary zones.
7. Let it simmer for a couple of days. Make sure that the problems that led you to believe the zone was corrupt do not appear.
8. At this point, you are done. If you want to convert it back to an ADI zone, do the following:

a. On DC1 (the standard primary zone), convert the zone back to AD integrated (note that in Windows 2003, you can choose whether to replicate DNS information to DNS servers only or to all DCs).
b. Reboot DC2, 3 and 4. The reboot (as we noted earlier) will convert the secondary zone back to ADI primary.
c. If you don't want to reboot, just delete the standard secondary zone on these servers and add as an ADI primary zone.

Note that when you uninstall DNS from the DCs (step 2), the clients pointing to those DNS servers will have a performance hit, but they should still find a DNS server if they're configured properly. Therefore, you probably want to do this after hours.

Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers.

This was last published in September 2005

Dig Deeper on Windows systems and network management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.