最新消息:

DNS 流程和交互

DNS admin 3529浏览 0评论

DNS 流程和交互涉及到 DNS 客户端和 DNS 服务器的 DNS 查询和动态更新,解决期间之间和名称解析和区域管理过程中的 DNS 服务器之间的通信。辅助进程和交互操作取决于对技术 (如 Unicode 和 WINS 的支持。

DNS 查询的工作原理

当 DNS 客户端需要查询程序中使用的名称时,它会查询 DNS 服务器来解析名称。 每个客户端发送的查询消息包含三条信息,指定需要服务器应答的问题:

  1. 指定的 DNS 域名,表示为完全限定的域名 (FQDN)。
  2. 指定的查询类型,可以指定资源记录 (RR) 的类型或查询操作的专门的类型。
  3. 指定的类中的 DNS 域名。 对于运行 Windows 操作系统的 DNS 服务器,这应该始终将指定为互联网 (IN) 类。

例如,指定的名称可以为一台计算机,FQDN 如”主机-a.example.microsoft.com。”,并按该名称指定要查找的地址 (A) RR 的查询类型。 思考的 DNS 查询作为客户端向服务器分为两部分的问题,如”您是否有任何 A 资源记录的计算机名为 hostname.example.microsoft.com。?”当客户端从服务器接收应答时,它读取并解译应答 A RR,学习它通过名称提问的计算机的 IP 地址。

在许多不同的方式解决 DNS 查询。 客户端有时可以回答查询使用本地缓存从上一个查询中获取的信息。 DNS 服务器可以使用它自己的资源记录信息的高速缓存来应答查询。 DNS 服务器可以还查询或完全解析名称,请求客户端的代表联系其他 DNS 服务器,然后发送应答返回至客户端。 此过程称为递归。

此外,客户端本身可以尝试联系其他 DNS 服务器来解析名称。 当客户机来执行此操作时,它使用基于服务器应答的独立和附加查询。 此过程称为迭代。

一般情况下,DNS 查询过程分为两部分:

  • 在名称查询开始在客户端计算机上,并传递给一个冲突解决程序,DNS 客户端服务) 进行解析。
  • 时无法本地解析查询,可以根据需要来解析名称查询 DNS 服务器。

这两个这些进程在以下各节详细介绍。

第 1 部分: DNS 客户端服务冲突解决程序

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

DNS 查询过程概述

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

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

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

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

第 2 部分: 查询 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。

 注意
默认情况下,DNS 服务器服务使用根提示文件,cache.dns,存储在服务器计算机上的 systemroot\System32\Dns 文件夹中。 此文件包含的 NS 和 A Rr (Internet 根服务器或 intranet 根服务器) 的 DNS 命名空间的根服务器。 DNS 服务器服务启动时,当前列表中的所有根服务器查询根服务器列表。 查询的结果用于更新根提示文件。 定期在服务正在运行时,也执行此操作。 时到根提示由管理员进行了更改,这些更改会写回,根提示文件。

反向搜索

在大部分的 DNS 查找,客户机一般执行正向查找,这是基于另一台计算机的 DNS 名称,如存储在地址 (A) RR 中搜索。 这种类型的查询希望将 IP 地址作为应答的资源数据。

DNS 也提供反向查找过程,允许客户端在名称查询期间使用已知的 IP 地址,并查找一个基于其地址的计算机名称。 反向查找采取形式的一个问题,如”您能告诉我使用 IP 地址 192.168.1.20 的计算机的 DNS 名称?”

DNS 不最初设计为支持这种类型的查询。 支持反向查询过程的一个问题是如何组织的 DNS 名称空间和索引名称,如何分配 IP 地址上的差异。 如果可用于回答以前问题的唯一方法是在 DNS 名称空间搜索所有域,则反向查询会花很长时间并需要用到太多处理。

若要解决此问题,称为 in-addr.arpa 域中的特殊域被 DNS 标准中定义,并保留在 Internet DNS 名称空间,以提供一种可行和可靠的方法来执行反向查询。 若要创建反向命名空间,使用中的 IP 地址的点分十进制表示法的数字进行反向排序形成 in-addr.arpa 域中的子域。

因为与 DNS 名称不同,当从左到右读取 IP 地址时它们进行解释以相反的方式,需要为每个八位字节值的域的此反向排序。 当从左到右读取 IP 地址时,它是从最一般的信息 (IP 网络地址) 的更具体的信息 (IP 主机地址) 到最后一个八位字节中包含的地址的第一部分中进行查看。

出于此原因,构建在 in-addr.arpa 域树时,必须被相反的 IP 地址八位字节顺序。 DNS 中 addr.arpa 树的 IP 地址可以被委派到公司,为其分配特定或有限的 IP 地址在 Internet 定义地址类套。

最后,在 in-addr.arpa 域树中,如内置在 DNS 中,需要一个额外的 RR 类型的 — — 指针 (PTR) RR — 定义。 这种 RR 用于在其正向查找区域中主机的 DNS 计算机名 (A) 命名的 RR 通常对应于主机的反向查找区域中创建的映射。

In-addr.arpa 域中适用于基于 Internet 协议版本 4 (IPv4) 的所有 TCP/IP 网络中使用的寻址。 新建区域向导自动假定在创建新的反向搜索区域时您正在使用该域。

如果您正在安装 DNS,并且为 Internet 协议版本 6 (IPv6) 网络配置反向查找区域,您可以在 $ 新建区域向导中指定一个确切的名称。 这将允许您在可用于支持 IPv6 网络,使用不同的特殊域名,即 ip6.arpa 域的 DNS 控制台中创建反向查找区域。

有关 IPv6 和 DNS 信息,包括如何创建和使用即 ip6.arpa 域名,如所述在 RFC 1886 年 (”DNS 扩展到支持 IP 版本 6″),请参阅的示例 DNS 的参考信息 .

注意
对于通过反向查询识别主机的反向查找区域和 PTR Rr 的配置仅限于为 DNS 标准实现的可选部分。 您不需要使用反向查找区域,虽然某些联网的应用程序,它们用来执行安全检查。

示例: 反向查询 (用于 IPv4 网络)

下图显示其 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 控制台提供了一种您可以配置子网化的反向查找”无类别”区域,选择高级视图时。 这使您可以配置 in-addr.arpa 域中的一组有限的分配的 IP 地址与那些地址使用非默认 IP 子网掩码的位置中的某个区域。

转发

转发器是用于转发的 DNS 查询到该网络外的 DNS 服务器的外部 DNS 名称的网络上的 DNS 服务器。 您还可以转发查询根据使用条件转发器的特定域名。

网络上的 DNS 服务器指定为转发器通过让其他 DNS 服务器中网络转发它们无法本地解析该 DNS 服务器的查询。 通过使用转发器,可以管理您的网络以外,如在 Internet 上的名称的名称的名称解析,并提高您网络中的计算机的名称解析的效率。

直接使用转发器的名称查询

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

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

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

当您指定作为转发器的 DNS 服务器时,您使该转发器负责处理外部通信,因此限制了到 Internet 的 DNS 服务器的风险。 转发器将建立外部 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 域名称根据网络上的 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 结尾。

动态更新

动态更新允许 DNS 客户端计算机能够注册并动态更新的 DNS 服务器的其 Rr,无论何时发生变化。 这减少了手动管理区域记录,尤其是对于经常移动或更改位置并使用 DHCP 获取 IP 地址的客户端的需要。

如 RFC 2136,”域名系统中的动态更新。”中所述,DNS 客户端和服务器服务支持动态更新使用DNS 服务器服务允许动态更新启用或禁用基于每个区域的每个服务器配置为加载标准主区域或目录集成区域。 默认情况下 Windows 服务器 2008 DNS 客户端服务将动态更新主机在 DNS 中配置了 TCP/IP 时 (A) Rr。 Windows Server 2008 DNS 服务器服务配置,默认情况下允许仅安全动态更新。 如果您将使用仅动态更新,则必须更改此配置。

协议说明

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

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

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

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

默认情况下为 TCP/IP 静态配置的计算机试图动态注册主机 (A) 和指针 (PTR) Rr 的 IP 地址配置和使用其已安装的网络连接。 所有的计算机基础注册记录它们的 FQDN。

以下默认值也适用于计算机更新其 DNS 名称的方式:

  • 默认情况下在 Windows XP 上的 DNS 客户端不通过远程访问或虚拟专用网络 (VPN) 连接尝试动态更新。 若要修改此配置,您可以修改特定网络连接的高级的 TCP/IP 设置或修改注册表。
  • 默认情况下,由 DNS 客户端不尝试对顶级域 (TLD) 区域的动态更新。 单标签名称命名任何区域都被视为一个 TLD 区域,例如,com,edu,保留为空,我的公司。
  • 默认情况下计算机的 FQDN 的主 DNS 后缀部分与该计算机加入到 Active Directory 域的名称相同。 若要允许不同的主 DNS 后缀,域管理员可以通过修改域对象容器中的msDS AllowedDNSSuffixes属性创建受限制的允许后缀列表中。 此属性是使用活动目录服务接口 (ADSI) 或轻型目录访问协议 (LDAP) 的域管理员管理的。

可以为任何以下原因或事件发送动态更新:

  • IP 地址是添加、 删除或修改任何一个的已安装的网络连接的 TCP/IP 属性配置中。
  • IP 地址租用更改或续订与 DHCP 服务器任何一种安装的网络连接,例如,当计算机启动时,或者如果ipconfig / 续订使用命令。
  • 若要手动强制刷新 DNS 中的客户端名称注册使用ipconfig /registerdns命令。
  • 在启动时,当打开计算机。
  • 成员服务器提升为域控制器。

当将前面的事件之一触发动态更新时,DHCP 客户端服务 (而非 DNS 客户端服务) 将发送更新。 这样设计被为了便于如果由于 DHCP 的原因发生了更改的 IP 地址信息,将在 DNS 中的相应更新执行同步的计算机的名称到地址映射。 DHCP 客户端服务为系统包括未配置为使用 DHCP 的连接上使用的所有网络连接) 执行此功能。

此更新过程假定该安装,运行 Windows Server 2008 的服务器时,默认值都有效。 特定名称和更新行为是可调式高级的 TCP/IP 属性配置为使用非默认 DNS 设置的位置。

除了计算机完整的计算机名称 (或主要名称),其他特定于连接的 DNS 名称可以配置和 (可选) 注册或更新 DNS 中。

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

在计算机上的 DNS 名称或 IP 地址更改时,通常会要求动态更新。 例如,假设名为”oldhost”客户机首次配置在系统属性中使用以下名称:

计算机名 oldhost
计算机的 DNS 域名称 example.microsoft.com
完整的计算机名称 oldhost.example.microsoft.com

在此示例中,计算机的配置没有特定于连接的 DNS 域名称。 稍后,计算机已重命名从”oldhost”为”newhost”,从而导致系统上的以下名称更改:

计算机名 newhost
计算机的 DNS 域名称 example.microsoft.com
完整的计算机名称 newhost.example.microsoft.com

系统属性应用名称的更改后,会提示您重新启动计算机。 当计算机重新启动 Windows 时,DHCP 客户端服务将执行将按照下列顺序更新 DNS:

  1. DHCP 客户端服务发送 SOA 类型查询使用计算机的 DNS 域名称。客户端计算机使用计算机 (如”newhost.example.microsoft.com”) 的当前配置的的 FQDN 作为此查询中指定的名称。
  2. 包含客户端 FQDN 的区域的权威 DNS 服务器响应该 SOA 类型查询。对于标准主要区域,在 SOA 查询响应中返回的主服务器 (所有者) 是固定和静态。 在区域中存储的 SOA RR 中所示,它总是匹配准确的 DNS 名称。 如果,但是,要更新的区域是目录集成,FQDN 的 Active Directory 域的域控制器运行的任何 DNS 服务器可以响应,并动态地插入自己的名称作为 SOA 查询响应中的区域的主服务器 (所有者)。
  3. DHCP 客户端服务然后尝试联系主 DNS 服务器。客户端处理其名称以确定授权为接受其名称的主服务器的 DNS 服务器的 IP 地址的 SOA 查询响应。 然后继续执行下面的步骤序列,根据需要来联络并动态更新其主服务器:
    • 它向 SOA 查询响应中确定的主服务器发送动态更新请求。
    • 如果更新成功,不采取任何进一步的操作。
    • 如果此更新失败,客户端下一次发送 SOA 记录中指定的区域名称 NS 类型查询。
    • 当它收到对此查询的响应时,它会在响应中列出的第一个 DNS 服务器发送 SOA 查询。
    • 解析 SOA 查询后,客户端返回的 SOA 记录中指定的服务器发送动态更新。
    • 如果更新成功,不采取任何进一步的操作。
    • 如果此更新失败,则客户端重复在响应中列出的下一个 DNS 服务器发送 SOA 查询过程。
  4. 联系到可以执行更新的主 DNS 服务器后,客户端将发送更新请求和 DNS 服务器进行处理。更新申请的内容包括说明添加 A (并可能 PTR) Rr 的”newhost.example.microsoft.com”和删除这些相同的记录类型为”oldhost.example.microsoft.com”,以前注册的名称。DNS 服务器还会检查以确保客户端请求允许进行更新。 对于标准主区域,动态更新不是安全的因此任何客户端尝试成功更新。 对于活动 Directory–integrated 区域,更新会得到保护,并使用基于目录的安全设置执行。 有关详细信息,请参阅”安全动态更新”在此主题的后面。

动态更新发送或定期进行刷新。 默认情况下计算机发送刷新一次每隔七天。 如果更新不导致区域数据的任何更改,则区域仍保持其当前版本,并且不写入更改。 更新会导致实际区域更改或增加的区域传送仅当名称或地址实际更改。

请注意名称不会从 DNS 区域是否它们变为非活动状态或在刷新间隔 (7 天) 内未更新。 DNS 不通过某种机制来释放或删除名称,尽管 DNS 客户端的确尝试删除或更新旧名称记录时的新名称或地址的更改会应用。

当 DHCP 客户端提供服务的计算机寄存器 A 和 PTR Rr 时,它会使用默认的缓存生存时间 (TTL) 15 分钟为主机记录。 这可以确定长其他 DNS 服务器和客户端缓存的计算机记录,当它们包含在查询响应。

DNS 和 DHCP 客户端和服务器

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 客户端通过使用 DHCP 客户端服务 FQDN 选项发送到 DHCPREQUEST 数据包中的 DHCP 服务器及其 FQDN。 DHCP 服务器然后回复给 DHCP 客户端通过发送包含 FQDN 选项 (选项代码 81) 的 DHCP 确认 (DHCPACK) 消息。

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

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

字段 解释
代码 指定此选项 (81) 的代码。
Len 指定长度,以八位字节,该选项 (最少 4 个)。
标志 可以是下列值之一:

0。 客户机要注册的 A RR 和请求,服务器将更新 PTR RR。

1。 客户端想要注册的 A 和 PTR Rr 的服务器。

3。 DHCP 服务器注册的 A 和 PTR Rr,不管客户端的请求。

RCODE1 和 RCODE 2 DHCP 服务器使用这些字段来指定响应来自 A 和 PTR Rr 登记执行客户端的名义,以指明它是否尝试发送 DHCPACK 之前更新代码。
域名称 指定客户端的 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.

Dynamic update process for multihomed clients

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.

 Important
This behavior was changed in Windows Server 2008. Previously, a multihomed client would register only the first IP address for each network connection by default. For more information, see Microsoft Knowledge Base article 975808.

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.

Time to Live

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.

Resolving name conflicts

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.

Secure dynamic update

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 资源记录的动态注册,可以通过使用注册表项限制。

安全动态更新工作原理

安全动态更新过程进行如下所示:

  • 若要启动安全的动态更新,DNS 客户端第一次启动安全上下文协商过程中,在此期间令牌传递客户端和服务器使用 TKEY Rr 之间。 在协商过程结束时,将建立的安全上下文。
  • 接下来,DNS 客户端将 (包含添加、 删除或修改数据的目的的资源记录) 的动态更新请求发送到 DNS 服务器、 签名使用先前建立的安全上下文和传递 TSIG RR,包括在动态更新数据包中的签名。
  • 服务器会尝试更新 Active Directory 使用客户端的凭据,并向客户端发送更新的结果。 这些结果使用的安全上下文进行了签名,并在响应中包括 TSIG RR 中传递签名。
安全动态更新过程

安全动态更新过程进行如下所示:

  1. DNS 客户端查询首选的 DNS 服务器,以确定哪个 DNS 服务器是它将尝试更新的域名具有权威性。 首选的 DNS 服务器响应该区域和区域具有权威性的主 DNS 服务器的名称。
  2. DNS 客户端尝试标准的动态更新,并且如果该区域配置为仅允许安全动态更新 (Active Directory 集成的区域的默认配置),DNS 服务器会拒绝非安全更新。 已配置该区域的标准动态更新,而不是安全的动态更新,DNS 服务器将接受了添加、 删除或修改该区域中的资源记录的 DNS 客户端的尝试。
  3. DNS 客户端和 DNS 服务器开始 TKEY 协商。
  4. 首先,在 DNS 客户端和 DNS 服务器协商基础的安全机制。 Windows 动态更新客户端和 DNS 服务器只能使用 Kerberos 协议。
  5. 接下来,通过使用安全机制,在 DNS 客户端和 DNS 服务器验证其各自的身份并建立的安全上下文。
  6. DNS 客户端将动态更新请求发送到 DNS 服务器,使用已建立的安全上下文签名。 动态更新请求数据包中包含 TSIG RR 的特征码字段中包含签名。 DNS 服务器使用的安全上下文和 TSIG 签名验证动态更新数据包的来源。
  7. DNS 服务器将尝试添加、 删除或修改在 Active Directory 中的资源记录。 它可以使更新取决于 DNS 客户端是否具有适当的权限以执行更新,以及是否已满足前提条件。
  8. DNS 服务器发送到 DNS 客户端,指出它是否能够进行更新,使用已建立的安全上下文签名回复。 动态更新响应数据包中包含 TSIG RR 的特征码字段中包含签名。 如果 DNS 客户端接收带欺骗性质的答复,它将忽略它,并等待的签名响应。

对于不支持 FQDN 选项的 DHCP 客户端的安全

不支持 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 组

当 DHCP 服务器 DnsUpdateProxy 组的成员时,由 DHCP 服务器注册的 DNS 域名称不安全。 结果是,不要在 Active Directory 集成的区域,以使只有安全的动态更新而无需执行其他步骤以便由该组的成员将其安全地创建记录中使用该组。

若要防止不安全的记录,或允许 DnsUpdateProxy 组的成员只允许安全动态更新的区域中注册记录,Windows 服务器 2008 DHCP 和 DNS 允许您创建专用的用户帐户并配置 DHCP 服务器,以执行与用户帐户的凭据 (用户名、 密码和域) 的 DNS 动态更新。 由多个 DHCP 服务器,可以使用一个专用的用户帐户的凭据。

专用的用户帐户是只用于 DHCP 服务器的 DNS 动态更新注册的凭据提供标准用户帐户。 注册名称代表的 DHCP 客户端使用 DNS 动态更新时,每个 DHCP 服务器将提供这些凭据。 要更新的区域的主 DNS 服务器所驻留在相同树林中创建专用的用户帐户。 只要它驻留在林中具有与包含要更新的区域的主 DNS 服务器的林建立林信任,也可以在另一个林中位于专用的用户帐户。

域控制器上安装时,DHCP 服务器服务将继承的域控制器的安全权限,并有权更新或删除 (这包括由运行 Windows Server 2008,包括域控制器的其他计算机进行了安全地注册的记录) 的安全活动目录集成的区域中未注册任何 DNS 记录。 当安装在域控制器上,以防止服务器继承也可能滥用) 域控制器的专用的用户帐户的凭据配置 DHCP 服务器。

配置专用的用户帐户,并使用在以下情况下该帐户凭据配置 DHCP 服务器服务:

  • 域控制器被配置为 DHCP 服务器功能。
  • DHCP 服务器配置为执行 DNS 动态更新的 DHCP 客户端的代表。
  • 由 DHCP 服务器更新 DNS 区域配置为仅允许安全动态更新。

您已创建了专用的用户帐户后,您可以使用用户帐户凭据配置 DHCP 服务器,通过使用 DHCP 控制台或通过使用 Netsh 命令 (netsh dhcp 服务器设置 dnscredentials)。

 注意
  • 如果提供的凭据属于对象 (如一台计算机) 的 DnsUpdateProxy 安全组的成员,在 DNS 中注册相同的名称记录的下一个对象将成为记录所有者。
  • 如果您已指定 DHCP 服务器在 DNS 中注册 DHCP 客户端计算机时使用的凭据 (用户名、 域和密码),这些凭据不会备份与同步或异步备份。 还原 DHCP 数据库后,必须配置新的凭据。

控制更新访问区域和名称

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

DNSAdmins 组

默认情况下的 DNSAdmins 组指定它在 Windows Server 2008 域中具有完全控制的所有区域和记录。 为了使用户能够枚举在特定域中 Windows Server 2008 的区域,用户 (或用户所属的组) 都必须登记的 DNSAdmin 组中。

很可能是域管理员可能不希望向 DNSAdmins 组中列出的所有用户授予完全控制。 通常情况下,这是由造成,如果域管理员希望授予对特定区域的完全控制和只读控件的一组用户域中的其他区域。 若要实现此目的,域管理员可以为每个区域,请创建一个单独的组,并将特定的用户添加到每个组。 然后为每个区域的 ACL 将包含具有仅在该区域的完全控制权限的组。 同时,所有的组将包含在 DNSAdmins 组中,可以配置为具有读取权限只。 由于区域的 ACL 始终包含 DNSAdmins 组的这一事实,而导致的登记的特定于区域的组中的所有用户将具有都读取权限的域中的所有区域。

保留名称

允许任何经过身份验证的用户进行区域中创建一个新名称的默认 DNS 服务器服务配置可能不是足够需要高级别的安全性的环境。 在这种情况下,默认 ACL 可以更改以允许在区域中的对象的创建特定组或用户仅通过。 每个名称的 Acl 的管理提供了另一种解决此问题。 管理员可以预留离开该区域的其余所有经过身份验证的用户打开的任何新对象创建一个区域中的名称。 为此,管理员创建的记录保留的名称,并在 ACL 中设置相应的组或用户的列表。因此,只有在 ACL 中列出的用户将能够注册保留名称下的另一条记录。

了解老化和清理

运行 Windows Server 2008 的 DNS 服务器支持老化和清理功能。 作为一种机制来执行清理和删除过时资源记录,随时间推移而积累于区域数据中提供了这些功能。

通过动态更新,当计算机在网络上启动时 Rr 被自动添加到区域中。 但是,在某些情况下,它们不会自动删除计算机离开网络时。 例如,如果一台计算机注册在启动时自己主机 (A) RR,并且稍后以不正确断开网络,可能不会删除其主机 (A) RR。 如果您的网络有移动式用户和计算机,这种情况可能经常发生。

如果非托管) 左侧,在区域数据中陈旧 Rr 的存在可能会导致一些问题。 以下是一些示例:

  • 如果在服务器区域中保留大量的陈旧 Rr,它们可以最终占用服务器磁盘空间并导致不必要的大量区域传输。
  • 加载带陈旧 Rr 的区域的 DNS 服务器可能会使用过时的信息来应答客户端查询,可能会导致客户端体验在网络上的名称解析问题。
  • 在 DNS 服务器上的陈旧 Rr 的积累可降低其性能和响应能力。
  • 在某些情况下,在区域中陈旧 RR 的存在会阻止 DNS 域名正由另一台计算机或主机设备。

若要解决这些问题,DNS 服务器服务具有以下功能:

  • 时间戳,基于当前日期和时间设置在服务器计算机上,为主要类型区域向动态地添加任何 Rr。 另外,时间戳记录在其中启用了 $ 老化/清理的标准主要区域中。
  • 手动添加的 Rr,使用 0 时间戳,表示它们不受老化过程影响而且可不受限制在区域数据中保留,除非您以其他方式改变它们的时间戳或删除它们,否则。
  • 计龄 Rr 在本地数据中,根据指定的刷新时间段,对任何符合条件的区域。 只有由 DNS 服务器服务加载的主要类型区域均有资格参与此进程。
  • 清理: 用于指定的刷新周期超出任何 Rr。 当 DNS 服务器执行清理操作时,它可以确定 Rr 已老化到陈旧的点,并将其从区域数据中删除。 可以将服务器配置为执行循环,自动清理操作,或者您可以启动立即清理操作在服务器上。
     注意
    默认情况下被禁用 DNS 服务器服务的老化和清理机制。 完全了解所有参数时才启用该设置。 否则,服务器可能会意外地配置为删除不应删除的记录。 如果意外地删除一条记录,用户不能解析为该记录,查询不仅任何用户可以创建记录,并且它的所有权,即使在配置为安全动态更新的区域上。

服务器使用每个特定 RR 时间戳,连同其他老化和清理属性,您可以调整配置,以确定清除记录的内容。

老化和清理的前提条件

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

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

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

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

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

 注意
在这种更改活动 Directory–integrated 从标准主要区域,您可能希望启用区域中的所有现有资源记录的清理。 要启用某个区域中的所有现有资源记录的老化数据清除,您可以使用AgeAllRecords 命令,并且要通过 dnscmd 命令行工具。

老化和清理术语

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

当前服务器时间当前日期和时间在 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 服务器设置开始清理时间通过计算以下总和的值:

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

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

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

要了解老化和清理在服务器上的过程,请考虑的寿命范围和后续阶段单个资源记录,同时将它添加到服务器和区域位置这一过程实际上是老化并从数据库中删除。

  1. 示例 DNS 主机、”主机-a.example.microsoft.com”,注册用于启用老化/清理了其中的区域的 DNS 服务器在其主机 (A) RR。
  2. 注册时该记录,DNS 服务器会将时间戳置于此基于当前服务器时间的记录。在写入记录时间戳后,DNS 服务器不接受该记录的刷新该区域的无刷新间隔的持续时间。 但是,它可以接受该时间之前的更新。 例如,如果 IP 地址为”主机-a.example.microsoft.com”的更改,则 DNS 服务器可以接受更新。 在这种情况下,服务器还会更新 (重置) 记录时间戳。
  3. 到期无刷新时间段之后,服务器即开始接受刷新此记录的尝试。初始的无刷新周期结束之后, 刷新周期立即开始记录。 在此期间,服务器不会取消刷新记录的其余有效期的尝试。
  4. 期间以及刷新周期之后,如果服务器接收的记录,刷新它进行处理。这将重置基于在步骤 2 中所述的方法记录的时间戳。
  5. 通过”example.microsoft.com”区域的服务器执行后续清理时,由服务器检查记录 (和所有其他区域记录)。每条记录与以下总和来确定是否应删除该记录的基础上的当前服务器时间进行比较:记录时间戳 + 区域的无刷新间隔+ 区域的刷新间隔
    • 如果此总和值大于当前服务器时间,不执行任何操作并记录在区域中继续老化。
    • 如果此总和值小于当前服务器时间,同时从服务器内存中当前加载的任何区域数据以及适用 DnsZone 对象存储在 Active Directory 中为目录集成”example.microsoft.com”区域被删除记录。

Unicode 字符支持

最初,Internet 主机名被限制在 Rfc 952 和 1123年中指定的字符集。 这些限制包括限制名称来使用大写和小写字母 (A-“Z”,a 到 z)、 数字 (0-9) 和连字符 (-)。 此外,DNS 名称的第一个字符可以是数字,而且名称必须进行编码,并使用基于美国 ASCII 字符表示。

当 DNS 作为 RFC 1035,其中一个核心 DNS 标准规范的一部分引入维护着这些要求。 使用 DNS 在国际设置中,此项要求有明显的限制其中扩展的字符集用于当地命名标准。

若要删除这些局限性,Microsoft 将展开 DNS 字符支持 RFC 1035 规范超出。 DNS 服务现在提供了增强的默认为 utf-8,Unicode 转换格式的支持。

Utf-8 是什么?

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.

How the DNS service implements UTF-8

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.

Considerations for interoperability with UTF-8

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.

WINS lookup integration

Support for using Windows Internet Name Service (WINS) is provided to look up DNS names that cannot be resolved by querying the DNS domain namespace. To accomplish WINS lookup, two specific resource record types are used and can be enabled for any zones loaded by the DNS service:

  • The WINS RR, which can be enabled to integrate WINS lookup into forward lookup zones
  • The WINS-R RR, which can be enabled to integrate node adapter status request for reverse lookup zones

WINS resource record

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) 的客户端需要特别有用。

WINS 搜索的工作原理

以下是查询的 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 反向查找的工作原理

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

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

 注意
WINS 和 WINS-R Rr 是专有的 Windows 提供的 DNS 服务器服务。 您可以阻止这些资源记录被包含在区域传送到其他 DNS 服务器实现系统中。

转载请注明:爱开源 » DNS 流程和交互

您必须 登录 才能发表评论!