动态DNS和活动目录（4）

　　程序清单7-1一个NETLOGON.DNS文件举例

　　首先，如果研究一下这个文件例子，就会注意到它建立了一个需要被正确创建的逻辑结构。这个部分是次要的，因为这些记录提供了完全的说明并且能直接粘贴到域区文件里去。

　　还没有提到的是允许Netlogon服务在DNS里维护SRV结构时带来的对整体性能的影响。这个结构用来帮助客户机，由此也帮助位于设计核心位置的服务，快速和有效地定位关键服务。这种SRV结构更支持直接查询而不是一系列的查询。这个结构也用来提供对不同的服务的最“好”的或“最本地”的提供者的指针，该判断是基于对客户机所处的域，特别是所在的站点的知识作出的。

　　不允许动态更新时，此结构需要经常随环境的改变作相应的调整，否则，它不能达到最优性能。这一点有可能特别应用于对域名有GUID（长达128位的不可译标号）并且用于时服务进行优化和直接定位查询的记录。条件允许的话，建议在允许动态更新的windows 2000 DNS里使用委托授权域区来维护这些结构，如同使用更新安全一样。当整个DNS域不能被授权列出主机和客户机，也不能列出这些与SRV相关的结构时，如果已存在的DNS被配置为能接受下划线的话，考虑一下授权_msdcs,_sites,_tcp和_udp.

　　7.5把活动目录与DNS结合起来（或不结合）

　　迄今为止本章已经详细介绍了一些精选主题。如果认为在信息方面讲的太多而在简单的答案上又讲的太少，最好好好阅读以下信息。一个windows 2000 域环境的out-of-the-box网络是瞄准于微软DNS主导所有的域环境这个设计出发点的。这里所有的域环境包括：活动目录集成且启用了动态DNS环境，用DHCP来服务客户机的环境，使用安全动态更新的环境，以及活动目录被防火墙保护的环境。当顺着这些方向的任何一个远离设计点时，就有新的问题需要解决。

　　为了更好地说明这一点，本节收集了一些观察资料，一些是最新提到的，一些是先前讨论过的，按照相关因素的顺序来说明。

　　7.5.1活动目录和DNS的拓扑

　　windows 2000 的第一个版本中，实际上所有公共文档的撰写都是从一个观点出发的，那就是在活动目录的域结构和用于DNS的域结构之间一一对应。实际上，微软和一些合作者致力于在两个域名空间制造这种严格的同形性，是为了更方便于新的网络环境，而不是满足所有的网络环境。

　　有可能获得与域中的活动目录名不同的客户机与服务器间的DNS一致性。很多通常操作有可能但并不是完全不出问题。在Beta2版本和零售版本最终代码的确定之间，作出了相当大的改变来支持这种域名空间的独立性。正如支持NetBIOS的独立性一样，但要做的更多一些。

　　在这里要说的另一点是就在最终代码固定之前，RFC2672“非终端DNS名字重定位”（定义了DNAME记录）获得了标准轨道。这个记录允许对DNS域名空间某一分支的替代以使其在不同的DNS域名下仍然被认识，它创建了域分支的一个别名，就像CNAME是对普通主机名允许别名一样。通过DNAME可以重新映射xyz.com到一个存在的DNS分支诸如as.corp.com以使得它的叶和子女，如cowpoke.corp.vom能在重映射的名字下被认识（本例中为compoke.xyz.com）。

　　我们期待在明年能够看到文档化选择有较大的变化。目前，域名空间同形性这条笔直但狭窄的路接受了大量的网络环境测试并且有文档化的指导。最有可能不出问题的。能由售者提供文档的很有可能是调整至符合把windows 2000 活动目录分散到大范围的已存在的TCP/IP机制里去的现实。目前如果想走这条路或需要走这条路，就应该和微软咨询服务保持联系并作好一些惯常的准备。

　　7.5.2DNS服务器与DC放置匹配的拓扑

　　除了网络在传输中负载以及机器负载的例外，DNS的活动目录集成似乎承担了一些难以设计的工作。这些工作本来应该参与决定一个企业里DC需要放置在什么位置的。这个决定与放置DNS服务的考虑同样重要。

　　甚至当已经决定这个站点需要一个DC了，一个或另一个缓存服务器模式对一个站点是否足够仍然是一个合理的问题。如果DC的放置甚至在网络崩溃条件下依赖于windows 2000 域环境可用性的需求，也需要指明定位域区副本。考虑客户机或DHCP向何处发送更新请求是非常重要的，当DNS没有被集成时，这些请求都传送到域区的一个主服务器去，不论它在什么地方。随着安放在本地的DC上主服务器的提供，这仅仅是一个复制载入的问题，因为DC已经有了大的工作负载（管理LDAP和Kerboros以及复制工作），以及DNS的动态更新载入，客户机依靠的本地辅服务器和缓存服务器是值得考虑的。随着这些本地辅服务器从它们的本地DC获得传输，DC里的主DNS域区自动成为站点间的桥头服务器。这些DC只处理来自DNS的附加载入，这些附加载入是由注册、刷新、改变复制以及到辅服务器的传送引起的。本地辅服务器处理来自客户机查询的DNS载入以及由前向服务器得到的答案缓存。

　　7.5.3域环境预先定义组

　　当在一个域中运行windows 2000 网络服务时，服务器是活动目录的一个参与者，这意味着有一些可利用的预先定义的组。在windows 2000 的最初版本中，没有多少组是和网络服务直接联系的，见表7-1。可以考虑使用这些组来帮助对管理员责任的委托授权，或者在DNS更新代理时来缓和使用DHCP进行动态DNS更新时产生的问题。

　　表7-1活动目录中预先定义的网络服务组

　　[[TheNo.1Picture.]]

　　7.5.4DNS域区数据可用性

　　在集成域区数据到活动目录里时，那些信息对LDAP查询变得可用。只有一个安全机制是活动目录固有的，它被用来控制更新和读取访问。因为域区数据的本质决定了它必须是可用的，所以资源记录允许无条件读取。目前仿佛还没有什么用来阻止那些能获得允许LDAP会话的安全上下文的人列举整个域区数据集。一个空的安全上下文可用的程度取决于施加于Everyone组和空的、或匿名的LDAP连接上的限制。这最后一项是在最初版本的实现中某些转换的主题。目前，用防火墙来解决问题是最好的方法，但是这样做仿佛把域区数据暴露在外，任何活动目录的合法用户都能列出它们。这里有点离题，但任何授权用户有创建和拥有资源记录的能力的确有相关联的相似点。

　　7.5.5目录服务指南和DNS负载

　　本章的开始提到了如何设计DNS到活动目录拓扑的最顶层。没有提到传统的LDAP在一个

　　目录服务结构里通过一个指示过程进行的导航。如果一个位于第四层的客户机试图访问位于目录结构里不同分支上的第二层的某资源，客户机在树上递归地“行走”，一个节点一个节点地到达根部，然后回到有此记录的分支。每一步都有一循环“旅行”，一个LDAP查询和对每个成功的LDAP服务器的指示回答。这是传统的LDAP指示过程，其中每个节点都知道并且能够将客户机引导到它的邻居，客户机可以接着查询等等。

　　为了支持DNS信息可用这个事实，以及目录结构与DNS结构同形的事实，微软改变了这种定位实现的方法。在windows 2000 的发行版本中，客户机（一旦有了充足的信息，例如通过在全局目录中的查询知道了一个资源所在的域）直接找DNS提供参考。例如，如果客户机需要域里的LDAP服务，它将向DNS查询域里的_Ldap._tcpSRV记录。这给了客户机一条到目标域的LDAP服务的直接途径，潜在地删去了许多LDAP树搜索。这也增加了DNS的使用性（和可用性）。

　　先前已经有了Netlogon如何使用DNS和SRV记录。并且期待在将来SRV对定位服务如_http._tcp的用途的增加。所有的这些因素组成了广泛使用的DNS服务。

　　7.5.6动态DNS更新负载

　　这个主题主要是收集了一些关于动态DNS对服务器工作的影响的记录和观察资料。任何指定的网络环境都应通过度量域中实际的行动来进行分析。

　　在允许动态DNS后，域区文件可以被经常地改变。不同的Microsoft系统有不同的缺省值。从cluster的试图每小时三到四次进行DNS注册更新，到windows 2000 专业版的每天一次，再到DHCP的七天一次。本章前述章节讨论的清理参数和无刷新间隔，对减少波动和不必要的复制或向上的域区传递有着非常重要的影响。

　　但事实是改变中的域区会触发传送。如果标准域区的一切都运行的很好的话，通告选项会被使用，从属服务器请求IXFR递增传送，载入也会变小。当在活动目录里进行存储时，这些改变将会被递增地传播，但在活动目录复制技术上小的属性会有一个相对大的负担。

　　因为活动目录是松散地收敛的，所以它提供给动态DNS很多机会来从不同的服务器得到不同的同步授权回答。这可能至少和标准的域区传送相同。

　　当然，因为其中之一不使用动态更新，所以这是一个有争议的地方。但在设计一个DNS网络环境时要记住这些要素。关于缓存服务器在哪里比较充分，这里还有一点额外的介绍，因为使用它们会避免不断的域区传送。

　　7.6小结

　　在本章里，自然不自然地放弃了曾经讨论过的活动目录和DNS之间的相交点，本章最突出的一点是动态DNS以及由活动目录属性带来的结果。微软支持它们之间的相交来说明SRV记录的使用和动态更新之间的关系。这些是怎么完成的留给读者自己去考虑。