动态DNS和活动目录（3）

　　7.3.8DHCP和DNS更新代理组

　　为了减少复杂性，微软映射了一个使用DHCP协议的预先设置的路线。不再是客户机获得资源记录的所有权而在清除上让它们的行为变得独立，而是让DHCP执行注册。这样，DHCP是所有者，并且能够修改和清除资源记录。这非常好，但仍然有些小问题。

　　如果使用缺省的DHCP行为，windows 2000 结束了对A记录的所有权，DHCP拥有了对它的IP协议的PTR记录的所有权。这是很合理的因为客户机拥有名字，DHCP拥有IP协议。如果客户机改变了它的名字或者重新加入了域，于是它就抛弃了域中的一个记录，对非windows 2000 的客户机，DHCP可能既注册名字又注册IP，所以会同时拥有两个记录，那么当多个DHCP服务器被配置为共享一个子网的责任时就会带来一个问题，因为仅仅只有一个服务器能改变A记录，而它们中的任何一个或许都有此记录（注意通常每个服务器都有一个唯一的IP池，所以PTR记录没有此问题）

　　要解决这些问题，windows 2000 提前定义了一个特殊的组，即DNS更新代理组。当一台机器成为这个组的一个成员时，它创建一个新的DNS记录，这个记录比已经讨论的记录的语义稍有不同，不是创建者自动地成为记录的所有者，被Dns更新代理成员创建的记录被成功地对其进行更新或刷新的帐户所拥有。

　　尽管这样试图解决了一些问题，但又带来了其他的问题。非常重要的一件事是诸如使用DHCP协议的机器将会成为这个组中的一员，所以，所有那些机器动态创建的记录都将有新的语义。如果一台机器这样注册了任何记录，不管是通过对客户使用DHCP还是通过自身注册，那些记录都会应用新语义。当一台机器，如一台域控制器执行许多动态更新时，这不是一个小问题（见下一节）。

　　Dns更新代理组试图用DHCP服务器作为成员，这允许它们对客户注册A记录，并且当它们试图更新记录时从客户机那里获得对那些记录的所有权。任何由运行DHCP的机器动态注册的记录，包括它本身的记录或当Netlogon也为一个域控制器时所创建的SRV记录，当此机器是一个Dns更新代理成员时，都会被剥夺所有权。解决的办法当然是不使用这样的机器作域控制器，并且对Dns更新代理组成员手工键入DNS条目。

　　7.3.9DNS安全小结

　　本章涉及了一些基本知识。活动目录集成使得可以用安全的方法来对DNS数据的访问进行控制及更新。没有这个集成，windows 2000 就不能提供任何DNS安全措施。

　　更新的保护是通过由RFC2078所规定的方法的微软版本而实现的，现今这个方法是微软特有的。windows 2000 客户机需要扩展为使用第三方DNS服务器，这个服务器使用基于RFC2137和2535的安全措施。被保护的动态更新过程在windows 2000 中支持Kerberos作为安全提供者。DNS服务器在代表客户机更新DNS数据时，本身使用LDAP方法。

　　当DNS数据存储到活动目录时，要接受通常的ACL权限验证，缺省值提供给授权用户组创建资源记录的能力，以及Everyone组列出域区和读取资源记录的能力。这些权限来源于dnsZone和dnsNode架构对象，在windows 2000 的最初版本中，这两个架构对象只能在此处改变，或者在它们被创建以后再在资源记录中改变。

　　资源记录被创建以后由创建它的帐户所有，除非这个帐户是DNS更新代理组的成员。在这种情况下，对新建记录首次成功进行更新或刷新的帐户将成为它的所有者。

　　对于安全动态更新，微软策略的最初框架是为活动目录集成DNS域区配置的。它有好的方面，也有不好的方面。在严厉地批评以前，先考虑一下这是一个先行者，是动态DNS新领地的开拓者。当今没有其他商业操作系统在安全和动态DNS的实现这条道路上走得如此之远，这应该是正确的。它们中的大部分功能的实现不得不在产品的时限、必需的功能以及复杂的RFC标准之间求得平衡。现在它们中有一些已标准化，有一些还没有。最新的RFC对DNS数据安全和更新依赖于正在建立的公钥机制，但windows 2000 已经准备参与了。在windows 2000 中如何使用动态DNS以及如何在动态DNS上实施安全措施，都必须经过仔细考虑。

　　7.4活动目录对SRV记录的依赖

　　对活动目录高效的操作部分地依赖于客户机的能力和服务器在组成活动目录的域中快速定位关键服务的能力。DNS是完成上述大部分工作的一种方式。

　　举个例子来说，当一个域成员机器启动时，它必须和本域的域服务器通信，并且在第一台域控制器不能包括全局目录时，它还得跟另一个域控制器通信。或者再举个例子，当一台机器上的客户在枝繁叶茂的活动目录里提出一个对不同域的资源的请求时，那个域的域控制器在决定是接受还是拒绝客户请求中起作用。

　　当需要域中已经定位的资源时，例如客户机在自身的域中打开一个共享文件夹时，就不需要用到DNS服务。然而经常第一步就需要这种定位服务，在windows 2000 体系结构中，正是用DNS来实现这种定位的。

　　为了使这些过程尽可能地高效，windows 2000 维护着一个相当复杂的SRV记录和CNANE记录集，域控制器上的Netlogon过程对它负责，使用动态更新建立它，并且在记录被认为是不合法时进行删除。

　　7.4.1域定位器服务

　　一个windows 2000 客户机可以使用关于域的三种类型的信息来尝试找到一个域控制器：域名（即最初版本中的DNS域）；一个全局唯一的标识号ID（GUID），即一个域内部的唯一的名字；一个站点识别标识符。在试图定位DC时（因为大多数关键服务都在DC上），客户机将这些信息传递给域定位器服务。

　　活动目录能够依据被用来代表网络拓朴结构的站点来划分。单个域可以存在于多个站点，一个站点又可能包含于多个域，也就是说，一个站点里可能有来自多个域的机器。当有可能进行一个查询服务时，站点被用来加速“本地”机器间的网络通信。

　　windows 2000 域定位器可以全部使用客户机能够提供的这三种类型的信息全部使用，来对一个查询尽量高效地获取IP地址。如果客户机知道自己位于哪个站点，并且在一个指定的域里请求一个诸如LDAP服务的特殊服务，第一步可能就是查询指定给被请求域和站点的_ldap._tcpSRV记录，如果定位器已经知道域的一个DC的话，它也能向DC发送LDAP查询来验证那时已返回给客户机的信息。

　　定位器服务使用期望存在于DNS数据库里的有关域名的知识。如上所述，DC上的Netlogon服务建立和维护了这些使用动态更新的注册。当动态更新被禁止时，就变得不可能了，而且这种查找过程的有效操作变成了某些倒霉的人的责任。不过，当DC和站点的拓扑是静态的和可利用的，这并不是一项如它看起来那样令人恐惧的任务。

　　7.4.2SRV的结构

　　Netlogon注册了记录的许多不同的层次。图7-8给出了只有一个DC时，对一个单个的小的域活动目录的这种结构的一个扩展部分。换句话说，这是一个能说明问题的最简单的一个图示。

　　首先要记住的是在一个大一些的环境里，将有不同的IP地址的多个记录，或者一些注册有相同的IP地址。当客户机查询一个特别的名字时，所有的匹配记录都用来决定返回的IP地址。在这样的环境里，也能看到对每个域的更多的条目，以及建立在位于活动目录根部（域森林的根域）域之下的一个更大的条目集。图7-8所示的内容是DNS服务器管理控制台里的，给出了一个子域结构的印象。实际上，这种结构逻辑上是在SRV记录的名字字段而不是域字段中创建的（见图7-1）

　　接下来要注意到有对LDAP、GC、Kerberos和kpasswd服务的记录。LDAP用于LDAP服务，在windows 2000 中总是位于DC上。GC用于全局目录服务，也是总位于DC上，但不是全部位于，在windows 2000 中，kerberos服务器和kerberos密码改变服务器也总是在域控制器上。

　　所有的记录使用TCP协议，除了两个与kerberos相关的服务同时也能使用UDP协议。这可见于SRV记录协议部分的_TCP和_UDP。

　　在名字里有站点的限定词的条目被用来依据它们在活动目录拓扑中的位置来划分服务，因为用于指定站点的特别的DC不一定意味着这个机器物理上在这个站点里，或者说只是在逻辑上作为站点成员而定义在活动目录站点拓扑里。当一个站点对一个特殊服务没有本地提供者时，Netlogon注册了它认为最合适的域控制器，这个站点里的成员应该首先尝试它的服务，Netlogon如何基于站点拓扑作出决定不是DNS的问题，所以本书中不涉及到这一点。重要的是要记住当Netlogon能使用动态DNS更新来调节SRV记录时，活动目录的功能更为优化。

　　这个结构通过一个记录有_msdcs的限定进一步地详细拟定了可利用的服务。在这些服务里有一定的特殊广播，借如一个限定为pdc的广播代表域中的一个DC，像NT4中对低级客户机的PDC仿真程序一样工作。条目集被每个域复制。另外，在只有活动目录的根域为人所知的情况下，用于在活动目录内定位的条目才会在活动目录的顶层DNS域下被详细描述。

　　如果需要手动地维护这个结构，建议你找出所有可用的当前信息。你的整个操作将从这个精确反映活动目录的结构里获益。

　　7.4.3没有动态DNS的SRV条目

　　当禁止使用动态DNS更新时，必须用手工方法进行域区数据管理。这不仅包括预期的记录类型－A、PTR、CNAME、NS等等，还包括Netlogon提供的SRV和CNAME记录。如同已描述的那样，SRV记录处于活动目录体系结构中域定位器服务的核心部分，是必需的

　　当运行dcpromo来形成一个域控制器时，创建一个SRV记录的最小列表NETLOGON.DNS（程序清单7-1）并存储在％windir%\system32\config。尽管如此，只看到这个非层次的列表并不能表达手工维护SRV记录的全部影响。