审核丢失的DNS记录
经常会有客户提出这样的问题，我的一条或者一批DNS记录无缘无故丢失了，有没有什么办法知道是怎么丢失? 如果客户没有事前启用对DNS区域或者记录的审核，就很难给出一个确切的答案。本文主要介绍如何对DNS进行审核，从而在记录丢失的时候，可以找到合理的线索。对其他操作(例如‘读’)的审核也类似。本文针对AD集成的DNS 区域(zone) 进行讨论，这在大型的企业AD环境中更普遍。
在介绍审核方法之前，让我们先热热身，了解一些背景知识。
DNS记录丢失的常见原因
DNS记录的丢失，通常有如下几种情况：
1 管理员的误删除
2 DNS客户端注销记录
3 记录老化，被DNS服务器scavenging机制删除
在一个大型的AD环境中，一个难点便是上述问题可能发生在任何一台DNS/DC上，然后删除的动作通过AD复制到所有DNS/DC上。例如国外的管理员在其管辖的DC上误删除了一条记录，同一个域内中国的DNS/DC收到了这个结果，影响了国内的某个应用程序。这样的案例时有发生。 这时，要避免这样的问题，首先要知道记录是怎么被删除的以及何时何地被删除的。这离不开DNS的审核功能以及对AD的元数据的检查。
AD中DNS的区域复制范围
谈下一个环节之前，让我们重温一下AD集成的DNS区域的复制范围及其在AD中的存储位置。AD集成的DNS域默认有三个复制范围，分别为：
Active Directory 林中的所有 DNS 服务器 (To all DNS servers in the Active Directory forest ...)
Active Directory 域中的所有 DNS 服务器 (To all DNS servers in the Active Directory domain ...)
Active Directory 域中的所有域控制器 (To all domain controllers in the Active Directory domain ...)
对区域复制的介绍，可以参考 https://technet.microsoft.com/zh-cn/library/cc779655(WS.10).aspx. 三种不同的区域复制范围，决定了这个DNS区域在AD中实际存储的位置，我们可以使用adsiedit这个工具来查看。限于篇幅，这里不在对adsiedit这个工具作进一步的介绍，有兴趣的读者可以参考 https://technet.microsoft.com/zh-cn/library/cc773354(WS.10).aspx 以及https://technet.microsoft.com/zh-cn/library/cc757121(WS.10).aspx
复制范围为Active Directory 林中的所有 DNS 服务器的DNS区域，其存储位置对应 dc=forestdnszones, dc=xxx, dc= xxx 下的CN=MicrosoftDNS目录下. 以根域corpa.local为例，对应位置为dc=ForestDnsZones, dc=corpa, dc=local.如果有这种复制范围的区域，就会出现在如下图所示的CN=MicrosoftDNS下面了
复制范围为Active Directory 域中的所有 DNS 服务器DNS区域，其存储位置对应dc=domaindnszones, dc=xxx, dc=xxx下的CN=MicrosoftDNS目录下。以域corpa.local为例，对应位置为dc=domaindnszones, dc=corpa, dc=local.如果有这种复制范围的区域，就会出现在如下图所示的CN=MicrosoftDNS下面了。
复制范围为Active Directory 域中的所有域控制器的DNS区域，其存储位置对应CN=System, DC=xxx, DC=xxx下的CN=MicrosoftDNS目录下。以域corpa.local为例，对应位置为CN=System,DC=corpa, DC=local.如果有这种复制范围的区域，就会出现在如下图所示的CN=MicrosoftDNS下面了。
启用审核的步骤
接下去我们看看启用审核的步骤：
1 首先我们要启用对目录服务访问的审核：
1) 在DC上，选择"Domain Controller Security Policy"
2) 启用 "Audit directory service access"这条审核规则,审核成功的访问即可.
这步建议在对应的组策略中进行配置，这样所有DC均可应用这条规则
2 在具体的某条DNS记录或者DNS区域上启用审核。这里以某条DNS记录为例，对整个区域的审核类似：
1)在某条DNS记录上右击，选中Property -Security -Advanced-Auditing.
2)对Everyone的如下访问进行审核
经过上述两步，在某条DNS记录上的审核已经被启动了。
注意，审核日志会输出在系统安全日志中，请将安全日志设置合理的大小，确保日志不会过快被覆盖。具体大小要视实际环境而定。
DNS记录丢失后的审查
1 DNS记录丢失后，一般只是DNS记录对应的AD Object中的两个属性(dnsTombstoned和dnsRecord)被修改了，而其AD元数据并不一定丢失。所以第一步工作是查看这条DNS记录在AD中的元数据，看看最后一次修改的时间和地点。
这里需要用工具repadmin来导出AD中的元数据。Repadmin的介绍，可以参考 https://technet.microsoft.com/en-us/library/cc755360(WS.10).aspx 和 https://technet.microsoft.com/en-us/library/cc770963(WS.10).aspx
假设丢失的记录是区域corpa.local下的abc,并且这个区域的复制范围是"Active Directory 域中的所有域控制器"，则使用如下命令导出元数据。
Repadmin /showobjmeta localhost "DC= abc,DC=corpa.local,CN=MicrosoftDNS,CN=System,DC=corpa,DC=local" > meta.txt
如果复制范围不同，需要根据之前介绍的不同复制范围对应的不同AD位置来替代上述的黄色部分
命令执行完后打开meta.txt,可以看到dnsRecord和dnsTombstoned最后一次修改的时间和 位置 。如下图修改时间为2009-08-12 15:02:48,这次修改发生在PSITESERVERDC这台服务器上.
2 找到对应的服务器及对应时间点，查看安全日志-审核日志的输出会在其中，以windows 2003为例，事件号 (Event ID) 为566. Windows 2008 R2中类似事件的event ID为5136 :
从示例的日志看，问题的原因是Administrator这个账号删除了这条DNS记录。可以进一步咨询登陆这个账号的用户是否删除了这条记录。
也有一些情况下，我们发现删除DNS记录的账号是系统账号(system)，或者DNS服务运行使用的服务账号。这种情况往往说明这条记录是DNS服务收到了某种信号以后才被删除的。根据经验一般有两种情况
1 DNS客户端注销记录。这种情况下，我们往往还要启用DNS的Debug日志来进一步的分析DNS是否收到了注销请求，并查明这个请求来自何处。
审核日志可以帮助我们找到需要查看的服务器和需要查看的时间点，这样在查看DNS的Debug日志时可以很快找到线索。当然，要进一步排查DNS客户端为什么这么做，就又要根据实际情况来分析了。这种情况下又包含了很多种可能，例如一些三方服务或者监控软件/硬件注销了记录等。
2 DNS服务器老化机制删除了记录。这种情况下，我们应该在找到发生最后一次修改的DNS服务器后，检查这个时间点DNS事件日志中是否有对应发生scavenging的事件。如果确实有，则可以认为是老化机制导致。接下去就要查看老化参数是否设置合理，例如 refresh,
no-refresh interval是否设置得太小，或者被删除的记录是否动态注册都成功等。
上述两种情况又会有很多种不同原因导致，限于篇幅，我们会另文详述，这里主要介绍一下对DNS记录进行审核的方法 。
本博文仅供参考，微软公司对其内容不作任何责任担保或权利赋予。