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:
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 contoso.com 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 contoso.com.dns 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:
To determine which partition your zone is located in:
To configure auditing on the zone, follow these steps:
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.
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
1) Click on Start > Administrative Tools > Domain Controller Security Policy.
2) Navigate to Local Policies > Audit Policy
4) Refresh the policy on computer by typing gpupdate /force at a Command Prompt.
1) Click on Start > Run > type gpmc.msc, and then press ENTER.
2) In the Group Policy MMC, navigate to the Forest: Contoso.com> Domains > Contoso.com > 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.
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:
(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:
(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> (DC=contoso.com 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.
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> Description: Object operation: Object Server: DS Operation Type: Object Access Object Type: dnsNode Object Name: DC=test1,DC=contoso.com,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> Description:
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:
Object Server: DS Object Type: dnsNode Object Name: DC=test,DC=contoso.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com (This tells the name of the record that was deleted) Handle ID: 0x0
Operation:
Operation Type: Object Access Accesses: Write Property
Access Mask: 0x20 Properties: Write Property dnsNode
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:
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)
User
Note:
Scavenging
Write
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
Deleted by AD (Adsiedit/ldp.exe)
Delete
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
Well written! Thanks for the information!
Very good article. Saves admins lots of time! Thanks.
Nice article.
Nice