本章内容包括：
•动态DNS（DDNS）。从windows 和DNS管理员的角度对DNS最新的动态更新特征作了一个简要的概述。该节略述了安全连结问题和域区文件清除，还详细讨论了windows 2000 中的“废物清理”问题。
•DNS域区的活动目录集成。论及了用活动目录来存储DNS域区文件，为何这样使用的原因，它提供什么服务，以及面对决定是否使用这个可选功能时的考虑，还详细讨论它提供的动态更新安全问题。
•依赖于SRV记录的活动目录。概览windows 2000 域环境中SRV记录的用法。在所有windows 2000 支持的DNS的新特征中，SRV记录是支持活动目录所必需的。
•把活动目录与DNS结合起来（或不结合）。收集一些因素的服务，以及在使用这项技术时哪些方面需要作出有见地的决定。
windows 2000 的活动目录实现了LDAP（轻便目录访问协议）目录服务。一段历史可以帮助理解这意味着什么。最初的X.500目录服务协议因为种种原因没能完全实现商业化，从而退出了历史舞台。特别指出的是，正是这样一个如此复杂的规范，导致了它的一个子集的实现，那就是LDAP协议。
尽管LDAP协议的特征仍然在发展，但windows 2000 现在支持一个事实是：现有的LDAP协议的实现通常不支持全球范围的定位服务，DNS便是其中一个。X.500最初的概念是只提供定位的目录结构及在目录结构中定位的能力。而LDAP协议的实现却集中于目录结构的使用更甚于对它的定位。
活动目录的设计利用了现有DNS的定位能力，并通过活动目录与域名空间的紧密联系而实现。结果，活动目录里最高层的对象在名字上看起来像DNS域。这恰恰是因为在这儿使用的域控制器对象代表windows 2000 的域边界。对windows 2000 的最初版本而言，它们本来是打算以有相同结构的DNS域和子域命名的。
这里隐含的意义有很多。本章分析了一些源于这种设计及源于使用支持此设计的DNS的最新特征的能力、相互作用以及缺陷。
7.1动态DNS
DDNS（动态DNS）RFC2136详述了能被DNS客户端用来请求改变DNS域的更新操作（定义了新的DNS操作码）和消息格式。正如我们所看到的，域内容必须在本域的主服务器上产生，于是动态DNS定义当辅服务器接收到一个更新请求时，应该被向前传送到主服务器进行。如果认为这些听起来很简单易懂，那么就等一会儿，后面还有很多内容。更新很容易，实现就难了。
通过对客户机所在域的授权域名服务器的定位（对NS记录的请求）来更动态更新客户端，这样可以通过请求地址注册或任意的指针记录的注册来广播它的存在。windows 2000 实际上是查询SOA记录而不是NS记录，然后直接向此域的主机注册。在客户机做完这些以后，它的名字就可以被解析了，同时IP地址也能被任意检验。就象资资源记录被手工键入的一样。
如果这样做很简单的话，任何一个DNS管理员都会像一个刚拥有一辆新自行车的小孩一样激动。正如我们所知道的，不付出代价或冒险是很难从新事物中获利的。否则老早以前就这样做了。
7.1.1什么是动态DNS
RFC2136说明了DNS的动态更新能力，它介绍了DNS更新消息格式。利用更新消息格式，客户端可以删除一个资源记录、添加一个资源记录、或检测与维护先前状态。
RFC详细说明了记录集的用法，例如，在一个DNS域里对WWW有多个相同名字（就像多个A记录一样）的记录集。更新操作可能针对单个资源记录、一个资源记录集或多个资源记录集。通过动态更新，可以添加资源记录，也可以删除资源记录和资源记录集。
测试一定的规则是否适合，能够应用（例如，对fs2.nq.example.net没有A记录存在）。这些测试中，有的是更新请求能继续下去而必须使用的先决条件，有的只是没有相关操作的简单的维护。这些维护利用了一种更新消息，这种更新消息有一个没有相关更新操作的测试，从而提供了一种查询DNS数据库以确定某些资源记录或资源记录集是否存在的简单方式。
DNS服务器告知客户机维护测试或者更新操作的输出结果。如果更新操作有相关操作和必需的先决条件，就由DNS服务器实现更新。在这种情况下，更新在一种完全无反应的方式下进行，也就是说，此时的更新操作是原语。
对于对单个资源记录的简单的添加或删除请求，更新消息是没有限制的。更新请求可以删除整个资源记录集。因为对通配符使用的限制，更新操作需要被清楚地指定。
RFC2136规定了实时指定的或标准的RFC安全保障，用以施加于更新过程，但却并未为此定义一套机制。RFC2137首次定义了安全DNS动态更新规程。动态更新的安全问题在继续发展，许多标准的RFC方法需要公共密钥机制提供支持。在windows 2000 的最初版本中，实现了支持Kerberos的安全方法（见本章后续章节）
7.1.2windows 2000 客户端对动态DNS的使用
上节提到windows 2000 客户端可以直接到主DNS服务器进行DNS更新，之所以能这样做是因为对域数据的任何改变都要在SOA服务器上进行。windows 2000 第一版的客户端配置的动态DNS更新的缺省值是每24小时试图对它的DNS条目刷新一次。
后续章节将会更清楚地讲到，不必要的更新带来了整个系统不必要的开销。所以windows 2000 客户端做的其实比它们被指示的更高明。当它们注册的时候，它们首先发送一个只有断言的更新，即测试一下DNS所知道的东西从客户端的角度来看是否是正确的。如果是，则不必更新。如果客户端确实需要更新，并且域区是活动目录集成的，它将在注册失败后尝试是否存在任何其他主服务器。如果客户端仍然失败，更新过程将在5分钟后重试，并且等待10分钟。如果仍然不成功，则将在再一次尝试之前等待50分钟。一台windows 2000 的机器，在被设置为动态更新DNS之后，将会坚持不懈地让自己为人所知。
第15章中讨论了windows 2000 DHCP（动态主机配置协议）服务器代表客户机进行注册的能力。它能被设置成多种方式，但windows 2000 客户端的缺省值是处理A记录，而DHCP服务器的缺省值是处理PTR记录。windows NTDHCP服务器没有这种能力。DHCP能被设置为既注册记录类型，又能对非windows 2000 客户端执行这种注册。这都是通过升级安全措施和注册清理来实现的（见后续章节）
7.1.3问题是什么
既然动态DNS能让DNS管理员从维护域区文件的繁重劳动中解脱出来，并且在1997年4月的RFC文件中已被定义，那么为什么它还是很少被使用？或者说，在使用动态DNS之前究竟需要知道些什么？
1.安全
对前一个问题的回答，用一个词来说就是：安全问题。如果任何人都能注册的话，欺骗和抢劫之间的很多变化几乎就变的微不足道了。比如说，对于www.example.net的A记录，或者更大胆一点，对域名服务器ns.example.net的A记录。如果不对谁的机器或什么机器被允许更新哪个记录进行什么控制的话，则DDNS将像一项极限运动―只有勇敢者才去试。
微软已通过活动目录对域区的集成实现了对动态更新过程的保护。集成特征将是本章接下来的主要话题。
2.服务广播
在域区能被动态更新后，你也许会注意到新的SRV服务记录开始出现。活动目录依靠使用SRV记录来定位它必要的服务。例如，预计在将来_http._tcp和_ftp._tcp将用SRV记录来实现。这对你的环境来说也许是个问题。所以要清楚windows 2000 这艘大船已经完全准备好了并且能够让SRV记录上载至它的最大载量。
3.域区清理
安全更新的另一方面的问题是更新冲突与域区清理。如果更新操作，包括应该被允许的删除操作被拒绝，记录将会变成孤立的。例如：如果客户端在允许移动已注册的记录时失败，并且在过一会后又被安全机制拒绝移动,那么谁来清除这些记录？
假设DNS服务器拒绝对一个已在域中使用名字域或相应IP地址的A记录进行注册更新的话，那么考虑一下DHCP客户端试图注册其已存在的名字或者是其他的机器将要被解析到它所注册的IP地址时的情形。
这只是对过期记录造成的问题的两个概念上的例子。如果对于更新过程没有安全问题，这些问题就会消失。当客户端试图更新时，他就会成功，然后客户端就能执行查询和更新操作来消除潜在冲突以及旧的记录来保证更新的正确执行。
DNS组织提供的一个明显的选择是在牺牲清理的代价下得到安全保障。但是问题在于旧的记录将成为降低整个机器可用性的障碍。
在windows 2000 的缺省操作中，只允许DNS管理员和创建该资源记录的客户机删除此记录。因此，如果注册一个记录的客户机抛弃了此记录，它将继续保留在DNS数据库里直到其他什么操作被执行而把它清除。使用DHCP协议进行注册的一个动机是：清除旧记录的责任能够被移植到一个更稳定的DHCP服务器上去。别忘了客户机能够改变并且经常改变他们的行动。
7.1.4服务影响
动态DNS的使用也给域区行为带来新的影响，也带来完成工作的新方法。例如：使用DNS记录进行DHCP客户机的注册提供了一个对更早的WINS的DNS集成的标准替换。再比如说，当动态DNS和SRV记录类结合时，动态DNS提供服务广播能力，该服务以前仅可在windows 系统中通过NetBIOS名字获得。
动态域区是指不断变化（至少是可能变化）的域区。不仅要求引入域区传送机制，还带来了一些新的问题。域区传递如何提供对域区一致的拷贝？DNS管理员如何手动地编辑一个域区文件并且在没有版本序列号时如何进行载入？你可能会说：“干嘛要手动编辑呢？动态DNS已经把我们从那一堆改变方法中解脱出来了。”是的。但是域区清理呢？
windows 2000 试图提前考虑这些问题。DNS服务器在传送过程中锁定域区以防改变，然而，对于传送而言，防御的第一要务是使用递增传送的通告选项。其次是根据域区的大小来设计它，以便进行完全传送时，它们能尽量简单（因为锁定的缘故）。DNS服务器的改变日志是如此的“深”，所以当被请求的递增改变超出了日志里已注册的改变时，一些IXFR请求会带来AXFR传送。活动目录集成域区在主服务之间避免了这种可能的问题，但在向辅服务器传递时却未能避免。
