Tracking DNS Record Deletion

I have worked with number of customers who have faced the scenario where few or many (important) DNS records disappear from a DNS zone and they are left only with a question as to who or what deleted those records. There could be a number of scenarios which can result in this situation, to mention a few:

  • The computer owning the DNS record was gracefully shut-down and dynamically de-registered its host or SRV records
  • A zone transfer deletion bug described in MSKB 953317 deletes virtually the entire contents of the zone immediately following zone transfer on busy W2K8 SP1 computers hosting secondary copies of a DNS zone.
  • Systems not able to update their record in DNS.
  • Misconfigured scavenging settings prematurely delete records before they can be re-registered by the computer that owns the record
  • Someone manually deletes the record from the DNS zone.

For this post, I am going to discuss DNS auditing configuration which can help identify the root cause of DNS record deletion or at least narrow it down.

NOTE: For this discussion I will use as the domain as well as the DNS zone name.

A DNS zone can be either stored on the DNS server in form of a file such as or it can be integrated in Active Directory for replication.

In the case of Standard Primary or Secondary zone, there is no way to determine who or what deleted the records from the zone. But if the zone is Active Directory-integrated, we can set up Directory Service Access Auditing to learn more about the cause of deletion of the records.
To learn more about AD Integrated zones, please refer to this.
A DNS zone integrated in Active Directory can be stored in 1 of 3 different partitions:

  • Default Domain partition : “All domain controllers in the Active Directory domain”
  • DomainDNSZones partition (Application partition) : “All DNS servers in the Active Directory domain”
  • ForestDNSZones partition (Application partition): “All DNS servers in the Active Directory forest”

To determine which partition your zone is located in:

  1. Open the DNS Management Console (DNS MMC).
  2. Right click on your zone name and select properties.
  3. On the General tab, review the setting for “Replication”.

To configure auditing on the zone, follow these steps:

Enable Directory Service Access auditing

You can enable this on a single Domain Controller or all Domain Controllers as needed to suit your environment. Follow the steps appropriate for your needs below.

Enable Directory Service Access auditing on a single DNS Server (Domain Controller)
Windows Server 2003 and above

1) Click on Start > Run > type gpedit.msc and then press ENTER.

2) In the Group Policy MMC, navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy.

3) Define ‘Audit directory service access’ for success and failure.

4) Refresh the policy on the computer by typing gpupdate /force at a Command Prompt.

For Windows Server 2008 and above you can also use the following command to enable Directory Service auditing on a DNS Server (Domain Controller):

Auditpol /set /category:“DS Access” /Success:Enable
Auditpol /set /category:“DS Access” /Failure:Enable

Enable Directory Service Access auditing on all DNS Servers (Domain Controllers)
Windows Server 2003

1) Click on Start > Administrative Tools > Domain Controller Security Policy.

2) Navigate to Local Policies > Audit Policy

3) Define ‘Audit directory service access’ for success and failure.

4) Refresh the policy on computer by typing gpupdate /force at a Command Prompt.

Windows Server 2008 and later

1) Click on Start > Run > type gpmc.msc, and then press ENTER.

2) In the Group Policy MMC, navigate to the Forest:> Domains > > Domain Controllers >Default Domain Controllers Policy.

3) Right click and select “Edit” on the Default Domain Controllers Policy.

4) Navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy.

5) Define ‘Audit directory service access’ for success and failure.

6) Refresh the policy all Domain Controllers by typing gpupdate /force at an Administrative Command Prompt.

Enable auditing on the DNS zone

1) Open ADSIEdit on any DC that has the DNS role. (Start, Run, type adsiedit.msc, and press ENTER).

2) Right-click ADSI Edit, click ‘Connect to..’

3) On the Connection Settings window that comes up, select the ‘Select or type a Distinguished Name or Naming Context:’ under Connection Point.

4) Depending on your Domain name and the partition where the zone is stored, type the Distinguished Name for the partition and click OK:

  • If the zone is stored in default Domain partition, then I will use DC=contoso,DC=com as the Distinguished Name. (This partition is generally loaded in Adsiedit by default).
  • If the zone is stored in DomainDNSZones partition, then I will use DC=DomainDNSZones,DC=contoso,DC=com as the Distinguished Name.
  • If the zone is stored in ForestDNSZones partition, then I will use DC=ForestDNSZones,DC=contoso,DC=com as the Distinguished Name.


(Screenshot demonstrating how to connect to the DomainDNSZones partition)

5) Navigate to the location of the DNS zone object according to where the zone is stored:

  • If the zone is stored in default Domain partition then:
    Expand Domain [(dc name)] > DC=contoso,DC=com > CN=System > CN=MicrosoftDNS
  • If the zone is stored in DomainDNSZones partition then:
    Expand Domain [(dc name)] > DC=DomainDNSZones,DC=contoso,DC=com > CN=MicrosoftDNS
  • If the zone is stored in ForestDNSZones partition then:
    Expand Domain [(dc name)] > DC=ForestDNSZones,DC=contoso,DC=com > CN=MicrosoftDNS

(Please note that in the case of a ForestDNSZones partition, the DN path will always refer to the forest root domain DN path)

6) Under CN=MicrosoftDNS you will find DC=<your zone name> ( in my case). Right click on that and select Properties.

7) On the Security tab, click the Advanced button.

8) Select the Auditing tab, and click Add.

9) Under User or Group, type ‘Everyone’ and click on Check Names button. Click OK.
(You may find some already existing entries with the name ‘Everyone’ under the Auditing tab. This may be confusing but please add a new entry as mentioned above.)

10) On the Auditing Entry window that pops up, under the Object tab, select Success and Failure for access types Write All Properties, Delete, and Delete Subtree and click Ok.

Reviewing auditing events using Event Viewer

After you have set up auditing by following the above mentioned steps, an Event ID (566 in Windows Server 2003 and 4662 in Windows Server 2008 R2) will be logged in the Security Event Log whenever a DNS record is modified; for example:

For Windows Server 2003:

Event Type: Success Audit
Event Source: Security
Event Category: Directory Service Access
Event ID: 566
Date: mm/dd/yyyy
Time: hh:mm:ss
User: Contoso\<account>  (computer account /user account)
Computer: <servername>
Object operation:
Object Server: DS
Operation Type: Object Access
Object Type: dnsNode
Object Name: DC=test1,,CN=MicrosoftDNS,DC=DomainDNSZones,DC=contoso,DC=com (This tells the name of the record that was deleted)
Handle ID: –
Primary User Name:
Primary Domain: contoso
Primary Logon ID:
Client User Name: (This contains the name of the user or the system that removed the record)
Client Domain:
Client Logon ID:
Accesses: (Write property / Deleted)*

For Windows Server 2008 and 2008 R2:

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: mm/dd/yyyy hh:mm:ss AM/PM
Event ID: 4662
Task Category: Directory Service Access
Level: Information
Keywords: Audit Success
User: N/A
Computer: <Server Name>

An operation was performed on an object.

Subject :

Security ID: CONTOSO\Administrator
Account Name: Administrator (computer account /user account)
Account Domain: CONTOSO
Logon ID: 0x1d3d5


Object Server: DS
Object Type: dnsNode
Object Name: DC=test,,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com (This tells the name of the record that was deleted)
Handle ID: 0x0


Operation Type: Object Access
Accesses: Write Property

Access Mask: 0x20
Properties: Write Property

When Active Directory deletes an object from the directory, it does not immediately remove the object from the database. Instead, Active Directory marks the object as deleted by setting the object’s isDeleted attribute to TRUE, stripping most of the attributes from the object, renaming the object, and then moving the object to a special container in the object’s naming context (NC) named CN=Deleted Objects. This object is called a tombstone and is used to replicate the object’s deletion throughout the Active Directory environment. Over time (default 60 days), the tombstone is removed and the object is truly gone from AD. DNS objects, however, have their own process of deletion – once the DNS zone is integrated in the Active Directory, all the DNS records become Active Directory objects but they get an attribute called “dNSTombstoned” attached to them.
A DNS record gets removed by either of the following methods:

  • Scavenging
  • Manual deletion
  • When it gets a valid TTL update with TTL=0
  • An LDAP delete command using interfaces such as ADSIEDIT or LDP

If the DNS record is getting deleted by any of the first 3 ways then the value of the dNSTombstoned attribute attached to it will become “TRUE”. In this scenario the records will still exist in Active Directory but DNS.exe will not load them in the MMC. This is because for DNS they are deleted, but for Active Directory they still exist as a valid AD object. We can still see them using ADSIEDIT. When the record is in this state in the Active Directory the value of dNSTombstoned can change to “FALSE” either when the host machine/DHCP sends an update for the record or by creating another record with the same name manually. When this happens, DNS.exe will start loading the record again in the MMC. If the DNS record is being deleted by the 4th method or if the record stays in the state of dNSTombstoned=TRUE for more than 7 days then it will be tombstoned (AD tombstoned) like any other AD object.

When the Accesses is “Write property” it means that the value of dNSTombstoned has been either changed to TRUE/FALSE or the time stamp on the record was updated and if the Accesses is “Deleted” then it means that the record has been AD tombstoned.


Deletion Type

Access Type (Accesses)






The DC name on which the Scavenging is turned on.

It is recommended that Scavenging is turned on only one DC containing the Zone.
The records will be scavenged only on that particular DC and thus the events logged due to scavenging will be logged on that DC only.

Note: Whenever a Scavenging cycle runs Event ID 2501 or 2502 is logged.
To verify that the records were deleted due to scavenging please match the timing of event 566 and event 2501

For better understanding of how Scavenging works, I would recommend you to go through the following articles:

Understanding aging and scavenging

Using DNS Aging and Scavenging

Scavenging setup

Manual delete(from DNS console)


The user name of person who deletes the record

When someone deletes the record manually from the DNS console, his/her username will be logged in this case.

Update from the Client directly


The name of the client machine

A valid update from the client can create, update or delete a record from the DNS.
If the update sent from the client has TTL > 0 then the record will be created or updated (if it is in the refresh interval) but if the client sends an update with TTL=0 then the existing record in the DNS will get removed (for example stopping the DHCP client service on a machine with static IP address causes this). In all the 3 ways the type of event logged will be the same.

Update from the DHCP server


The name of the DHCP server

Same as above.

Update from the DHCP server configured with credentials


The account configured on the DHCP

Same as above.

Deleted by AD (Adsiedit/ldp.exe)


The user account provided to run the process.

A DNS record can be deleted from the AD while it is still on the DNS MMC or even when it is dnsTombstoned. We can used Adsiedit or LDP.exe to delete the AD objects.
When this happens the Access type is shown as “Deleted” which means it AD tombstoned and the User name shown for this will be the username used to delete the object.

This table should cover almost all the scenarios.

Please note from the table that for every valid update the Access type would be “Write”. Just by looking at the Event ID we cannot determine whether the record was dnsTombstoned or the time stamp was updated, you may also find multiple events logged (which look the same) for the same record. When an event is logged we need to check in the DNS MMC and see if the record exists or not, if it does then it means the event was logged for renewing the timestamp on the record, if the record does not exist then it would mean that the record has been dnsTombstoned (You can verify this by checking the dnsTombstoned attribute of that record in Adsiedit).

Recommended Microsoft Knowledge Base articles discussing some issues that can cause DNS record deletion:

885279 Net Logon policies are not applied on a high-speed computer that is a Windows Server 2003-based domain controller
306602 How to optimize the location of a domain controller or global catalog that resides outside of a client’s site
267855 Problems with many domain controllers with Active Directory integrated DNS zones
953317 A primary DNS zone file may not transfer to the secondary DNS servers in Windows Server 2008
2520155 DNS Host record of a computer is deleted after you change the DNS server assignment

You may also face issues related to partial / full zone loading issues (many times confused as multiple records disappearing issue). In this case please check the Active Directory for any CNF objects which can cause this.

If you have any related questions, please post them here and I will try to answer them as soon as possible.

– Sneh Shah