从功能上来看，活动目录与DNS八杆子打不到一起。但是DSN与活动目录是不可分割的。或者说，如果离开了DNS，那么Windows2008域环境将无法工作。这主要是因为活动目录需要利用DNS进行资源的查找，从客户登陆到全局目录查找，都离不开DNS。所以对于需要部署或者升级AD的系统管理员来说，必须要深入了解DNS与活动目录这种息息相关的特性。在这篇文章中对此做一番分析。不过师傅领进门，修行还靠自身。
有域管理经验的用户一定知道，如果DSN出现问题，那么就可能会给活动目录环境带来毁灭性的灾难。2008的域环境也是如此。因为域环境中所有服务器和客户端都需要经常性的彼此进行相互查找。如客户端要使用打印机或者登陆到某个文件服务器，都需要进行查找。在这个过程中，如果DNS出现问题，导致名称解析服务中断，那么就会严重影响到活动目录的功能。
为此为了提高域环境的安全，推荐在任何活动目录域环境中都必须安装冗余的DSN设备(这不是强制的，但是笔者强烈建议这么处理)。如果不具备这个条件的话，也需要考虑复制DSN主区域，并借像重视保护全局目录AD索引一样来保护DNS。也就是说，DNS就是域环境的生命线。另外，建立对AD集成的区域进行安全更新，并且设计网络时让DHCP服务器与域控制器向分离。这些措施都有利于提高DNS服务器的安全。
二、非微软DNS与2008域环境的集成
在实际工作中可能由于种种原因，没有将DNS服务器部署在Windows2008系统上，甚至没有部署在微软的操作系统中。如DNS服务器可能采用的是Unix系统等等。在这种情况下，非微软的DNS能够对2008域环境提供支持吗?答案是肯定的。
在2008域环境中，特定编写的活动目录域服务器能够与非微软的DNS实现共存。不过这有一个前提。这个DNS服务必须支持活动更新和SRV纪录。换句话说，DNS服务可以运行在各种其所能够支持的操作系统上。但是如果要跟2008域环境集成的话，必须支持更新和SRV纪录。否则的话，2008活动目录不能够通过这个DNS来实现查找功能。
不过微软的专家并不建议这么做。他们强烈推荐在2008域环境中，最好将DNS服务部署在Windows2008操作系统上。因为采用相同的操作系统环境，在功能、稳定、安全等层面上会有额外的收货。如操作系统版本不同或者品牌不同，则有些功能会受到一定的限制。
其次如果用户所采用的DNS版本比较低或者说不原意将活动目录客户程序直接驻留在企数据库中(有时候出于硬件的限制会采取这种措施)时，系统管理员可以简单的将活动目录DNS授权给可以在其中充当权威服务器的分离的区域。然后再由Windows2008操作系统摄之道外部DNS实现的转发器。此时就可以提供对原始区域中资源的解析。在实际工作中，这是经常采用的一种方法。对于企业中没有独立的DNS服务器或者非微软的DNS服务器中组建活动目录环境具有很大的帮助。
第2页：学会使用次区域来解决问题
三、学会使用次区域来解决问题
在某些情况下，即使DNS工作正常，活动目录也会存在一定的故障。如在同位体根域模型中，两颗分离的树构成同一森林内不同的名称空间。此时他们之间的相互访问就会受到影响。为了解决问题，此时需要使用次区域。
那是什么原因造成这个问题的呢?这主要是因为在同位根域模型中的每一颗树是由在其他域中可能没有安全权限的独立的域构成。为此就需要一种合适的机制允许在两颗树之间执行查找。简单的说，就是因为没有查找权限所造成的。在这种情况下，通常是在每个DNS环境中，创建次区域来解决这个查找的问题。虽然在2008种有效的解决了这个问题，如将这些分离的树复制到森林中所有DSN服务器的功能，减少了次区域的使用频率。但是在一些复杂的环境中，如需要在森林以外进行查找，则这个次区域仍然是必需的。
不过需要注意的是，使用次区域可能会导致性能上的瓶颈。用户在查找资源或者登陆的过程中，可能会感觉到性能的下降。所以在没有充分必要的情况下，在域环境中最好不咬使用同位根域模型。这可能会导致性能问题，同时也会增加维护的复杂性。
四、提高DNS查找效率、优化活动目录性能
从以上的分析中可以看出，域环境要正常工作的话，必须依赖于DNS。如当用户需要进行打印，则先是通过DNS来查找相关的资源。从中可以看出，DNS的查找效率直接跟域环境的性能相关。如果其查找效率低下，则必然会导致活动目录的性能降低。反过来说，就是提高DNS的查找效率，就可能优化活动目录的性能。
这里以Windows2008环境为例，介绍一个提高DNS查找效率的简单办法。在站点容器的根中通常包含一个特定域的所有控制器的列表。当特定的站点服务不可用时，则就采用这些列表进行名称解析。也就是说，如果某个站点域控制器失效的话，客户端就会随即的选择这个站点中存储的一个域控制器。所以如果能够确保这个位置存储的项仅仅是快速连接中心站点的服务器，就可以明显提高DNS的查找性能。
一般情况下，在Windows2008中是将SRV纪录的存储位置划分成一个单独的区域，并将其复制到安装了DNS的所有域控制器上。在这个区域中加入一项资源，如打印机，他们指示在这些特定站点上有哪些可用的资源。在部署服务器之前创建活动目录站点时来自中心位置的一个SRM纪录会被添加到DNS中的站点子域中去。此时当向这些站点添加一个新的资源时，他们的SRV纪录会与站点创建时存储在其中的其他SRV纪录结合。即不会自动删除这些纪录或者覆盖它。这就会错误的引导客户端通过由低速广域网链路到达服务器。这直接的结果就是导致登陆时间延长。简单的说，就是走了冤枉路。虽然说条条道路可以通罗马，但是路径的长短、路径的通行情况等等会影响到最后达到的时间。故在配制域环境的时候，需要合理部署，以提高DNS的查找效率。如在必要的时候，适当的整理这些SRV纪录并将其放置在合适的站点子域，必将会大大缩短DNS查找时间，从而缩短客户登陆时间，提高活动目录的工作效率。
第3页：经验总结
从以上的分析中可以看出，DNS对于Windows2008的活动目录息息相关。其不仅关系到活动目录是否能够正常工作，而且还关系到其工作的性能。为此在部署活动目录的时候，往往需要先建立或者调整原有的DNS环境。在后续性能优化时，也需要两者一同考虑。当活动目录无法正常工作，如无法正常登陆时，往往也是从DNS开始查起。在下篇文章中，笔者可能会分析一下常见的DNS查找故障以及排错相关的内容。大家如果有需要的话，请关注笔者后续的总结。这或许能够对大家维护2008域环境提供一定的帮助。
这里以Windows2008环境为例，介绍一个提高DNS查找效率的简单办法。在站点容器的根中通常包含一个特定域的所有控制器的列表。当特定的站点服务不可用时，则就采用这些列表进行名称解析。也就是说，如果某个站点域控制器失效的话，客户端就会随即的选择这个站点中存储的一个域控制器。所以如果能够确保这个位置存储的项仅仅是快速连接中心站点的服务器，就可以明显提高DNS的查找性能。
一般情况下，在Windows2008中是将SRV纪录的存储位置划分成一个单独的区域，并将其复制到安装了DNS的所有域控制器上。在这个区域中加入一项资源，如打印机，他们指示在这些特定站点上有哪些可用的资源。在部署服务器之前创建活动目录站点时来自中心位置的一个SRM纪录会被添加到DNS中的站点子域中去。此时当向这些站点添加一个新的资源时，他们的SRV纪录会与站点创建时存储在其中的其他SRV纪录结合。即不会自动删除这些纪录或者覆盖它。这就会错误的引导客户端通过由低速广域网链路到达服务器。这直接的结果就是导致登陆时间延长。简单的说，就是走了冤枉路。虽然说条条道路可以通罗马，但是路径的长短、路径的通行情况等等会影响到最后达到的时间。故在配制域环境的时候，需要合理部署，以提高DNS的查找效率。如在必要的时候，适当的整理这些SRV纪录并将其放置在合适的站点子域，必将会大大缩短DNS查找时间，从而缩短客户登陆时间，提高活动目录的工作效率。
从以上的分析中可以看出，DNS对于Windows2008的活动目录息息相关。其不仅关系到活动目录是否能够正常工作，而且还关系到其工作的性能。为此在部署活动目录的时候，往往需要先建立或者调整原有的DNS环境。在后续性能优化时，也需要两者一同考虑。当活动目录无法正常工作，如无法正常登陆时，往往也是从DNS开始查起。在下篇文章中，笔者可能会分析一下常见的DNS查找故障以及排错相关的内容。大家如果有需要的话，请关注笔者后续的总结。这或许能够对大家维护2008域环境提供一定的帮助