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管理员在解决这些问题时节省很多时间和精力。