计算机id dns知识,DNS 事件 ID 4013 疑难解答 - Windows Server | Microsoft Docs

DNS 事件 ID 4013 (DNS 服务器无法加载与 AD 集成的 DNS 区域)

09/08/2020

本文内容

本文解析在 DNS 服务器角色启动后承载 DNS 服务器角色的域控制器的 DNS 事件日志中记录Windows ID。

适用于：  Windows Server 2012R2

原始 KB 编号：   2001093

症状

在Windows Active Directory 域控制器的基于服务器的服务器上，DNS 服务器角色停止响应 15 到 25 分钟。 This issue occurs after the Preparing network connections message is displayed， and before the Windows logon prompt (Ctrl+Alt+Del) displayed.

以下 DNS 事件 ID 4013 记录在托管 DNS 服务器角色的域控制器的 DNS 事件日志中，这些域控制器在 DNS Windows启动：

Event Type: Warning

Event Source: DNS

Event Category: None

Event ID: 4013

Date: Date

Time: Time

User: N/A

Computer: ComputerName

Description:

The DNS server was unable to open the Active Directory. This DNS server is configured to use directory service information and can not operate without access to the directory. The DNS server will wait for the directory to start. If the DNS server is started but the appropriate event has not been logged, then the DNS server is still waiting for the directory to start.

For more information, see Help and Support Center at https://go.microsoft.com/fwlink/events.asp.

Data:

0000:

在此日志条目中，值无法记录。 或者，它们包括但不限于以下值：

十六进制

字节

小数

符号

错误字符串

000025f5

f5 25 00 00

9717

DNS_ERROR_DS_UNAVAILABLE

目录服务不可用

0000232d

2d 23 00 00

9005

DNS_ERROR_RCODE_REFUSED

DNS 操作被拒绝。

0000232a

2a 23 00 00

9002

DNS_ERROR_RCODE_SERVER_FAILURE

DNS 服务器故障。

示例客户方案

Active Directory 站点中同时重新启动的多个域控制器。

两个域控制器域控制器部署在同一个数据中心中。

DNS 服务器角色安装在两个域控制器上，并托管与 AD 集成的 _msdcs。 和 Active Directory 域区域。

DC1 配置为将 DC2 用于首选 DNS，将自身用于备用 DNS。

DC2 配置为将 DC1 用于首选 DNS，将自身用于备用 DNS。

所有域控制器都提供不间断电源， (UPS) 和电力生成器备份。

数据中心经常发生 2 到 10 小时的断电。 UPS 设备使域控制器保持运行状态，直到生成器提供电源，但它们无法运行该系统。 内置于服务器类计算机的温度保护在内部温度达到制造商限制时关闭域控制器。

最终恢复电源后，域控制器将挂起 20 分钟。 This issue occurs after Preparing network connections is displayed， and before the logon prompt is displayed.

DNS 事件 ID 4013 记录在 DNS 事件日志中。

打开 DNS 管理控制台 (DNSMGMT。MSC) 失败并生成以下错误消息：

无法 与服务器联系。 错误为：服务器不可用。 是否继续添加它？

在 DSA 中打开"Active Directory 用户和计算机 (管理单元。MSC) 生成以下错误消息：

无法找到命名信息

Active Directory 站点中的单个域控制器

一个域控制器部署在站点中。

安装了 DNS 服务器角色，并托管与 AD 集成的服务器_msdcs。 和 Active Directory 域区域。

对于首选 DNS，域控制器指向自身。

域控制器没有指定备用 DNS 服务器，也没有指向通过广域网或 WAN (链接) 域控制器。

域控制器因断电而重新启动。

重新启动期间，WAN 链接可能无法运行。

域控制器启动后，可能会挂起 20 分钟。 This issue occurs after Preparing network connections is displayed， and before the logon prompt is displayed.

DNS 事件 ID 4013 记录在 DNS 事件日志中。

打开 DNS 管理控制台 (DNSMGMT。MSC) 失败并生成以下错误消息：

无法 与服务器联系。 错误为：服务器不可用。 是否继续添加它？

在 DSA 中打开"Active Directory 用户和计算机 (管理单元。MSC) 生成以下错误消息：

无法找到命名信息。

原因

某些域控制器中的 Active Directory 副本包含对林中其他域控制器的引用。 这些域控制器尝试在启动期间入站复制所有本地Windows分区，作为初始同步或初始同步的 一部分。

在尝试使用最新的 DNS 区域内容启动时，托管与 AD 集成的 DNS 区域副本的 Microsoft DNS 服务器在 DNS 服务启动后将 DNS Windows几分钟。 如果 Active Directory 在启动期间完成了初始同步，Windows发生。 同时，Active Directory 会延迟入站复制目录分区。 复制将延迟，直到它可以将源域控制器的 CNAME GUID 解析为目标域控制器用于名称解析的 DNS 服务器的 IP 地址。 准备网络连接时挂起的持续时间取决于驻留在域控制器的 Active Directory 副本中的本地保留目录分区的数量。 大多数域控制器至少具有以下五个分区：

schema

configuration

domain

林范围的 DNS 应用程序分区

域范围的 DNS 应用程序分区

这些域控制器可能会遇到 15-20 分钟的启动延迟。 存在额外分区会增加启动延迟。

DNS 事件日志中的 DNS 事件 ID 4013 指示 DNS 服务启动延迟。 这是因为未发生 Active Directory 分区的入站复制。

多个条件可能会解决以下问题：

启动Windows较慢

DNS 服务器上配置为托管 AD 集成区域(隐式驻留在充当域控制器的计算机上)上的 DNS 事件 4013 的日志记录。

这些条件包括：

配置托管 AD 集成 DNS 区域 DNS 服务器的 DNS 服务器。 其 Active Directory 副本包含林中其他域控制器的知识，以专门指向自身进行 DNS 名称解析。

配置托管 AD 集成 DNS 区域 DNS 服务器的 DNS 服务器。 其 Active Directory 副本包含林中其他域控制器的知识，这些域控制器指向以下 DNS 服务器：不存在、当前处于脱机状态、无法通过网络访问，或者没有托管入站复制 Active Directory 所需的区域和记录。 示例包括域控制器 CNAME GUID 记录及其潜在源域控制器的相应主机 A 或 AAAA 记录。

启动托管 AD 集成 DNS 区域域控制器和 DNS 服务器。 其 Active Directory 副本包含有关实际上是隔离网络的其他域控制器的知识，这是因为：

呼叫者或目标计算机上网络适配器或网络堆栈已禁用或不起作用。

域控制器已在隔离网络上启动。

本地域控制器的 Active Directory 副本包含对网络上不再存在的过时域控制器的引用。

本地域控制器的 Active Directory 副本包含对当前处于关闭状态的其他域控制器的引用。

源域控制器、目标域控制器或 DNS 或网络基础结构存在问题。 因此，本地域控制器的 Active Directory 副本包含对联机且可访问但无法成功复制的其他域控制器的引用。

在 Windows Server 2003 和 Windows 2000 Server SP3 或更高版本中，承载操作主机角色的域控制器还必须在维护操作主机角色状态的目录分区上成功复制入站更改。 必须先成功复制，然后才能执行与 FSMO 相关的操作。 添加了此类初始同步，以确保域控制器已就 FSMO 角色所有权和角色状态达成一致。 FSMO 角色正常运行所需的初始同步要求与本文讨论的初始同步不同，其中 Active Directory 必须入站复制才能立即启动 DNS 服务器服务。

解决方案

一些 Microsoft 和外部内容建议将注册表值设置为 Repl Perform Initial Synchronizations 0， 以绕过 Active Directory 中的初始同步要求。 特定的注册表子项和该设置的值如下所示：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

值名称：Repl Perform Initial Synchronizations

值类型：REG_DWORD

值数据：0

建议不要持续在生产环境或任何环境中使用此配置更改。 应仅在 Repl Perform Initial Synchronizations 关键情况下使用 ，以解决临时和特定问题。 在解决这些问题后，应还原默认设置。

其他可行选项包括：

删除对过时域控制器的引用。

使脱机或非正常运行的域控制器可以运行。

托管集成 AD 的 DNS 区域域控制器不应指向单个域控制器，而应该仅指向自己作为名称解析的首选 DNS。

域控制器的 DNS 名称注册和名称解析是相对轻量级的操作，由 DNS 客户端和服务器高度缓存。

将域控制器配置为指向单个 DNS 服务器的 IP 地址(包括 127.0.0.1 环回地址)表示单个故障点。 此设置在仅具有一个域控制器的林中是可容忍的，但在具有多个域控制器的林中则不允许。

对于首选和备用 DNS 服务器，中心站点域控制器应指向同一站点中的 DNS 服务器，最后指向自身作为另一台备用 DNS 服务器。

分支站点域控制器应配置首选 DNS 服务器 IP 地址以指向中心站点 DNS 服务器，将备用 DNS 服务器 IP 地址配置为指向站点内 DNS 服务器或最接近的可用站点中的 DNS 服务器，最后使用 127.0.0.1 环回地址或当前静态 IP 地址自行访问。

指向中心站点 DNS 服务器可以减少完全注册关键域控制器 SRV 和 HOST 记录所需的跃点数。 中心站点内的域控制器往往得到最多的管理关注，通常在同一站点中拥有域控制器的最大集合。 由于它们在同一站点中，因此将相互复制更改：

在 Windows Server 2003 或更高版本中每 15 秒

Windows 2000 Server 中每五分钟

此行为使此类 DNS 记录众所周知。

如果分支站点中注册的域控制器无法出站复制，动态域控制器 SRV 和主机 A 和 AAAA 记录注册可能无法使其关闭。

成员计算机和服务器应继续指向站点最佳 DNS 服务器作为首选 DNS。 它们可能指向外部 DNS 服务器，以提供额外的容错能力。

最终目标是防止一切内容导致拒绝服务，同时平衡成本、风险和网络利用率，例如：

复制延迟和复制失败

硬件故障、软件故障

操作实践

短期和长期断电

火灾、盗窃、淹没和火灾

一些事件

例如，请确保目标域控制器可以使用 DNS (解析源域控制器，避免回退) 。

应确保域控制器可以成功解析引导式 CNAME 记录，以托管当前和潜在的源域控制器的记录。 这样做可以避免名称解析回退逻辑引入的高延迟。

域控制器应指向 DNS 服务器：：

在启动时Windows可用。

托管、转发或委派_msdcs。 和当前和潜在的源域控制器的主 DNS 后缀区域。

可以解析当前 CNAME GUID 记录 (例如，) 和可能的源域控制器的托管 dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com 记录。

缺少、重复或过时的 CNAME 和主机记录都会导致此问题。 默认情况下，Microsoft DNS 服务器上未启用清理，这增加了主机记录过期的可能性。 同时，DNS 清理可以配置得过于积极，从而导致从 DNS 区域提前清除有效记录。

针对名称解析回退优化域控制器。

无法正确配置 DNS 以便域控制器可以解析域控制器 CNAME GUID 记录以托管 DNS 中的记录很常见。 为了确保 Active Directory 分区的端到端复制，Windows Server 2003 SP1 和更高版本的域控制器进行了修改，以执行名称解析回退：

从域控制器 CNAME GUID 到完全限定的主机名。

从完全限定的主机名到 NetBIOS 计算机名称。

目录服务事件日志中的 NTDS 复制事件 ID 2087 和 2088 指示：

目标域控制器无法将域控制器 CNAME GUID 记录解析为主机记录。

名称解析回退发生。

可以配置 WINS、HOST 文件和 LMHOST 文件。 因此，目标域控制器可以解析当前和潜在的源域控制器的名称。 在三个解决方案中，WINS 的使用更具可扩展性，因为 WINS 支持动态更新。

计算机的 IP 地址和名称可能会变得过时。 此问题会导致 HOST 和 LMHOST 文件的静态条目在一段时间变得无效。 出现此问题时，一个域控制器的查询可能未正确解析为另一个域控制器。 网络跟踪中未观察到任何名称查询。

如果启动到已知的错误配置，将 DNS 服务器服务的启动值更改为手动。

如果在本文讨论的已知错误配置中启动域控制器，请按照以下步骤操作：

将 DNS 服务器服务启动值设置为手动。

重新启动，等待域控制器播发。

重新启动 DNS 服务器服务。

如果 DNS 服务器服务的服务启动值设置为手动，则 Active Directory 不会等待 DNS 服务器服务启动。

其他注意事项

避免单点故障。

单个故障点的示例包括：

将 DC 配置为指向单 DNS 服务器 IP

将所有 DNS 服务器放在同一物理主计算机的来宾虚拟机上

将所有 DNS 服务器放在同一物理站点中

限制网络连接，使目标域控制器只有一个网络路径来访问 KDC 或 DNS 服务器

安装足够的 DNS 服务器以实现本地、区域和企业范围的冗余性能，但不要安装太多 DNS 服务器，这样管理就会成为负担。 DNS 通常是 DNS 客户端和 DNS 服务器高度缓存的轻型操作。

在新式硬件上运行的每个 Microsoft DNS 服务器每台服务器可满足 10，000-20，000 个客户端的要求。 在域控制器上安装 DNS 角色可能会导致企业中 DNS 服务器过多。 这样做会增加成本。

如果可能，错开企业中 DNS 服务器的重新启动。

安装某些修补程序、Service Pack 和应用程序可能需要重新启动。

某些客户每七天(每 30 (30 天)按计划重新启动) 。

以智能方式安排重启以及需要重新启动的软件的安装。 这样做是为了防止同时重新启动目标域控制器指向的唯一 DNS 服务器或潜在的源复制合作伙伴进行名称解析。

如果Windows或管理软件正在安装需要重新启动的软件，请错开目标域控制器上的安装，以便域控制器指向的一半可用的 DNS 服务器同时重新启动名称解析。

在战略位置安装 UPS 设备，以确保 DNS 在短期断电期间的可用性。

使用现场生成器扩充支持 UPS 的 DNS 服务器。

为了应对长时间中断的问题，一些客户部署了现场电力生成器以保持关键服务器联机。 一些客户发现生成器可以在数据中心为服务器提供电源，但不能为现场的 DNS 提供电源。 缺少空调可能会导致本地服务器在内部计算机温度达到特定阈值时关闭。

更多信息

2010 年 5 月 10 日由 Active Directory 开发团队测试：

DNS 等待 NTDS，在目录的初始复制完成之前无法启动。 这是因为最新的 DNS 数据可能尚未复制到域控制器。 另一方面，NTDS 需要 DNS 解析用于复制的源域控制器的 IP 地址。 假定 DC1 指向 DC2 作为 DNS 服务器，DC2 指向 DC1 作为其 DNS 服务器。 当 DC1 和 DC2 同时重新启动时，由于相互依赖关系，启动速度将变慢。 导致启动速度缓慢的根本原因是 DNSQueryTimeouts。

如果 DNS 服务器服务在 NTDS 启动时运行良好，则 NTDS 只需执行两个 DNS 查询来解析源域控制器的 IP 地址：

一个针对 IPv4

另一个适用于 IPv6

这些 DNS 查询几乎瞬时返回。

如果 NTDS 启动时 DNS 服务器服务不可用，NTDS 将需要发送 10 个 DNS 查询来解析 IP 地址：

四表示基于 GUID 的名称

四表示完全限定名称

两个表示单标签名称

每个 DNS 查询的延迟由 DNSQueryTimeouts 控制。 默认情况下，DNSQueryTimeouts 设置为 1 1 2 4 4。 这意味着 DNS 客户端将等待 12 (1 + 1 + 2 + 4 + 4) 秒进行 DNS 服务器响应。 每个命名上下文源需要 120 秒来解析 IP 地址。 假定存在五个命名上下文， (Configuration、Schema、domain、ForestDnsZones、DomainDnsZones) 和一个复制源。 在此方案中，NTDS 需要 850 (170 X 5) 秒或超过 14 分钟才能完成初始复制。

已执行多个测试来验证上述行为。

当 DNS 服务器是联机的第三个域控制器时重新启动域控制器。 对于每个源的每个命名上下文，我们都有两个 DNS 查询，它们几乎瞬时完成：

in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com

in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com

in resolveDnsAddressWithFallback

GUID based DNS name

in GetIpVxAddrByDnsNameW

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 22:31:40.534

end GetAddrInfoW: 22:31:40.534

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 22:31:40.534

end GetAddrInfoW: 22:31:40.534

同时重新启动 DC1 和 DC2。 DC1 将 DC2 用于 DNS DC2，而 DC1 用于 DNS。 对于每个源的每个命名上下文，我们有 10 个 DNS 查询，每个查询大约需要 12 秒：

in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com

in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.microsoft.com

in resolveDnsAddressWithFallback

GUID based DNS name

in GetIpVxAddrByDnsNameW

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 22:37:43.066

end GetAddrInfoW: 22:37:55.113

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 22:37:55.113

end GetAddrInfoW: 22:38:07.131

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 22:38:07.131

end GetAddrInfoW: 22:38:19.161

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 22:38:19.176

end GetAddrInfoW: 22:38:31.185

FQDN

in GetIpVxAddrByDnsNameW

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 22:38:31.200

end GetAddrInfoW: 22:38:43.182

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 22:38:43.182

end GetAddrInfoW: 22:38:55.191

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 22:38:55.191

end GetAddrInfoW: 22:39:07.216

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 22:39:07.216

end GetAddrInfoW: 22:39:19.286

NetBios

in GetIpVxAddrByDnsNameW

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 22:39:19.286

end GetAddrInfoW: 22:39:31.308d

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 22:39:31.308

end GetAddrInfoW: 22:39:43.324

为了进一步研究 DNSQueryTimeouts 与慢速启动之间的关系，DNSQueryTimeouts 设置为 1 1 2 4 4， 使 DNS 客户端等待 31 (1 + 1 + 2 + 4 + 4) 秒。 在此测试中，等待了 31 秒：

in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com

in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com

in resolveDnsAddressWithFallback

GUID based DNS name

in GetIpVxAddrByDnsNameW

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 18:06:48.143

end GetAddrInfoW: 18:07:19.158

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 18:07:19.158

end GetAddrInfoW: 18:07:50.162

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 18:07:50.162

end GetAddrInfoW: 18:08:21.161

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 18:08:21.161

end GetAddrInfoW: 18:08:52.158

FQDN

in GetIpVxAddrByDnsNameW

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 18:08:52.221

end GetAddrInfoW: 18:09:23.231

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 18:09:23.231

end GetAddrInfoW: 18:09:54.243

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 18:09:54.243

end GetAddrInfoW: 18:10:25.239

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 18:10:25.239

end GetAddrInfoW: 18:10:56.243

NetBios

in GetIpVxAddrByDnsNameW

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 18:10:56.243

end GetAddrInfoW: 18:11:27.244

in GetIpAddrByDnsNameHelper

start GetAddrInfoW: 18:11:27.244

end GetAddrInfoW: 18:11:58.265