DNS Records Disappearing and DNS Auditing

DNS Records Disappearing and DNS Auditing


Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP: Directory Services
Active Directory, Exchange and Windows Infrastructure Engineer


Compiled 12/9/2010


 


Are records misteriously disappearing?


DNS records that may be disappearing, or zone data that seems to be altered, may be caused by duplicate zones. Duplicate zones are little understood basically because of misunderstanding how AD integrated zones work. The whole concept of AD integrated zones is based on AD replication because the zone is stored in the actual AD database and is replicated to other DCs based on the replication scope of the zone (whether choosing the DomainNC partition, All DCs in the Domain, or All DCs in the Forest). Therefore due to AD replication, the zone is automatically available on other DCs in their respective replication scope.


DNS zone replication in Active Directory
http://technet.microsoft.com/en-us/library/cc779655(WS.10).aspx


Therefore, one major cause of duplicate zones is not waiting for the zone to AUTOMATICALLY populate after you install DNS on a newly promoted domain controller. When an administratore promoted the new server, the administrator may have thought that after installing DNS, they would have to manually create the current AD zone. This is a HUGE mistake. If the zone is AD integrated, you simply allow the new DC to replicate (such as go to lunch, or wait at least 20 minutes), otherwise you WILL introduce a duplicate zone if you manually create a zone that already exists on the other domain controllers because AD replication put it there.


In summary, if an administrator manually created a current AD Integrated zone, possibly thinking to quicken the replication process, you’ve just introduced a duplicate zone.


To understand what this is, how it may have occured, and how to fix it, please read my blog on this subject:


Using ADSI Edit to Resolve Conflicting or Duplicate AD Integrated DNS zones
Published by acefekay on Sep 2, 2009 at 2:34 PM  2313  0
http://msmvps.com/blogs/acefekay/archive/2009/09/02/using-adsi-edit-to-resolve-conflicting-or-duplicate-ad-integrated-dns-zones.aspx


 Here’s a good article to read:


Oops, our AD Integrated DNS zone’s are missing in Windows 2003!
http://blogs.technet.com/b/networking/archive/2007/05/10/oops-our-ad-integrated-dns-zone-s-are-missing-in-windows-2003.aspx


Scavenging Can Also Cause Records To Disappear


Scavenging settings possibly causing this. If Scavenging is set to less than the recommended default of 7 days, especially if less than 24 hours, or if the record, when created, the checkbox “Delete this record when it becomes stale” for records you want to keep, was not unchecked. To see this setting, the DNS Console’s View must be in Advanced Mode.


Other things to be wary of is if another administrator deleted it. How many administrators have access to the zone?


You can also enable auditing for Directory Services for AD objects to determine and find out who’s deleting anything. You can set it either in the DC’s Directory Security Policy, or in a GPO. Once enabled, then go into the DNS console, zone properties, Security tab, Advanced, enable Auditing for Everyone group.


You can also find the deleted record in the AD database. If you want to find the deleted record in the AD database, it is still there. This is because anything in the AD database that gets deleted, gets tombstoned, or another way to put it, marked for deletion. It can be marked one of two ways for deletion: dNSTombstoned and isDeleted.


dNSTombstoned: If a record is deleted in the MMC for dnsmgmt.msc the object still exists but dns.exe will no longer load the value.


isDeleted: isDeleted is the AD “tombstone” for the deletion of the object from the AD.


The following was quoted from:
DNS Concepts
http://dnsfunda.blogspot.com/


“Once we determine if the DNS recored is dNSTombstoned or AD tombstoned we then use “repadmin /showmeta,” which will show us the time/date that each attribute for this object was created, edited, or marked for deletion. This shows the originating source DC of this change. From there we may be able to determine who/what was on that source DC at the time.”


Read the following article in conjunction with the steps I’ve provided below it, in its entirety for complete information on how to determine who deleted the object, and how to enable auditing for DNS objects.


Auditing a DNS Zone
http://blogs.technet.com/b/yuridiogenes/archive/2008/03/06/auditing-a-dns-zone.aspx


Active Directory Domain Services (AD DS) Auditing Step-by-Step Guide
Mar 15, 2010 … In Microsoft® Windows® 2000 Server and Windows Server 2003 …
http://technet.microsoft.com/en-us/library/cc731607(v=ws.10).aspx


 


Who or what account created Records?


How to find who manually created host records in Secure DNS Zones
http://networkadminkb.com/kb/Knowledge%20Base/DNS/How%20to%20find%20who%20manually%20created%20host%20records%20in%20Secure%20DNS%20Zones.aspx



How To Enable DNS Auditing


Enabling DNS Auditing


One way to find out if someone is manually deleting records as I mentioned, whether intentionally or unintentionally, is to enable DNS auditing. This feature is only available on AD integrated zones, and not Standard Primary Zones. This is because once a zone is AD Integrated, it is now part of the AD database, therefore is controlled by AD Security.


If enabling Audting does not help to find who’s deleting them, then the problem is more than likely a duplicate zone issue. I would suggest the easy way to troubleshoot this is to first see if there are duplicate zones. This is because you’ll be waiting for events to be logged and needing to sort through them to find who’s deleting them, if in fact that is the problem. Therefore, the easiest course of action is to first determine if there are any duplicates, and if there are, to go through the procedure in my Duplicate Zones blog to delete them.



To enable DNS Auditing, you would enable AD Directory Services access auditing



1. Enable Directory Service Access auditing in your default Domain Policy:


a) Edit the Domain Security Policy
b) Navigate to Local Policies -> Audit Policy
c) Define ‘Audit directory service access’ for success and failure
d) Refresh the policy on all Domain Controllers


2. Enable auditing on the DNS zone if the zone is in the DomainDnsZones partition:


a) Open ADSIEdit (Start, Run, adsiedit.msc)
b) Right-click ADSI Edit, and connect to the DC=DomainDnsZones,DC=<domain>,DC=<top level domain> container
c) Expand MicrosoftDNS, and navigate to the location of the DNS zone
d) Right-click the zone and choose Properties
e) On the Security tab, click the Advanced button
f) Select the Auditing tab, and click Add
g) Under User or Group, type in Everyone
h) On the Object tab, select Success and Failure for access types Write All Properties, Read All Properties, Delete, and Delete Subtree


3. Enable auditing on the DNS zone if the zone is in the ForestDnsZones partition:


a) Open ADSIEdit (Start, Run, adsiedit.msc)
b) Right-click ADSI Edit, and connect to the DC=DomainDnsZones,DC=<domain>,DC=<top level domain> container
c) Expand MicrosoftDNS, and navigate to the location of the DNS zone
d) Right-click the zone and choose Properties
e) On the Security tab, click the Advanced button
f) Select the Auditing tab, and click Add
g) Under User or Group, type in Everyone
h) On the Object tab, select Success and Failure for access types Write All Properties, Read All Properties, Delete, and Delete Subtree


4. Enable auditing on the DNS zone if the zone is in the Domain Name Context. In Windows 2000, it’s called the DomainNC partition, and with Windows 2003 or newer, it’s called the Default Naming Context:


a) Open ADSIEdit (Start, Run, adsiedit.msc)
b) Right-click ADSI Edit, and in the drop-down box, connect to either the DomainNC or the Default Naming Context (whichever option shows up)
c) In ADSI Edit, rt-click ADSI Edit, choose “Connect To,” in the Connection Point click on “Well known Naming Context”, then in the drop-down box, select “Domain”.  If this is Windows 2003 or newer, this option shows up as “Default Naming Context”
d) Expand DomainNC or Default Naming Context, then expand your domain name.
e) Drill down to CN=System.
f) Click on CN=MicrosoftDNS.
g) You will see any zones that are in the DomainNC partition under the MicrosoftDNS folder.
h) Right-click the zone and choose Properties
i) On the Security tab, click the Advanced button
j) Select the Auditing tab, and click Add
k) Under User or Group, type in Everyone
l) On the Object tab, select Success and Failure for access types Write All Properties, Read All Properties, Delete, and Delete Subtree


3. When a record is changed from DNS, Event ID such as 566 will be logged in the Security Event Log on the related DC.


 


I hope you find this helpful!


Suggestions, comments and corrections are welcomed!


Ace Fekay

Leave a Reply