What to do when DNS records disappear

Finding deleted DNS records

Domain Name System (DNS) records can be deleted manually, as a result of some operation such as a DC demotion or other object removal, and of course, they could be deleted programmatically. Remember that the record, like any AD object, can be deleted on any DC/DNS server and it will replicate to all DCs. One way to track this down is to find the deleted object and then look at the metadata. The built-in LDP.exe tool on all DCs is very helpful for this exercise.

In addition, finding DNS records in AD depends on the replication scope. Those locations are as follows. Table 1 shows the LDP tool exposing the DNS records in the DomainDNSZones container. Note that DNS records will only show up in one of these three locations.

Table 1: Replication scope locations in AD

When objects are deleted they are placed in the Deleted Objects folder, as shown in Figure 1. However, deleted DNS objects are stored in the container where the other DNS records are stored. For instance, in Figure 2, we see the DNS records stored in the DC=DomainDNSZones container, but there is also a Deleted Objects container. The DNS deleted objects are in this container.

Fig. 1: Deleted Objects (click to enlarge)

Fig.2: DNS Records List (click to enlarge)

Note: To expose the deleted objects folder (hidden by default in LDP.exe), do the following:

1. In the LDP.exe tool, connect to a DC and bind with admin credentials
2. Go to Options – controls and in the Load Predefined field, select Return Deleted Objects.
3. Refresh by selecting Tree – (domain name) - OK

Expanding the DC=deletedObjects,dc=domainDNSzones… container, the deleted DNS objects are exposed (Figure 3). In this case the record we are interested in is “DC=_dcdiag_test_record…” In this example this has been recreated several times. Note in Figure 3 the attributes exposed in LDP (right pane) are not much help. However, using Repadmin/showobjmeta command we can get more data.

This command has the following format:

Reapadmin /showobjmeta DCName ObjectDN

So for this example, we get the ObjectDN from the LDP tool and plug it in:

C:\Users\olseng>repadmin /showobjmeta wtec-dc4 "dc=_dcdiag_test_record\0ADEL:ba38f888-9314-4ddf-852d-736db6ae181e,cn=deleted objects,dc=domaindnszones,dc=wtec,dc=adapps,dc=hp,dc=com" >dnsdelete.txt

Fig. 3: Deleted DNS objects (click to enlarge)

I like to direct it to a file to make it easier to use. The output is shown in Figure 4. Note the red box around the isDeleted attribute. This attribute is set when the object is deleted. Also shown is the GUID of the originating DC and the timestamp. The GUID can be resolved to a DC name either by looking in the CNAME records on the DNS Management snapin or running. Often the DC name will show rather than the guid. Now it is evident when the record was deleted, which DC it was performed on and when. That will help in unraveling the mystery of the disappearing record.

Fig. 4: Deleted DNS record output (click to enlarge)

Fixing “Corrupt” or incorrect DNS records

If DNS records become corrupt or are not up to date, dynamic registration can be used easily to fix the problem. For instance the DNS Alias records used to map the server GUID to the FQDN of the server are used for AD replication. Recovering or reinstalling a DC could result in duplicate alias records where the old record is not purged. If there are multiple ones, or if the record is incorrect, then delete the records in question and the server to re-register the correct one. This usually takes about 15 minutes but you can restart the Netlogon service for a faster response. Remember to refresh the DNS management snapin to see the new records. All record types can use this method to register the correct record.

Fixing “Missing” DNS zones

One administrator was trying to remove DNS from a DC. He mistakenly deleted the DNS zone from the snap-in on that DC. He ignored the warning that this would remove the zone from AD. Within a few minutes, the whole production DNS zone was gone… Poof! Disappeared! He was contemplating another career but I assured him it was easily repairable, thanks to dynamic registration. We simply re-created the DNS zone, restarted Netlogon on each DC and the zone was repopulated. There were some static A records that had to be entered by hand but he had that information. I wouldn’t recommend this as a troubleshooting method but I have used it when the entire zone was hosed – meaning records and name resolution was inconsistent across the DNS servers. Delete the Zone and let the DCs re-register.

Recovering Corrupt ADI zones

While the AD Integrated (ADI) Primary DNS feature -- which stores the zone file in Active Directory -- is faster and more efficient than standard DNS, it has some negative points:

• The zone file is not a simple text file on disk and can only be viewed and manipulated with tools that access AD.

• Different replication scopes store the zone file in different locations in the AD making locating the DNS records difficult. Replication scope is defined in DNS Zone properties.

• ADI zones become “corrupt” in that the DNS records are not consistent across all DCs, giving inconsistent results to DNS queries.

Assuming you don’t want to wipe out the whole zone, there is a cool trick that can get the ADI (multi-primary) zone back on track if you suspect corruption (inconsistent behavior in the domain’s name resolution) in an ADI zone.

1. Identify one name server that is correct to use as the new source (pick the PDC emulator or look at the DNS errors, performance, etc.)
2. Go to the DNS Management snapin – zone properties. Select Zone Type and configure the zone to Standard DNS zone (see here). This is done by unchecking the “Store the zone in Active Directory” option. This dumps the DNS information from AD to a text zone file on that DC’s hard drive.
3. Go to another DC/Name Server – DNS management snap-in – and delete the zone. This will delete it from the Active Directory (a prompt will ask you).
4. Wait for Replication then check each DC/Name Server to make sure the zone is gone from AD. You can also use LDP and look at the 3 locations in AD shown in Table 1 in this article to make sure no DNS records are there. If you see them, then you didn’t delete the zone or replication isn’t finished.
5. When DNS is gone from the AD, let it simmer in this config for a couple of days. Now you have a single source (master) so there can be no inconsistency. Make sure it all works. It is a good idea to create standard secondary zones pointing to this name server as the master so you have better name resolution performance in this interim period.
6. Change the Standard Primary to ADI zones. Go to the DNS snapin – zone - properties – type and check the “Store the zone in Active Directory” option.
7. In the zone properties – Replication - select the replication scope desired (See here).
8. Change the secondary zones to ADI zones:

• Delete the secondary zone from the DNS snapin on each name server, restart DNS and it should re-register. You may need to recreate the zone on that name server and it will be populated.

OR

• Reboot the DC. Yes, rebooting the DC that hosts a secondary DNS zone when the zone is ADI Primary will convert the secondary zone to ADI when it comes back up.

The Disappearing Zone (by design)

I have run into cases where the admin claims his DNS zones are disappearing – one by one – sometimes in a day or two, sometimes over a couple of weeks. Look in the DNS snapin on each DC/Name Server and the zone is gone. This is actually by design and is noted in step seven above.  In these cases, the admin had a standard primary-secondary configuration and decided to migrate to an ADI Primary configuration. When the standard primary zone is converted to ADI primary, all DCs must host an ADI primary zone. They will remain with the secondary zone until rebooted as this info is held in memory. After reboot, the ADI zone will be populated on all DC/Name Servers.

It is permissible to have secondary zones in an ADI primary zone but they must be hosted on member servers – not DCs. This allows DNS servers to be placed in remote sites where DCs are not desired.

While multi-master replication and the Active Directory Integrated (multiple primary) zone features have introduced advantages and disadvantages at the same time, a good understanding of how they work will save the AD administrator a lot of time and effort in resolving these issues.

ABOUT THE AUTHOR
Gary Olsen is a systems software engineer for HP in Global Solutions Engineering. He has authored or co-authored several books, including Windows 2000: Active Directory Design and Deployment and Windows Server 2003 on HP ProLiant Servers.