如何找到消失的DNS记录？

Windows活动目录应用的多主机复制模式的缺点之一就是变更复制很快，小错误可能在短时间内就变成大错误。

域名系统(DNS)的区和记录可能损坏，包含错误的信息甚至消失不见了。

找到删除的DNS记录

DNS记录可以人工删除，某些操作可以导致这个结果，比如DC降级或其它对象清除，当然，DNS记录也可以程式地删除。记住，该记录和所有AD对象一样，可以在任意DC/DNS服务器上删除，并且这会复制到所有DC。追踪的方式之一是找到被删除的对象，然后查看元数据。所有DC上的内置LDP.exe工具对该操作都很有帮助。

另外，找出AD上的DNS记录要根据复制范围。这些位置如下。表1显示陈列DNS记录的LDP工具。记住，DNS记录只会显示这三个位置中的一个。

表1：AD中的复制范围位置

当对象被删除时，它们被放在“删除对象”文件夹，如图1所示。但是删除的DNS对象存储在其它DNS记录存储的库中。例如，在图2中，我们看见存储在DC=DomainDNSZones库中的DNS记录，但是其中它也有“删除对象”库。

图1：删除对象

图2：DNS记录列表

记住：想要显示删除对象文件夹(默认情况下隐藏在LDP.exe中)，做法如下：

在LDP.exe工具中，连接到一个DC并绑定管理员证书

进入选项-控制，在“预定义负载”区域选择 “还原删除对象”。

通过选择“树-(域名)-完成”刷新

展开DC=deletedObjects、dc=domainDNSzones…库，删除的DNS对象就显示了(图3)。在这种情况下，我们感兴趣的记录是“DC=_dcdiag_test_record…”。在这个例子中重建了很多次。注意，在图3中，在LDP(右边板)中显示的属性没有什么帮助。

该命令用以下格式：

Reapadmin /showobjmeta DCName ObjectDN

所以在这个例子中，我们从LDP工具中得到了ObjectDN并这样插入它：

C:Usersolseng>repadmin /showobjmeta wtec-dc4 "dc=_dcdiag_test_recordADEL:ba38f888-9314-4ddf-852d-736db6ae181e,cn=deleted objects,dc=domaindnszones,dc=wtec,dc=adapps,dc=hp,dc=com" >dnsdelete.txt

图3：删除的DNS对象

我想要它直达一个文件来让它使用起来更简单。输出如图4所示。注意，红线圈起来的部分是属性。该属性在对象删除时建立。同时显示的还有初始DC的GUID和时间标记。GUID可以通过在DNS管理单元上的CNAME记录里查看或运行解析成DC名称。DC名称通常显示的不会是GUID。现在删除记录的时间、它何时在哪个DC上执行都很明显了。这对于解开记录消失之谜有所帮助。

图4：被删除DNS记录的输出

DNS记录消失了!不要慌张，没有这么可怕，你首先要做的是找到不见的DNS记录(上文所述)，现在你已经镇定了些，那么就和我们一起来看看如何修复消失的DNS记录吧!

修复“损坏”或错误的DNS记录

如果DNS记录损坏或者没有及时更新，可以用动态注册来轻松地修复问题。例如，用于映射服务器GUID到服务器FQDN的DNS别名记录常用于AD复制。恢复或重装DC可能导致复制了没有清理老记录的别名记录。如果有多个别名记录，或该记录是错误的，那么删除这些问题记录，服务器会重新登录正确的记录。这通常花费15分钟，但是你可以重启Netlogon服务来更快地反馈。记住刷新DNS管理单元来查看新记录。所有记录类型都能用这种方法来注册正确的记录。

修复“消失”DNS区

一名管理员正在试着从DC上清除DNS。他错误地从该DC上的单元处删除了DNS区。他忽略了这会从AD上移除区的警告。几分钟内，整个生产DNS区都不见了…天啊!消失了!他正在思量着寻找下一份工作，但是我向他保证这可以轻松修复，这多亏了动态注册。我们简单地重建了DNS区，在每个DC上重启Netlogon，然后区就重新构成了。有一些静态A记录必须要手动输入，但是他拥有这些信息。我并不建议这作为一个解决方法，但是当整个区被清洗(有意义记录和名称解析在各台DNS服务器上不一致)时我确实用到它了。删除该区并让DC重新注册。

恢复损坏ADI区

虽然综合活动目录(ADI)基础DNS功能(它在活动目录中存储区文件)比标准DNS更快、更高效，但它也有一些缺点：

区文件不是磁盘上一个简单的文本文件，且只能用访问AD的工具来查看和操作。

不同的复制范围在AD中的不同位置存储区文件，这让定位DNS记录非常困难。

ADI区变“损坏”因为DNS记录不是在所有DC上都一致，给了DNS查询不一致的结果。

假设你不想毁掉整个区，如果你怀疑ADI区中有损坏(在域名解析中的不致行为)，有一个很酷的技巧可以让ADI(多基础)重回正轨。

确定一个正确的名称服务器来用作新来源(选取PDC模拟器或查看DNS错误、性能等等)。

进入DNS管理单元-区属性。选择区类型并配置区到标准DNS区(见这里)。通过不选“”在活动目录中存储区“选项可以完成该动作。这将DNS信息从AD转储到该DC硬盘上的文本区文件。

进入另一个DC/名称服务器-DNS管理单元，然后删除该区。这将从活动目录中删除它(会有一提示)。

等待复制然后检查每个DC/名称服务器来确保该区从AD中消失。你也可以运用LDP并查看AD中的3个位置(表1所示)来确保那里没有DNS记录。如果你看到它们，那么你就没有删除该区或者复制没有完成。

当DNS从AD中消失时，让它保持这种配置两三天。现在你拥有一个单一来源(控制)，所以可能不会有不一致。确保所有工作都正常。创建一个指向该名称服务器的标准次级区作为控制是一个不错的主意，那么你在这个过渡期间就能拥有更好的名称解析性能了。

将标准基础更改至ADI区。进入DNS单元-区-属性-输入并检查“在活动目录中存储该区”选项。

在区属性中-复制-选择想要的复制范围。

将次级区更改到ADI区：

在每台名称服务器上从DNS单元删除次级区，重启DNS，它会自动登录。你可能需要在名称服务器上重建该区，然后它会自动完成。

或者重启DC。是的，重启托管次级DNS区的DC，ADI Primary会在它备份时将次级区变更到ADI。

消失的区(故意的)

我曾经遇到过管理员声称自己的DNS区只消失了一段时间(有时是一两天，有时是一周)的情况。查看每个DC/名称服务器上的DNS单元，区消失了。这实际上是故意的，而且是根据以上的七个步骤。在这种情况下，管理员有一个标准的基础-次级配置，并且决定迁移到一个ADI Primary配置。当标准基础区变成ADI基础时，所有DC必须托管一个ADI基础区。他们会在重启前保留次级区，因为该信息在放在内存中。重启后，ADI区会在所有DC/名称服务器上重新构成。

在ADI基础区中拥有次级区是允许的，但是他们必须托管在成员服务器上，而不是在DC上。这让DNS服务器可以放置在不需要DC的远程站点。

虽然多控制复制和综合活动目录(多基础)区功能集优点与缺点于一身，了解它们工作的方式会为AD管理员在解决这些问题时节省很多时间和精力。