|
一旦你配置完DNS，并且它开始工作以后，DNS通常被认为是一个“黑盒”，想要找出它为什么会出问题是非常困难的。而你的Exchange环境的正常状态受你的网络的DNS操作的正常状态所束缚。DNS问题对Exchange产生的不利影响有三个级别：在Exchange Server和DNS服务器之间的整体连通性，DNS服务器的整体性能，以及DNS服务器的完整性（也就是说，从一个技术角度和最佳实践观点所作的最佳配置）。你所遇到的每个DNS问题都可以归到这些分类中。我会提供一个有关于DNS的核心组件，以及解决特殊级别问题时你该采取的方法的详细分析。了解DNS问题的不同级别以及解决问题过程需要一个特殊的方法都可以使DNS变得不再神秘，这样对于Exchange管理员来说，DNS就不再是黑盒了。我将从着眼于DNS相关的连通性和性能问题开始，而在以后的文章里，我将会研究DNS的完整性问题。
连通性问题
解决连通性问题需要测试Exchange服务器是否可以和提供DNS服务的服务器通信。连通性并没有集中于DNS服务器整体应用程序的状态，也就是说，DNS是否对查询做出适当的响应或者区域（zones）是否存在，并且被正确地配置。解决DNS连通性问题不仅仅是解决端口的连通性，因而需要有关于基础网络的知识要比DNS应用程序内部更多的知识。
一个解决DNS连通性问题的基础是确保TCP和UDP端口53对于你的Exchange服务器都可用。一个人们常犯的错误是认为只需要UDP端口53。虽然这对于简单的DNS查询（比如Nslookup查询）是正确的，但是Exchange需要TCP和UDP来满足DNS的要求。当对端口53进行基本的连通性测试时，从Exchange服务器的“透视图（perspective）”中运行这些测试是十分重要的。在较大的Exchange执行操作中，不同的防火墙规则和区域可能会阻碍Exchange访问DNS服务器，当从一个穿过不同网络路径的工作站中运行测试时，也许会注意不到某个位置。
确认连通性。确认基本的连通性只是确认DNS连通性步骤里的第一步。一旦你连接到了TCP和UDP端口53，你需要确认服务器已经适当地配置为可以在这些端口上接收到DNS的查询。就Windows服务器而言，不同于其它平台，DNS不能在端口53以外的其它端口配置为侦听事件。注意：如果一个其它服务是在端口53上侦听，那么DNS服务就不能启动了。因此如果DNS服务已被启动，并且你可以通过TCP和UDP端口53进行连接，那么你向确保基本连通性的道路上又前进了很长的一段路。
你最后需要检查的是确定在宿主服务DNS请求的网络上没有IP冲突。如果存在冲突的话，DNS服务可能被成功启动，但是直到冲突被解决后，才能与网络通信。所以为了使你的Exchange环境通过DNS连通性测试，你的网络必须满足下列四个基本要求：
• DNS服务应该已经启动。
• 服务器能收到在TCP和UDP端口53上的通信。
• 没有IP冲突。
• 没有端口冲突。
注意：你所使用的DNS服务可以在Windows系统（DNS Server服务）或UNIX系统（named—name server—daemon）中运行。如果你可以连接到你的DNS服务，并且确信你所连接到的服务真的是DNS，那么你可以开始调查DNS服务的状态了。
解决连通性问题
如果你连接不上，你会做什么？你如何解决该问题取决于连通性测试什么内容失败了。你只能连接到TCP上吗？还是你根本不能连接？你确认过基本条件吗？表1总结了与DNS连接可能的连通性问题以及在哪产生的问题（客户端、服务器端，或者网络）。
表1：产生DNS连通性问题的可能原因
在你调查网络问题以前，先开始调查你本地的连通性是十分重要的。你可以通过从本地服务器执行一个简单的Telnet或者Nslookup到它本身上来完成这个操作。注意要通过“locally”（没有包括你的网络）来执行这个测试，你可以排除一些最初的网络问题。如果由于某种原因，这些测试失败了，并且你已经检查了你的DNS服务器服务已经被启动了，而且没有IP或者端口冲突，很可能是一个本地软件过滤器导致了连通性问题。本地软件过滤器包括软件防火墙、路由器（例如，RRAS），网卡IP过滤器，以及任何其它的第三方可以控制数据进出网络接口的软件，包括Ipsec在内。
因此，系统管理员常常可以快速的调查，并且发现由于网络原因而导致的Exchange问题，而且常常是正确的。一些会产生问题的硬件配置，比如防火墙、路由器，或开关通常被认为是产生网络问题的主要原因。当你调查硬件过滤器问题时，最好先从本地网络的子网开始调查，然后扩展到除那个子网以外的远程子网中。
场景1：在相同子网中的Exchange Server
最简单的例子是当宿主在相同的子网内。当宿主在相同的子网上时，如防火墙和路由器之类的设备在设备之间并不扮演直接传递通信的角色。只有连接两个服务器的开关才能确定通信是否在服务器之间传递。如果你知道子网掩码是正确的，而两个服务器仍然不能“Ping”通彼此，只有开关的安全配置，比如一个Virtual LAN（VLAN）或ACL能够阻碍通信。因此，当你遇到一个在相同子网上的服务器的DNS问题时，你的解决方案应该集中于安全之上。
场景2：在远程子网上的Exchange Server
当服务器不在相同的子网上时，解决方法就会变得更加复杂了。实际上，表2里所罗列的Invalid gateway项说明了一些可能性。以这个表作为一个出发点，你可以首先从确定你所要解决问题的范围开始：本地子网或者远程子网。如果你的DNS服务器和有问题的DNS客户端（例如一个Exchange服务器）在相同的子网上，你可以使用表2里的本地子网范围。
表2：网络连通性问题
一旦你缩小了范围，就可以把问题的焦点转到网络中相应的组件上。因为网关与路由不相称，或者它自己的网关、路由表，及其它组件不正确，所以网关可能会是无效的。你可以对远程宿主执行一个追踪，这对于确定问题所在会非常有用。该追踪将告诉你一个Exchange服务器是否可以连接到目标网络或一个可识别目标网络的网关上。当调试一个远程宿主时，你应该从集中在你的子网和远程子网（我们假定子网掩码是正确的）之间的路由测试开始。
Exchange服务器可以连接到其它宿主上。如果需要你解决问题的那个DNS客户端（Exchange服务器）可以连接到DNS服务器所在的远程网络中的其它宿主，该远程机器也许有一个无效的子网掩码或者网关设置。该远程宿主或端口可能会有一些特殊的安全设置，会阻止你的Exchange服务器与它连接。如果你连接不上远程网络里任何其它的宿主，使用一个追踪（如果你的网络中已经启用了追踪）来确认你到达该远程宿主有多“远”。例如：如果在你的网络的两个子网之间有五个路由器，一个追踪可能会显示在第三个hop上出现连接断点。这个信息会告诉你也许在第三个hop路由器上存在一个路由问题。它可能丢失了到下一个网络的路由，或者有一个ACL故障或其它问题阻止到达目标网络的通信。
Exchange服务器可以连接到网络上，而连接不上宿主。如果你可以连接到远程网络，而连接不到宿主，你或许需要处理一个与安全有关的问题。也许特定端口被阻止了。还有可能（但是也不太可能）是所有的宿主都设置了无效的子网掩码和网关。网关也可能会有一个无效的子网掩码。如果你没能连接到远程宿主网络，你应该从“本地”开始。图1显示了这个流程的整个步骤。
图1：当Exchange服务器可以连接到网络，而连接不到宿主时，使用的基本方法的解决步骤
检查你的本地路由表是否包含任何到目标网络的路由。如果路由表包含有到目标网络的路由，通过“ping”或追踪可以访问你所使用的网关吗？网关正确吗？子网掩码正确吗？如果你没有到目标网络的路由，你会使用默认的网关。可以访问它吗？网关正确吗？子网掩码正确吗？
如果你的默认网关可以访问，而且是正确的，但是你不能访问远程网络，你可以执行一个追踪来找出哪个网关出了问题。追踪失败位置的网关或许有一个缺失的路由，无效的网关，或者不正确的子网掩码。
如果你已经确认了所有到远程网络的路由，但仍然不能连接到远程宿主上，很可能是与安全有关的问题。如果可能的话，尝试用不同的端口或者使用不同的方法来连接宿主。“Ping”是最常用，也是最明显的方法来测试基本的连通性，但是你的网络可能禁用了“Ping”（以及追踪）。这样或许需要你使用另外一个方法，比如Telnet来测试连接。例如：如果你知道该机器运行了Terminal Services，试着在端口3389上执行一个Telnet。如果可以成功地远程登录到宿主上，但你却“ping”不通它，你就知道了只是DNS被阻止了。因此，既然所有的到宿主网络的路由看上去都是正常的，而你仍然不能连接，你可以假定又是个安全的问题了。不幸地是，准确地知道安全配置问题出现在哪儿需要你调查硬件设备上的特殊配置，而这些硬件设备也许是一个你无法访问的防火墙或路由器。
解决性能问题
优化性能是大多数管理员所追求的目标，但是却很难实现。你的Exchange服务器的性能受各种因素的影响，从硬件配置到软件参数，再到应用程序的冲突。为了对“应有”的性能有一个认识，你了解一下Exchange环境的开发过程是十分重要的。典型环境的性能是什么样呢？典型性能实际上是最佳的吗？第一个问题很好回答，但是确定第二个问题的答案就是个技术问题了。
基线。建立一组基线对了解一个特殊环境的典型性能模式必不可少。如果你没有历史数据来进行比较，那么判断性能是否变慢会是非常困难的。另外，没有历史基线，你将很难确定你所做的优化工作是否成功地提高了性能。为你的Exchange环境创建基线不仅仅包括收集有关主要组件（如处理器或内存）的基本信息，你还需要收集与你的DNS服务有关的数据。
测量。想知道测量什么以及何时测量与DNS性能有关的项是十分困难的。测量众所周知的组件，比如CPU、内存和磁盘，是一个合适的开始位置。你可以通过使用Windows System Monitor（也称为性能监测器）或其它第三方的监控产品来容易地收集这些测量值。然而，如果你只测量这些组件，当DNS服务或Exchange服务器的另一个组件出现问题时，你就无法觉察出问题了。因此，如果你能测量与DNS服务相关的组件，如CPU、内存，以及磁盘I/O，那就最好不过了。
为了评估你的Exchange环境里的DNS性能，或许在你的DNS服务器上需要测量的最重要的（并且最恰当的）数值是DNS响应时间，也就是说DNS服务器对查询的响应速度是多快。具备这个基线统计值相当重要，这样当你的DNS响应时间降低到正常程度以下时，你就可以及时地发现问题了。至少，你可以了解你的DNS服务过去的执行情况，以及对于你的Exchange环境来说，CPU、内存、磁盘I/O以及响应时间是否标准。
不幸地是，并没有“DNS响应时间”的性能计数器。为了测量DNS的响应时间，你需要检查Windows System Monitor计数器，比如TCP Query Received/Sec以及TCP Response Sent/sec，并且比较它们。收到一个查询的较高比率，以及一个明显变慢响应的比率都暗示可能存在一个性能问题。你可以用UDP Query Received/sec和UDP Query Response/sec来使用这个相同的技术。当你开始查看由于TCP或者UDP查询（或者二者同时使用）而导致的性能问题时，你可以通过检查用于这些请求的内存以及或者查看这样的请求的数目是否异常地过高或过低，来对产生这些问题原因做更进一步的调查。
此外，了解这些数值是否非常重要十分依赖于你的基线。如果这些数值都大大高于你所看到的历史数据的结果，你就可以确信自己正在体验一个性能下降情况。一个快速的Google搜索会检索出几个第三方的工具，它们可以帮助你测量和确定一个你的DNS响应时间的基线。如果你不想使用这样的工具，而是倾向于使用脚本就获得同样的体验，你可以编写一个使用一个嵌入DNS请求的脚本，它可以记录在一个DNS请求结束前后的时间戳来评估特定的查询的响应时间。
记住，往往其它的因素还会对DNS服务的性能产生不利的影响。例如：一个流氓进程可能会消耗CPU，并且导致DNS服务器看起来好像变“慢”。这不是一个使用DNS服务直接产生的问题，而是一个使用流氓进程影响DNS服务的问题。同样重要的是考虑组件间的相互依赖性，以及在一个组件上产生性能问题所带来的连锁反应。例如：当系统内存不足时，它开始占用更多的磁盘空间，会导致较高的I/O。了解并考虑这些在服务器上以及它的服务间的交互作用对于解决DNS性能问题至关重要。
解决。当你解决关于CPU问题时，先要检查你所收到的请求。一个异常大量的TCP或UDP请求会引起CPU问题。正如我在本文前面所提到的，一般会通过你的平均客户来执行UDP请求，而TCP请求被Exchange所使用。如果你看到大量的TCP请求，这是一个检查Exchange相关请求的提示，而不是解决例如简单的查找宿主名的问题。查找，区域传送请求会引起较高的CPU使用率。当区域没有被正确配置时，一个异乎寻常地完整区域传送常常会引起性能问题。如果某些Exchange服务器没有同步，那么它们将请求完整区域传送，而不是增量的传递。如果你发现对于你的Exchange组织出现了比标准情况更多的区域传送请求时，你需要调查你的下游（downstream）DNS服务器，传送的目标有可能是产生问题的原因。
你可以根据TCP和UDP使用的内存消息来识别内存问题，这样会便于确定产生内存性能问题客户种类。既然我们知道了TCP DNS请求是由Exchange服务器产生的，例如，单独地由TCP产生的问题会指引我们把Exchange服务器作为DNS客户端来进行检查。异常的内存缓存或数据库内存可以被认为是一个DNS服务的内存问题。磁盘I/O问题一般与CPU或者内存问题有直接关系，它会引起磁盘写入比平常更多的信息。因此，当你每次调查一个磁盘I/O问题时，你应该并行地调查CPU和内存问题。
在大型环境里，一个常见的DNS性能问题的原因是不均衡地分配客户端负载。在小型环境里，DNS性能问题可能是源于其它的负载，比如在一个运行DNS以及许多其它程序的服务器上所产生的负载。你的DNS基础结构应该被设计成可伸缩的，而且客户端被配置为以一个分布式方式使用DNS服务器，这一点十分重要。这就意味着在你的组织里不是有一个“主”和“副”DNS服务器，而是考虑一个整体结构：一个服务器服务于你的组织里的一半客户端请求，而另一个服务器服务于你的组织里的另一半客户端请求。这样，负载被均匀地分布在两个DNS服务器上，就不会出现主服务器已经过载，而副服务器只有在主服务器无响应时才被启用。取决于你的环境的规模，你可以采取不同的方法来为你的客户完成一个更加平衡的DNS服务器分配方式。实际上，在小型组织里可能并不需要关心这个问题。然而，如果你决定想要更加均衡地分配DNS负载，你可以利用多个DHCP范围，这样会分配不同的DNS数据给客户机器，并且会确保带有静态的DNS入口的服务器在DNS服务器上的负载也以这样的方法而分配。
控制DNS解决方法
解决DNS问题的可以被看作是一个Exchange管理员工作中更具考验的部分。但是通过沿用本文所建议的方法，并根据问题的特殊症状将DNS问题分类，你将会在自己的Exchange环境里更加自如的克服DNS问题。 | 
