DNS 流程和交互

下图显示了完整的 DNS 查询过程的概述。

DNS 查询过程概述

查询过程的初始步骤所示，DNS 域名是在本地计算机上的程序中使用。 请求然后传递到 DNS 客户端服务使用本地缓存的信息的分辨率。 如果可以解析查询的名称，则应答该查询，并在过程完成。

本地解析程序缓存可以包括两个可能的来源获取的名称信息：

• 如果本地配置主机文件，则从该文件的任何主机名称到地址映射加载到缓存中，DNS 客户端服务启动时。
• 在应答来自以前的 DNS 查询的响应中获得的资源记录被添加到缓存并且保留的一段时间。

如果查询与缓存中的项不匹配，则解析过程继续与客户端查询 DNS 服务器来解析名称。

如前面的图中所示，客户端将查询首选的 DNS 服务器。 从全局列表中选择初始客户端/服务器查询中使用的服务器。

当 DNS 服务器收到查询时，它首先检查是否它可以应答查询权威性地根据包含在服务器上的本地配置区域中的资源记录信息，请参阅。 如果查询的名称与本地区域信息中的相应 RR 相匹配，服务器应答不具有权威性，使用该信息来解析查询的名称。

如果没有区域信息存在用于查询的名称，然后，服务器检查到如果它可以解决使用本地缓存的信息，从以前的查询的名称，请参阅。 如果在此处找到匹配项，则服务器将使用此信息应答。 同样，如果首选的服务器可以使用来应答肯定匹配响应从其缓存请求的客户端，查询完成。

如果查询的名称没有找到匹配的应答在首选服务器 — 从其缓存或者区域信息 — 查询过程可以继续，请使用递归来完全解析此名称。 这涉及到其他 DNS 服务器来帮助解析名称的援助。 默认情况下，DNS 客户端服务会询问服务器以完全解析返回应答前的名称代表的客户端使用递归过程。

为了使 DNS 服务器正确执行递归过程，它首先需要一些有用的联系信息有关 DNS 域名称空间中的其他 DNS 服务器。 在窗体的根提示，DNS 服务可用于定位其他 DNS 服务器具有权威性的 DNS 域名称空间树的根的初步 Rr 的列表中提供了此信息。 根服务器是域根和 DNS 域名称空间树中的顶级域的权威。

通过使用根线索查找根服务器，DNS 服务器就能够完成的递归过程。 从理论上讲，此过程使定位具有权威性的任何其他 DNS 域名称空间树中的任何级别使用的服务器的任何 DNS 服务器。

例如，请考虑使用递归过程来找到名称的”主机-b.example.microsoft.com。”当客户端查询一个 DNS 服务器。 DNS 服务器和客户端第一次启动并已没有本地缓存信息可用来帮助解析名称查询时发生该进程。 它假定由客户端查询的名称是域名服务器其中有没有本地知识，根据其配置的区域。

首先，首选的服务器分析全名并确定它需要的顶级域，”com”授权服务器的位置。 然后，它使用迭代查询到”com”DNS 服务器以获取”microsoft.com”服务器的引用。 接下来，参考性应答来自”microsoft.com”服务器到 DNS 服务器为”example.microsoft.com”。

最后，”example.microsoft.com.”服务器被联系。 由于此服务器作为其配置的区域的一部分包含查询的名称，因此它作出权威性地应答回到原始服务器启动递归。 当源服务器接收响应时表明权威性应答已获得对请求的查询，它将返回到发出请求的客户端此应答转发和递归查询过程就完成。

尽管递归查询过程可以是资源密集型时执行按上文所述，它有一些为 DNS 服务器的性能优势。 例如，在递归过程中，执行递归查询的 DNS 服务器获取有关 DNS 域名称空间信息。 此信息由服务器缓存，并可用于再次帮助使用或与之匹配的后续查询的应答速度。 随着时间的推移此缓存的信息可以不断增加并占据很大一部分的服务器内存资源，尽管每次打开和关闭 DNS 服务重启时清除它。

下面的三个数字说明了依据 DNS 客户端查询每个适配器上的服务器的过程。

查询 DNS 服务器，第 1 部分

查询 DNS 服务器，第 2 部分

查询 DNS 服务器，第 3 部分

DNS 客户端服务查询的 DNS 服务器，按以下顺序：

1. DNS 客户端服务的 DNS 服务器的首选的适配器列表上的第一个 DNS 服务器发送名称查询，并等待一秒钟的响应。
2. 如果 DNS 客户端服务没有收到响应，从第一个 DNS 服务器在一秒钟内，它仍在研究当中的所有适配器上的第一个 DNS 服务器发送名称查询，并等待两秒钟，等待响应。
3. 如果 DNS 客户端服务没有收到来自内的任何 DNS 服务器响应两秒，DNS 客户端服务都会向一些仍在考虑的所有适配器上的所有 DNS 服务器发送查询，并等待另一个两秒钟的响应。
4. 如果 DNS 客户端服务仍然没有收到响应来自任何 DNS 服务器，它仍在研究当中的所有适配器上的所有 DNS 服务器都发送名称查询，并等待 4 秒的响应。
5. 如果 DNS 客户端服务没有收到任何 DNS 服务器的响应，DNS 客户端仍在研究当中并等待八秒钟响应的所有适配器上的所有 DNS 服务器都发送查询。

如果 DNS 客户端服务收到一个肯定的响应，它将停止查询的名称、 添加到缓存响应并将响应返回给客户端。

如果 DNS 客户端服务没有收到响应来自任何服务器在 8 秒内，具有超时设置会响应 DNS 客户端服务。 此外，如果它不具有从指定的适配器上的任何 DNS 服务器收到的响应，为下一步的 30 秒，然后 DNS 客户端服务响应发送到服务器，具有超时设置该适配器上的所有查询，不查询这些服务器。

如果在任何点 DNS 客户端服务从服务器接收否定响应，它从考虑此搜索过程中移除该适配器上的每台服务器。 例如，如果在步骤 2 中，备用适配器 A 上的第一个服务器提供给否定响应，DNS 客户端服务将不发送查询给列表中的任何其他服务器为备用适配器 a。

跟踪的哪些服务器应答名称查询速度越快，DNS 客户端服务和它向上移动服务器或向下快速基于如何在列表上他们答复名称查询。

下图显示了如何在 DNS 客户端查询每个服务器上的每个适配器。

多宿主名称解析

前面的 DNS 查询说明假定进程结束肯定地响应返回给客户端。 但是，查询可返回其他的答案。 这些是最常见的查询答案：

• 权威性应答
• 肯定应答
• 参考性应答
• 否定应答

权威性应答是返回到客户端，并随 DNS 消息以指示此应答从带直接授权机构查询的名称服务器获取中设置的颁发机构位提供的肯定应答。

一个肯定的响应可以包含查询 RR 或符合查询的 DNS 域名和查询消息中指定的记录类型 （也称为 RRset) Rr 的列表。

参考性应答包含附加的 Rr 名称或查询中的类型未指定的。 如果不支持递归过程，则这种类型的应答被返回给客户端。 记录旨在充当客户端可以继续使用迭代查询使用的有用的参考答案。 参考性应答包含其他数据 （如除了类型查询的 Rr。 例如，如果查询的主机名是该区域中找到”www”并没有为此名称的 A Rr，但却找到”www”CNAME RR 相反，DNS 服务器可以包括该信息时对客户端的响应。 如果客户端能够使用迭代，它可以使用进行其他查询的参考信息，以求完全解析本身的名称。

从服务器否定响应可以表示两个可能的结果之一时遇到服务器尝试处理和完全并不具有权威性，递归解析查询时：

• 权威性服务器报告查询的名称不存在 DNS 命名空间中。
• 权威性服务器报告的查询的名称已存在，但该名称存在指定类型的任何记录。

冲突解决程序将在两个窗体中的查询结果传递肯定或否定响应，回到申请程序和高速缓存响应。

如果查询的最终应答太长，无法被发送和解析单个 UDP 消息数据包，在 DNS 服务器可以启动一个故障转移通过 TCP 端口 53，从而回答完全在 TCP 客户端的响应连接会话。

禁用 DNS 服务器上的递归过程通常会被限制根据 DNS 客户端的名称解析为一个特定的 DNS 服务器，如在 intranet 上时。 当 DNS 服务器不能解析外部 DNS 名称，并期望客户端故障转移到另一台 DNS 服务器解析这些名称时，可能也会禁用递归。 如果您禁用 DNS 服务器上的递归，您不能在同一台服务器上使用转发器。

默认条件下，DNS 服务器使用多个默认计时时执行递归查询并联系其他 DNS 服务器。 这些默认设置包括：

• 3 秒的递归重试间隔。 这是时间的 DNS 服务在重试递归查询期间所做的查询之前等候长度。
• 8 秒的递归超时间隔。 这是时间的 DNS 服务在失败重试的递归查询之前等候长度。

在大多数情况下，这些参数不需要调整。 但是，如果您正在使用递归查找通过慢速广域网 (wan) 链接，您可能能够通过对设置略作调整提高服务器性能和查询的完成。

迭代是满足以下条件生效时，DNS 客户端和服务器之间使用的名称解析类型：

• 客户端申请使用递归过程，但在 DNS 服务器上禁用递归。
• 查询 DNS 服务器时，客户端不会请求使用递归过程。

从客户端迭代请求告知客户端正在等待最好的应答的 DNS 服务器可以立即提供而无需联系其他 DNS 服务器的 DNS 服务器。

使用迭代时，DNS 服务器应答客户端根据自己特定的知识的命名空间与被查询的名称数据有关。 例如，如果您的 intranet 上的 DNS 服务器收到查询时从”www.microsoft.com”的本地客户端，它可能从其名称缓存返回答案。 如果查询的名称当前未存储在服务器名称缓存中，服务器可能作出响应，从而得到参考信息 — — 即由客户端查询的名称比较接近其他 DNS 服务器的 NS 和 A Rr 列表。

使用迭代时，DNS 服务器可以进一步帮助之外提供自己最好的应答，返回到客户端的名称查询解析。 对于大部分迭代查询，客户端使用其本地配置的 DNS 服务器列表联系整个 DNS 名称空间的其他名称服务器，如果其主 DNS 服务器不能解析查询。

在 Windows 服务器 2008 DNS 客户服务不会执行递归。

DNS 服务器来处理客户端查询使用递归或迭代，它们将发现并获得大量有关 DNS 名称空间的信息。 由服务器然后缓存此信息。

缓存提供一种方法，以加速流行的名称后, 继查询的 DNS 解析的性能，同时大大减少了网络上与 DNS 相关的查询通信。

当 DNS 服务器进行递归查询代表的客户端，它们将暂时缓存资源记录。 缓存的 Rr 包含从学习而进行迭代查询以便搜索和充分应答的递归查询代表执行客户端的 DNS 域名称的权威 DNS 服务器获得的信息。 稍后，当其他客户端发出新的查询，申请与缓存的 Rr 匹配的 RR 信息，DNS 服务器可以使用缓存的 RR 信息来应答它们。

当信息被缓存时，生存时间 (TTL) 值将应用于所有缓存的 Rr。 只要缓存 rr 的 TTL 没有到期，DNS 服务器可以继续缓存并再次使用 RR，应答匹配这些 Rr 其客户端的查询时。 缓存 TTL 值由 Rr 所使用的大部分区域配置中被分配的最小值 （默认） TTL 设置中该区域的起始颁发机构 (SOA) RR。 默认情况下最小 TTL 为 3600 秒 （1 小时），但是可以调整或者，如果需要，可以在每个 RR 设置各自的缓存 Ttl。

下图显示其 IP 地址、 192.168.1.20 了解另一台主机 （主机 a） 的名称基于 DNS 客户端 （主机 b） 可通过启动反向查询的一个示例。

反向查询

此图中所示的反向查询过程发生在下面的步骤：

1. 客户端、”主机-b”，对于映射到 IP 地址 192.168.1.20 的”主机 a”的指针 (PTR) RR 查询 DNS 服务器。因为查询的 PTR 记录，冲突解决程序将反转该地址，并反向地址的结尾追加 in-addr.arpa 域中。 这形成完全限定的域名 (“20.1.168.192.in-addr.arpa.”) 要反向查找区域中搜索。
2. 已经找到后，”20.1.168.192.in-addr.arpa”的权威 DNS 服务器可以响应带有 PTR 记录信息。 这包括域的 DNS 名称”主机-a”，完成反向查找。

请记住，如果查询的反向名称不是从 DNS 服务器具有权威、 正常的 DNS 解析 （递归或迭代） 可以用于定位 DNS 服务器的反向查找区域的权威且包含查询的名称。 在这种意义上，反向查找中使用的名称解析过程是相同的正向查找。

下图阐释了如何外部名称查询被转发使用转发器。

使用转发器定向外部名称查询

而无需特定的 DNS 服务器指定为转发器，所有 DNS 服务器可以都发送查询使用它们的根目录提示的网络之外。 结果是，大量的内部，而且也可能是关键的 DNS 信息可以在 Internet 上公开。 除了此安全和隐私问题，这种解决方法可能会导致大量的成本高昂而且效率低下与 Internet 连接速度缓慢的网络连接或具有较高的互联网服务成本的公司的外部通信。

当您指定作为转发器的 DNS 服务器时，您使该转发器负责处理外部通信，因此限制了到 Internet 的 DNS 服务器的风险。 转发器将建立外部 DNS 信息的巨大缓存，因为所有网络中的外部 DNS 查询都是通过它来解析。 在较短的时间内，转发器将解决使用此缓存的数据的外部 DNS 查询的精华部分，从而通过网络和响应时间可为 DNS 客户端减少互联网通信。

从没有配置为使用转发器的 DNS 服务器的 DNS 服务器配置为使用转发器将行为不同。 DNS 服务器配置为使用转发器的行为如下：

1. 当 DNS 服务器收到查询时，它会尝试解析此查询使用承载的主要和辅助区域和它的高速缓存。
2. 如果不能使用该本地数据解析查询，然后它会将查询转发到指定为转发器的 DNS 服务器。
3. DNS 服务器将尝试联系它的根提示中指定的 DNS 服务器之前短暂等待来自该转发器的应答。

当 DNS 服务器将查询转发给转发器时它会递归查询发送到转发器。 这与不同的迭代查询 DNS 服务器将在标准名称解析 （不涉及转发器的名称解析） 过程中发送到另一台 DNS 服务器。

在其中使用转发器的 DNS 服务器上配置的顺序由其 IP 地址列出 DNS 服务器的顺序决定。 DNS 服务器将查询转发到转发器的第一个 IP 地址后，它将等待一段很短的应答来自该转发器 （根据 DNS 服务器的超时设置） 之后继续使用下一个 IP 地址进行转发操作。 它继续执行此过程，直到收到来自转发器肯定应答。

与传统的解决方案，其中往返时间 (RTT) 是与每个服务器相关联，转发器列表中的 IP 地址不排序根据往返时间，而必须手动重新排序，要更改首选项。

配置转发器并主持父区域的 DNS 服务器将使用其委派信息，然后再转发查询。 如果不存在委派记录用于在查询中的 DNS 名称，DNS 服务器将以解决该查询使用其转发器。

一个常见的错误配置转发时是尝试在一个专用 DNS 命名空间的根服务器上配置转发。 尝试在一个专用 DNS 命名空间的根服务器上配置转发的目标是将所有非现场查询转发到 Internet 的 DNS 服务器。 根服务器不能使用标准转发配置。 如果根服务器查询有关任何域名，然后它将引用可以回答的问题 （从其本地区域，高速缓存），DNS 服务器或它将失败 （NXDOMAIN），以响应，但不能将它配置为转发到特定服务器。

条件转发器是用来转发 DNS 查询以便在查询中的 DNS 域名称根据网络上的 DNS 服务器。 例如，DNS 服务器可以配置为转发它的名称结尾 widgets.example.com 到 DNS 服务器的 IP 地址或多个 DNS 服务器的 IP 地址接收的所有查询。

条件转发器可以用来改进 intranet 内的域的名称解析。 通过使用特定的内部域名的转发器配置 DNS 服务器，可以提高 intranet 名称解析。 例如，域 widgets.example.com 中的所有 DNS 服务器无法都配置为转发查询的结尾 test.example.com 到 merged.widgets.example.com，从而删除查询 example.com） 的根服务器或删除具有辅助区域 test.example.com 的 widgets.example.com 区域中配置 DNS 服务器的步骤的步骤的权威 DNS 服务器的名称。

DNS 服务器可以使用条件转发器解析之间共享信息的公司的 DNS 域名的查询。 例如，两家公司，构件玩具和乖宝贝玩具公司，希望提高构件玩具的 DNS 客户端如何解决乖宝贝玩具公司的 DNS 客户端的名称。 从乖宝贝玩具公司管理员通知管理员的小部件，可以发送查询的域 dolls.tailspintoys.com 乖宝贝玩具公司网络中的 DNS 服务器的一组有关的小玩具。 小玩具网络中的 DNS 服务器配置为转发的名称与指定的 DNS 服务器的 dolls.tailspintoys.com 网络中结束，乖宝贝玩具的所有查询。 因此，构件玩具网络中的 DNS 服务器不需要查询他们的内部根服务器或 Internet 根服务器，以解析查询的名称以 dolls.tailspintoys.com 结尾。

RFC 2136 引入了新的操作码或消息格式称为更新。 更新消息可以添加和删除从指定区域的 Rr，以及测试系统必备条件。 更新是原子操作，也就是说，必须满足所有先决条件或没有更新操作将发生。

作为在任何传统的 DNS 实现中，必须在该区域的主 DNS 服务器提交区域更新。 如果由辅助 DNS 服务器收到更新，它将被转发向上复制拓扑直至到达主 DNS 服务器。 Active Directory 集成的区域，这种情况在区域中的资源记录的更新可以发送到其数据存储区包含的区域 Active Directory 域控制器上运行的任何 DNS 服务器。

区域传送过程始终将锁定区域，以便辅助 DNS 服务器接收传输区域数据时的一致的区域视图。 当该区域被锁定时，它就无法再接受动态更新。 如果该区域很大，并且经常锁定区域传输目的，它将运行动态更新客户端，并且系统可能会变得不稳定。 Windows Server 2008 DNS 服务器服务队列到达区域传输过程中，并处理区域传送完成后的更新请求。

客户端和服务器计算机更新其 DNS 名称的方式

示例： 如何进行动态更新的工作原理

Windows DHCP 客户机的动态更新意识和可以初始化动态更新进程。 当客户端租用 IP 地址或续订租约，确定哪台计算机更新 A 和 PTR Rr 的客户端的 DHCP 客户机进行协商与 DHCP 服务器动态更新的过程。 根据协商过程中，DHCP 客户机、 DHCP 服务器，或同时更新通过到要更新的名称具有权威性的主 DNS 服务器发送动态更新请求的记录。

客户端和正在运行的 Windows 的版本早于 Windows 2000 的服务器不支持动态更新。 Windows Server 2008 DHCP 服务器服务可执行客户端不支持 DHCP 客户端服务 FQDN 选项 （这在下一节中所述） 所代表的动态的更新。 例如，运行 Microsoft Windows ® 95、 Windows 98 中和 Windows NT 的客户端不支持 FQDN 选项。 但是，可以在 DHCP 控制台的服务器属性的DNS选项卡中启用此功能。 DHCP 服务器首先从 DHCP 请求数据包中获取旧客户端的名称。 然后将该作用域的域名附加并注册的 A 和 PTR Rr。

在某些情况下，过时 PTR 或 A Rr 可以出现在 DNS 服务器中的 DHCP 客户端的租约过期时。 例如，当运行 Windows Vista ® 或 Windows Server 2008 的 DHCP 客户端尝试协商与运行 Windows NT 4.0 DHCP 服务器动态更新过程，DHCP 客户机必须注册两个 A 和 PTR Rr 本身。 以后，如果运行 Windows 2000 的客户端不正确地从网络中删除，客户端无法取消注册其 A 和 PTR Rr，它们会变得陈旧。

陈旧的 A RR 出现在允许仅安全的动态更新的区域中，没有计算机能够在该 A RR 中注册该名称的任何其他 RR。 若要防止陈旧 PTR 和 A Rr 的问题，您可以启用老化和清理功能。 有关老化和清理功能的详细信息，请参阅本主题中的”了解老化和清理”。

为了提供容错能力的动态更新，请考虑为接受来自 Windows Server 2008 基于网络的客户端的动态更新，这些区域的 Active Directory 集成。 为了加快发现的权威 DNS 服务器，您可以配置每台客户机是该目录集成区域的主的首选和备用 DNS 服务器的列表。 如果客户端无法使用其首选的 DNS 服务器更新该区域，因为 DNS 服务器不可用，客户端可以尝试备用服务器。 当首选的 DNS 服务器变为可用时，它将加载更新后，目录集成区域，包括来自客户端的更新。

若要协商动态更新过程，DHCP 客户端通过使用 DHCP 客户端服务 FQDN 选项发送到 DHCPREQUEST 数据包中的 DHCP 服务器及其 FQDN。 DHCP 服务器然后回复给 DHCP 客户端通过发送包含 FQDN 选项 （选项代码 81） 的 DHCP 确认 (DHCPACK) 消息。

下表列出的 DHCPREQUEST 数据包的 FQDN 选项的字段。

在 DHCPREQUEST 数据包的 FQDN 选项中的字段

在 DHCP 客户端发送 FQDN 选项和由 DHCP 服务器所执行的操作的条件取决于客户端和服务器正在运行的操作系统和如何配置客户端和服务器。

客户端请求动态更新取决于它是否在运行 Windows Server 2008 或更早版本。 它还取决于客户端配置。 客户端可以执行下列操作之一：

• 默认情况下 Windows 服务器 2008 DHCP 客户端服务将发送标志域的 FQDN 选项设置为 0，以请求的客户端更新的 A RR 和 DHCP 服务器服务更新 PTR RR。 客户端发送 FQDN 选项后，它会等待来自 DHCP 服务器的响应。 DHCP 服务器将标志字段设置为 3，除非客户端 A rr 然后启动更新。 如果 DHCP 服务器不支持或未配置为执行 DNS 记录注册，然后没有 FQDN 包含在 DHCP 服务器的响应中，并在客户端尝试注册 A 和 PTR Rr。
• 如果 DHCP 客户机运行 Windows 操作系统的系统早于 Windows 2000 中，或者如果客户端是 Windows 2000，并且它配置不进行注册 DNS 资源记录，然后在客户端不发送 FQDN 选项。 在这种情况下，客户端不会更新任何记录。

具体取决于哪种，DHCP 客户端请求，DHCP 服务器可以采取不同的操作。 如果 DHCP 客户机发送 DHCPREQUEST 消息 FQDN 选项的情况下，行为取决于 DHCP 服务器和配置方式的类型。 如果它被配置为更新记录代表的 DHCP 客户端不支持 FQDN 选项，DHCP 服务器可以更新两个记录。

在下列情况下，DHCP 服务器不执行任何操作：

• 在 DHCP 服务器 （例如，运行 Windows NT 4.0） 不支持动态更新。
• DHCP 服务器正在运行 Windows Server 2008，并配置为不为不支持的 FQDN 选项的客户端执行动态更新。
• DHCP 服务器正在运行 Windows Server 2008，并配置为不注册 DNS 资源记录。

如果 Windows network–based DHCP 客户端请求的服务器更新 PTR RR，但不是将 A RR，行为取决于 DHCP 服务器和配置方式的类型。 服务器可以执行下列操作之一：

• 如果 DHCP 服务器正在运行 Windows Server 2008，并且配置为不执行动态更新，其响应不包含 FQDN 选项并不会更新任何 RR。 在这种情况下，DHCP 客户机尝试更新 A 和 PTR Rr，如果它能够。
• 如果 DHCP 服务器正在运行 Windows Server 2008，并且配置为根据 DHCP 客户端请求更新，服务器将尝试更新 PTR RR。 DHCP 客户机的 DHCP 服务器 DHCPACK 消息包含 FQDN 选项与标志字段设置为 0，确认 DHCP 服务器更新的 PTR 记录。 DHCP 客户机然后尝试更新 A RR 中，如果能够。

如果 DHCP 服务器正在运行 Windows Server 2008，并且是配置为始终更新 A 和 PTR 两个记录，DHCP 服务器会尝试更新这两个 Rr。 DHCP 客户机的 DHCP 服务器 DHCPACK 消息包含 FQDN 选项与标志字段设置为 3，通知 DHCP 客户机的 DHCP 服务器更新 A 和 PTR 记录。 在这种情况下，DHCP 客户机不会尝试更新任一 RR。

静态配置的客户端和远程访问客户端不依赖的 DHCP 服务器的 DNS 注册。 Statically configured clients dynamically update their A and PTR RRs every time they start and then every 24 hours in case the records become corrupted or need to be refreshed in the DNS database.

Remote access clients can dynamically update A and PTR RRs when a dial-up connection is made. They can also attempt to withdraw, or deregister, the A and PTR RRs when the user closes down the connection explicitly. Computers running Windows Server 2008 with a remote access network connection attempt the dynamic registration of the A and PTR records corresponding to the IP address of this connection. By default, the DNS Client service on Windows XP does not attempt dynamic update over a remote access or VPN connection.To modify this configuration, you can modify the advanced TCP/IP settings of the particular network connection or modify the registry.

In all operating systems, if a remote access client does not receive a successful response from the attempt to deregister a DNS resource record, or if for any other reason fails to deregister a resource record within four seconds, the DNS client closes the connection. In such cases, the DNS database might contain a stale record.

If the remote access client fails to deregister a DNS resource record, it adds a message to the event log, which you can view by using Event Viewer. The remote access client never deletes stale records, but the remote access server attempts to deregister the PTR RR when the client is disconnected.

By default, Windows Server 2008 DNS Client service dial-up networking clients do not attempt to update A and PTR records automatically. Due to the nature of their business, it is common that ISPs do not enable dynamic updating of DNS information by their customers. If you use an ISP that does not support dynamic update, configure the connection properties to prevent the computer from performing dynamic updates.

If a dynamic update client is multihomed (has more than one network connection and associated IP address), it registers all IP addresses for each network connection. If you do not want it to register these IP addresses, you can configure the network connection to not register IP addresses.

The dynamic update client does not register all IP addresses with the DNS servers in all namespaces that the computer is connected to.For example, a multihomed computer, client1.noam.example.com, is connected to both the Internet and the corporate intranet. Client1 is connected to the intranet by adapter A, a DHCP adapter with the IP address 172.16.8.7. Client1 is also connected to the Internet by adapter B, a remote access adapter with the IP address 10.3.3.9. Client1 resolves intranet names by using a name server on the intranet, NoamDC1, and resolves Internet names by using a name server on the Internet, ISPNameServer.

Whenever a dynamic update client registers in DNS, the associated A and PTR RRs include the Time to Live (TTL), which by default is set to 10 minutes for records registered by the Net Logon service, and 15 minutes for records registered by the DHCP Client service. If the DNS Server service dynamically registers records for its own zones, the default TTL is 20 minutes. You can change the default setting in the registry. A small value causes cached entries to expire sooner, which increases DNS traffic but decreases the risk of cached records becoming outdated. Expiring entries quickly is useful for computers that frequently renew their DHCP leases. Long retention times are useful for computers that renew their DHCP leases infrequently.

When the DNS Client service attempts to register an A record and it discovers that the authoritative DNS zone already contains an A record for the same name but with a different IP address, by default, the DNS Client service attempts to replace the existing A record (or records) with the new A record containing the IP address of the DNS client. As a result, any computer on the network can modify the existing A record unless secure dynamic update is used. Zones that are configured for secure dynamic update allow only authorized users to modify the resource record.

You can change the default setting so that the DNS Client service ends the registration process and logs the error in Event Viewer, instead of replacing the existing A record.

DNS update security is available only for zones that are integrated into Active Directory. When you integrate a zone into Active Directory, access control list (ACL) editing features are available in the DNS console so you can add or remove users or groups from the ACL for a specified zone or resource record. ACLs are for DNS administration access control only, and do not influence DNS query resolution.

By default, dynamic update security for DNS servers and clients are handled as follows:

• DNS clients attempt to use unsecured dynamic update first. 如果非安全的更新被拒绝，则客户端将尝试使用安全更新。此外，客户端使用允许它们尝试覆盖先前注册的资源记录，除非更新安全性明确禁止的默认更新策略。
• 区域后将成为活动的 Directory–integrated，运行 Windows Server 2008 默认允许仅安全的动态更新的 DNS 服务器。当使用标准区域存储时，DNS 服务器服务的默认设置是不允许在其区域的动态更新。 对于那些要么目录集成或使用标准的基于文件的存储，您可以更改此区域以便允许所有动态更新，这样所有的更新，才能被接受。动态更新是最新附加 DNS 标准规范，RFC 2136 中定义。 有关 Rfc 的详细信息，请参阅 DNS 的参考信息 .

  DNS 资源记录的动态注册，可以通过使用注册表项限制。

安全动态更新工作原理

安全动态更新过程

不支持 FQDN 选项 （选项 81） 的 Windows DHCP 客户机不能进行动态更新。 如果所需的 A 和 PTR Rr 用于在 DNS 中动态注册这些客户端，则必须配置 DHCP 服务器以代表自己执行动态更新。

但是，具有 DHCP 服务器以执行安全动态更新的 DHCP 客户机不支持 FQDN 选项的代表并不可取的因为 DHCP 服务器时执行安全动态更新的名称，DHCP 服务器成为该名称的所有者，并且只有该 DHCP 服务器可以更新该名称的任何记录。 在某些情况下，这可能导致问题。

例如，假设 DHCP 服务器 DHCP1 创建一个对象，用于名称 nt4host1.example.com，并停止响应，并且稍后备份 DHCP 服务器，DHCP2，尝试更新的记录相同的名称，nt4host1.example.com。 在此情况下，DHCP2 不能更新名称，因为它不拥有该名称。 在另一个示例中，假设 DHCP1 添加一个对象，用于名称 nt4host1.example.com 中，并且管理员然后升级 nt4host1.example.com 到基于 Windows 2000 的计算机。 因为不是基于 Windows 2000 的计算机的没有所有者名称，它将不能更新 DNS 记录的名称。

若要解决此问题，提供了名为 DnsUpdateProxy 的内置安全组。 如果所有的 DHCP 服务器添加为 DnsUpdateProxy 组的成员中，一台服务器的记录被更新由另一台服务器如果第一个服务器出现故障。 另外，因为由 DnsUpdateProxy 组的成员所创建的所有对象都是不安全的第一个用户 （即不是 DnsUpdateProxy 组的成员） 来修改与 DNS 相关的记录集名称将成为它的所有者。 升级旧客户端后，他们可以因此所有权名称记录的 DNS 服务器上。 如果为老客户机注册资源记录每个 DHCP 服务器为 DnsUpdateProxy 组的成员，消除了前面讨论的问题。

保护记录时使用的 DnsUpdateProxy 组

DNS 区域和资源记录存储在 Active Directory 中的访问控制 Acl。 为 DNS 服务器服务后，整个区域或特定的 DNS 名称，则可以指定 Acl。 默认情况下，通过任何经过身份验证的 Active Directory 用户可以在任何区域中创建 A 或 PTR Rr。 后一个所有者名称已为创建一个区域 （无论资源记录类型），只允许用户或该名称的 ACL 中指定的组具有写入权限才能够修改该名称相对应的记录。 虽然这种方法是理想在大多数情况下，某些特殊情况下需要分别考虑。

DNSAdmins 组

保留名称

可以使用的老化和清理的 DNS 的功能之前，必须满足几个条件：

1. 在 DNS 服务器和区域上都必须启用清理和老化。默认情况下被禁用资源记录的老化和清理。
2. 资源记录必须动态地添加到区域或手动修改，以便在老化和清理操作中使用。

通常情况下，使用 DNS 动态更新协议动态添加的那些资源记录会遵守老化和清理。

但是，您可以允许对通过非动态途径添加其他资源记录进行清除。 对于通过从另一台 DNS 服务器加载基于文本的区域文件或通过手动将其添加到区域中，添加到区域中这种方式，记录设置为零的时间戳。 这使得这些记录没有资格使用在老化和清理操作。

若要更改此默认设置，您可以重置并允许它们使用当前的 （非零） 时间戳值分别，管理这些记录。 这使这些记录将成为老化和清理。

下面的列表指明新的或修订的术语来帮助讨论老化和清理时专门引进了。

当前服务器时间当前日期和时间在 DNS 服务器上。 此数字可以表示时间为在任何点的确切数值。

无刷新间隔确定每个区域，受限于以下两个事件的时间间隔：

• 日期和上次刷新记录的时间以及其时间戳设置。
• 日期和时间时记录下一步有资格被刷新，并让其时间戳重置。

此值才可减小到 Active Directory 数据库的写操作的数量。 默认情况下此间隔设置为七天。 它应该不会增加到合理的水平，因为老化和清理功能的好处可能丧失或降低。

记录刷新当资源记录处理 DNS 动态更新时只有资源记录时间戳而不是其他特征的记录时，进行修订。 由于以下原因通常可引起刷新：

• 当在网络上重新启动计算机时，以及在启动时，如果其名称和 IP 地址信息符合相同的名称和地址信息，它用来在即将关闭之前时，它会发送刷新请求以更新此信息及其相关联的资源记录。
• 运行时，将由计算机发送定期刷新。
• Windows XP 和 Windows 服务器 2008 DNS 客户端服务续订客户机资源记录的 DNS 注册每隔 24 小时。 此动态更新发生时，如果动态更新请求不会导致修改到 DNS 数据库，它被认为是刷新，而不是资源记录更新。
• 其他网络服务进行刷新尝试，如 DHCP 服务器续订客户机地址租约 ；群集服务器注册和更新记录的群集;和 Net Logon 服务，以及可注册和更新 Active Directory 域控制器使用的资源记录。

记录更新当 DNS 动态更新资源记录的其中除了其时间戳记录的其他特征为修改处理。 更新通常会出现，原因如下：

• 当一台新计算机添加到网络，并在启动时，它会发送更新其资源记录注册到第一次使用其配置的区域。
• 当该区域中的现有记录的计算机 IP 地址中有更改时，导致发送更新为 DNS 区域数据中其修订名称到地址映射。
• 当出现 Net Logon 服务注册新的 Active Directory 域控制器。

刷新间隔确定每个区域，受限于以下两个不同的事件的时间间隔：

• 最早的日期和时间时记录有资格被刷新，并让其时间戳重置。
• 最早的日期和时间时记录有资格被清理和从区域数据库中删除。

此值应足够大，以允许所有客户端刷新它们的记录。 默认情况下此间隔设置为七天。 它应该不会增加到合理的水平，因为老化和清理功能的好处可能丧失或降低。

资源记录时间戳由 DNS 服务器用来确定删除资源记录的老化和清理操作执行时的日期和时间值。

清理周期在服务器上启用自动清理时，该周期表示重复执行自动清理过程之间的时间。 默认值是七天。 为防止 DNS 服务器性能的损害，对此最小允许的值为 1 小时。

清理服务器可选的高级的区域参数，它允许您指定的允许进行清理的区域的 DNS 服务器的 IP 地址限制的列表。 默认情况下如果不指定此参数，则加载目录集成区域 （也可用于清理） 的所有 DNS 服务器都尝试执行该区域的清除。 在某些情况下，此参数可以是最好在某些加载目录集成区域的服务器上执行仅清理的情况下非常有用。 若要设置此参数，必须指定要清理的区域，该区域的 ScavengingServers 参数中启用的服务器的 IP 地址的列表。 这可使用 dnscmd 命令，命令行基于工具用于管理 Windows DNS 服务器。

开始清除时间以数字表示的特定时间。 这次由服务器用于确定区域何时进行清理。

满足所有前提条件允许使用清理后，开始清理对服务器区域当前服务器时间大于的起始清理时间的区域的值时。

服务器设置的时间值开始清理每个区域的基础上，每次发生下列事件之一时：

• 该区域启用动态更新。
• 中的清除旧资源记录复选框状态的改变将生效。 可以使用 DNS 控制台来修改此设置相应的 DNS 服务器或它的一个主要区域。
• DNS 服务器加载可使用清理过程的主要区域。 当服务器计算机启动时或 DNS 服务器服务启动时才发生这种情况。
• 当某个区域将被暂停后又恢复服务。

任何先前的事件发生时，DNS 服务器设置开始清理时间通过计算以下总和的值：

当前服务器时间 + 刷新间隔 = 开始清除时间

清理操作期间，此值将用作比较的基础。

样本记录老化和清理过程的示例

Utf-8 是建议的字符集之外的 ASCII 使用不断发展的协议。 The UTF-8 protocol provides for support of extended ASCII characters and translation of UCS-2, a 16-bit Unicode character set that encompasses most of the world’s writing systems. UTF-8 enables a far greater range of names than can be achieved using ASCII or extended ASCII encoding for character data.

Computers running Windows Server 2008 are UTF-8 aware. This means that when UTF-8-encoded characters are received or used as data by the server, the server can load and store this data in its zones. Although Windows-based DNS servers are UTF-8 aware, they remain compatible with other DNS servers that use traditional US-ASCII data encoding and current DNS standards.

To provide standards compatibility and interoperability with other DNS implementations, the DNS service uses uniform downcasing of any received character data. In this process, the DNS service converts all uppercase characters used in standard US-ASCII data to lowercase equivalent data for the following reasons:

• To maintain compatibility with current and existing DNS standards.
• To provide interoperability with DNS server implementations that do not recognize or support UTF-8 encoding.

To understand why uniform downcasing was chosen, several related points must first be considered from the current revised Internet standards for DNS. Several key points in the standards pertain directly to how character data is to be handled between DNS servers and other servers and clients. These include the following:

• Any binary string can be used in a DNS name. (RFC 2181)
• DNS servers must be able to compare names in a case-insensitive way. (RFC 1035)
• The original case for character data should be preserved whenever possible as the data is entered into the system. (RFC 1035)

Because case insensitivity is a required part of the core DNS standard and case preservation is an optional recommendation, uniform downcasing was chosen to provide an effective standards-compliant solution. By downcasing UTF-8 encoded names before transmission, other DNS servers (which are not UTF-8 aware) are able to receive and perform successful binary comparisons of the data and obtain the desired results.

The DNS Server service can be configured to allow or disallow the use of UTF-8 characters on a per-server basis. Although other DNS server implementations that are not UTF-8 aware might be able to accept the transfer of a zone containing UTF-8 encoded names, these servers might not be able to write back those names to a zone file or reload those names from a zone file. Administrators should exercise caution when transferring a zone containing UTF-8 names to a DNS server that is not UTF-8-aware.

Some protocols place restrictions on the characters allowed in a name. In addition, names that are intended to be globally visible (RFC 1958) should contain ASCII-only characters, as recommended in RFC 1123.

The use of UTF-8 for transformation of Unicode characters is not noticeable for general users, but UTF-8-encoded characters can be observed when Network Monitor or another similar tool is used to analyze DNS-related traffic over the physical network.

In addition to DNS server support for the UTF-8 encoding format, the client resolver defaults to using the UTF-8 character encoding format.

Names encoded in UTF-8 format must not exceed the size limits clarified in RFC 2181, which specifies a maximum of 63 octets per label and 255 octets per name. Character count is insufficient to determine size because some UTF-8 characters exceed one octet in length.

The UTF-8 encoding protocol adapts to use with existing DNS protocol implementations that expect US-ASCII characters because representation of US-ASCII characters in UTF-8 is identical, byte for byte, to the US-ASCII representation. DNS client or server implementations that do not recognize UTF-8 characters always encode names in the US-ASCII format. Those names are correctly interpreted by the DNS Server service.

The DNS service provides the ability to configure name checking to allow or restrict the use of UTF-8 characters in DNS data.

By default, multibyte UTF-8 name checking is used, allowing the greatest tolerance when the DNS service processes characters. This is the preferred name-checking method for most privately operated DNS servers that are not providing name service for Internet hosts.

The WINS and DNS services are used to provide name resolution for the NetBIOS namespace and the DNS domain namespace, respectively. 尽管 DNS 和 WINS 可以向客户端提供独立且有用的名称服务，主要是为旧客户端和 NetBIOS 命名需要支持的程序提供支持需要 WINS。

但是，DNS 服务可以使用 WINS 解析区域信息中找不到的 DNS 域名称时提供两个命名空间中的组合的名称搜索。 为了提供这种互操作，新记录 （WINS 记录） 被定义为区域数据库文件的一部分。

WINS RR 的存在可以指示 DNS 服务使用 WINS，为主机名称或名称的区域数据库中找不到任何正向查询搜索。 此功能会进行名称解析的未注册 DNS，如 Windows 95 或 Windows 98 的计算机的计算机名称不支持 WINS 的 （例如，UNIX） 的客户端需要特别有用。

以下是查询的 DNS 服务器在试图查找另一台计算机名为”主机-a.example.microsoft.com。”地址的 DNS 客户端 （主机 b） 的示例

WINS 搜索

在步骤 1 中，客户端查询其首选的 DNS 服务器。 在步骤 2 到步骤 8 中，正常的递归过程时首选的 DNS 服务器查询其他 DNS 服务器连续代表的客户端。 Example.microsoft.com 区域的 DNS 服务器位于通过引用应答前一个链时，在第 8 步，得出结论这一过程。

当 example.microsoft.com 区域的 DNS 服务器接收的查询主机 a，它在中查找其配置的区域，如果可以找到匹配的地址 (A) RR。 如果找到没有 A 记录，该区域启用为使用 WINS 搜索服务器具有以下功能：

• DNS 服务器将在 DNS 查询中包含完全限定的域名的名称 （主机 a） 的主机部分分隔开。名称的主机部分是查询的 DNS 域名中的第一个标签，在名称中使用英文句点之前。
• 服务器然后将发送到使用的主机名，主机 a 的 WINS 服务器的 NetBIOS 名称请求。
• 如果 WINS 服务器可以解析该名称，则会返回到 DNS 服务器的 IP 地址。
• DNS 服务器然后编译一个 A RR，使用解决通过 WINS 服务器的 IP 地址和此记录返回到原始的首选 DNS 服务器的查询请求的客户端，通过主机 b。
• 在首选的 DNS 服务器然后传递给查询应答传回发出请求的客户端。

此外，还有 WINS-R 记录或 WINS 反向查找条目，可以启用并添加到反向查找区域。 但是，因为按 IP 地址未编制索引的 WINS 数据库，DNS 服务无法将反向名称查询发送到 WINS 以获得给出其 IP 地址的计算机的名称。

因为 WINS 不提供反向查找能力，DNS 服务就将节点适配器状态请求发送到 DNS 反向查询中隐含的 IP 地址直接。 当 DNS 服务器收到从节点状态响应的 NetBIOS 名称时，它后面追加回上节点状态响应中提供的 NetBIOS 名称的 DNS 域名称，并将结果转发给发出请求的客户端。