审核丢失的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记录进行审核的方法 。

本博文仅供参考，微软公司对其内容不作任何责任担保或权利赋予。