Cumulative list of reasons that DNS records disappear from DNS zones

Symptoms

Sucessfully registered DNS records are no longer present in a DNS zone.

Cause

Multiple root causes exist, and they are listed in the following table:

Cause

Issue

Synopsis

1

DNS Scavenging is misconfigured.

The Scavenging feature on one or more DNS Servers was configured to have overly-aggressive settings and is prematurely deleting DNS records for AD-integrated DNS zones.

2

DNS zones are CNF or conflict mangled in Active Directory.

The container representing the DNS zone in Active Directory has become CNF or conflict mangled, and was replaced by a different container that may first be empty or contain a subset of the records contained in the previous instance of the zone.

3

DnsAvoidRegisterRecord defined in a Group Policy Object (GPO).

A code defect exists if SRV record registration is excluded by using the "DC locator DNS records not registered by the DCs" Group Policy setting. This modifies the DnsAvoidRegisterRecords registry setting under the "hklm\software\policies\microsoft\netlogon\parameters" registry subkey.

A DNS client's DNS Host record is deleted after you change the DNS server IP address on the same client.

8

Record registration failures make records vulnerable to the scavenging process.

DNS dynamic update protocol updates for existing records fail. Therefore, the records time stamp does not update, and this makes the record vulnerable to deletion by a correctly configured DNS Scavenging process.

9

DNS records are deleted when a given Windows client dynamic lease is changed to a reservation.

DNS records currently registered by a DHCP enabled Windows client are deleted by the DHCP server when the client's dynamic lease is transitioned to a reservation and the following settings are enabled:"Always dynamically update DNS A and PTR records"

"Discard A and PTR records when lease is deleted"

"Dynamically update DNS A and PTR records for DHCP clients that do not request update"

Resolution

Cause 1: DNS scavenging is misconfigured

Scavenging is the most common culprit when DNS records go missing from DNS zones where . Even Windows-based computers that have statically assigned servers register their records every 24 hours. Verify that the NoRefresh and Refresh intervals are too low. For example, if these values are both less than 24 hours, then you will lose DNS records.

With exceptions, Active Directory allows for any domain controller to originate creating an object in a writable directory partition. When two domain controllers create the same object or container inside a replication window, the directory applies conflict resolution logic to determine which object should remain and which object should be quarantined.

When the replication of objects results in a name conflict (two objects have the same name within the same container or have the same container name), then the directory automatically renames one of the objects to have a unique name. Specifically, a "*CNF:<GUID>" string is appended to the DN path of the created object and the instance that is created by the last writer domain controller remains.

If the container representing a DNS zone (or subordinate container) becomes conflict mangled, the container representing a more complete copy of a DNS zone can be replaced by container with the same name that is (at first) less complete or even empty.

Determine which copy of the zone should remain, delete the "bad" copy of the zone (which may be the one with the non-CNF-mangled DN path) and rename the CNF-mangled copy of the zone as required, then restart the DNS Server service or reload zones.

Cause 3: DnsAvoidRegisterRecord defined in a GPO

Cause 3 is related to a code defect in which SRV records are excluded by using the DnsAvoidRegisterRecords setting in a GPO. The DNS server targeted by a Windows client receives record updates one time every five minutes. The time stamp and the version number on dnsRecord constantly increase. As SRV records are stored in dnsRecord attribute, a non-linked multivalued attribute, the domain controller or DNS server receiving the incorrect updates is always winning the conflict resolution. Some updates are lost while other deleted records mysteriously come back.

SRV record loss associated with a mass restart has the same issue with last-writer wins behavior on the non-linked multivalued attributes. But version churn caused by the GPO is not going to the source of the registrations. The mass restarts of lots of domain controllers is the cause of the concurrent registrations. Some administrators have worked around this behavior by lowering the SRV registration window.

A good solution to this problem is to configure the DNS client on domain controllers point off-box DNS Servers addresses as primary for name resolution. Designate local hub DNS servers per region and have all the DNS servers in that region point that one DNS server. The hublet DNS servers all point to a single DNS server in a tiered hub-and-spoke model. All DNS servers can point themselves as secondary's but not primaries. Because restarts triggered by Windows Update usually occur at 03:00, as long as there is only one hublet DNS server per time zone, you will never encounter this issue.

Check the Active Directory object version on the dnsNode object that contains the missing record. If it is a large number, this might be your issue. A possibility is to move the exclusion of the SRV records to local policy in order to stop the constant deregistrations.

However, there is an issue with the new behavior. In the new behavior, the SRV records are removed only one time, specifically the first time that the policy is applied. Because the records are non-linked multivalued attribute, a condition can occur where multiple domain controllers remove SRV records on different DNS servers before Active Directory coverage of the zone. When the underlying attribute is fully converged, the last DNS server to receive a deletion is the only version that is kept. Only the records that were removed on that DNS server are removed from the SRV record. The SRV records removed on other DNS servers seem to come back. Manual cleanup may be required after the all domain controllers have applied the GPO and the affected SRV records are fully converged.

Cause 4: Windows Server 2008 zone transfer delete bug

This is resolved by installing Windows Server 2008 Service Pack 2 or KB953317. This issue is specific to Windows Server 2008 DNS zones that are hosting secondary copies of DNS zones, and it does not occur when the Microsoft DNS Server role is installed on Windows Server 2008 R2, Windows Server 2003 R2, Windows Server 2003, or Windows 2000 Server computers.

When you change DNS servers' IP addresses on a TCP\IP network stack on Windows Server 2008 or Windows Server 2008 R2 and then restart the computer, sometimes the deletion of the host "A" record occurs on the original DNS server after the registration of the host A record on the newly configured DNS server IP address (Active Directory Integrated DNS). From a user perspective, anything that depends on name resolution is broken.

When the DNS server IP is changed on the client, the client sends an SOA update to delete its "A Record" from OLD DNS server and send another update to register its "A" Record to the NEW DNS Server.

This DCR is designed to reduce the number stale host "A" records. Problem occurs in Active Directory-integrated zones.

This issue arises when the DNS Server IP is changed on the client. When it changes, client sends the register request to new server and delete request to old server. As both the servers are already synced up, register will not occur. But deletion happens in the old server, and then it is deleted in both servers because of Active Directory.

This problem occurs if Option 81 is defined and ISATAP or 6to4 interfaces are present. DNS dynamic update protocol update incorrectly sets TTL to 0 which triggers record deletion for IPv6 record registration.

This issue occurs because of an issue in the DNS Client service. When the DNS server configuration information is changed on a client, the DNS Client service deletes the DNS host record of the client from the old DNS server and then adds it to the new DNS server. Because the DNS record is present on the new server that is a part of the same domain, the record is not updated. However, the old DNS server replicates the deletion operation to the new DNS server and to other DNS servers. Therefore, the new DNS server deletes the record, and the record is deleted across the domain.

Cause 8: DNS Dynamic Update Protocol updates to existing records fail causing them to be deleted by the scavenging process as aged records

Multiple root causes exist for DNS record registration failures.

NETLOGON event 577X events are logged for record registration failures of SRV records by the NETLOGON service.

Other events are logged for registration failures of host A and PTR records. Check System logs for these failures. Such events may be logged by the clients that register these records, or by the DHCP servers that register the records on the clients behalf.Cause 9: Converting an active dynamic lease to a reservation deletes the A and PTR records for that client

This behavior is by design. The DNS records (A record/PTR) are automatically updated during the next DHCP renew request from the client.

More Information

KB885279 Net Logon policies are not applied on a high-speed computer that is a Windows Server 2003-based domain controllerKB306602 How to optimize the location of a domain controller or global catalog that resides outside of a client's siteKB267855 Problems with many domain controllers with Active Directory integrated DNS zonesKB953317 A primary DNS zone file may not transfer to the secondary DNS servers in Windows Server 2008