本章内容包括：
设计DNS服务器：讨论了一些与更复杂的DNS服务器层次的发展有关系的一些问题，并推荐了一些设计原则。
对运行中DNS服务器的监测：介绍如何使用windows 2000 中所提供的工具保持对DNS服务器及其配置和运行质量的了解。
改变已注册DNS服务器的IP地址：介绍了改变DNS服务器的IP地址时应考虑的一些重要问题，包括在InterNIC的注册。
用新的DNS服务器提高性能：概括了在已有的DNS服务结构内增加新的DNS服务器的理由和操作步骤。
域区数据维护：介绍了维护域区数据和在服务器之间传送域区数据所涉及的各项工作。
许多决定了DNS服务器工作性能重要决定都是在设计阶段或者在监测到DNS服务器的性能和可靠性不合要求而调整设计时做出的。为了在工作负载最大时DNS服务仍能正常提供并且使DNS服务器的能力跟上变化的需求，DNS管理员需要不断的监测所安装的DNS服务器，包括安装了DNS服务器的机器的性能。软件的服务级别，尤其是与安全相关的补丁必须保持更新。另外还要维护DNS数据库，所涉及工作包括资源记录变化的日常管理，偶尔的将域区移到不同的机器上，机器的取代和重建，此外现在还包括对动态域区的清理以除去过时的记录和检查其大小。
13.1设计DNS服务器
本节介绍了监测DNS服务器的一些方法。要充分利用这些方法，需要对服务有所了解。还需要在普通的操作窗口中确立了有关性能和负载的基线，还应对服务的设计及其能力有深刻的理解。当监视结果显示有问题存在时，查看墙上的图表不是一次狩猎探险，而是考虑一些关系以确定应进行测试的可能是造成问题的地方。服务体系结构的图表应使你清楚什么样的查询是从哪里来的，经过哪里。它还能帮助你看到客户端执行内部和外部解析的路径以及客户端可用的选择。
监测DNS服务器的性能是重要的，能提醒是否应该调整服务，但仅止于此。端用户所感觉到的性能或其他DNS服务器的解析器所感觉到的性能才是真正的度量，仅查看服务器的日志是得不到这种信息时，必须有一种方法评价整个系统，包括影响服务的网络延迟。可以在通常负载下自动地抽样检查，或者采取可靠性或可用性更低的听取用户的反馈的方法。
当找到瓶颈或重负载点后，想一下是否有转移负载的简单的方法。或者说是否需要另一台服务器分担负载？当所有的传输都应该是IXFR时，为什么服务器耗费了许多时间响应AXFR传输？
在开始的设计阶段还应考虑安全策略。安全策略被正确实现了吗？是否需要一个测试程序？对控制和配置变化的监测是否提供了足够的安全保证？
随着时间的推移，设计是会有变化的。比如说你可能发现将客户端配置为直接使用主服务器而不是辅服务器，对你手动执行域区或软件维护是极大的限制。或者说Internet的商业应用可能增加了对外部域名解析的数量，还比如说随着时间的推移一些变化改变了系统。当这些情况发生时，应牢记设计原则并试图调整配置以满足需求，尽可能好地提供服务。
推荐的设计原则如下：
在当前服务和安全补丁级别下易于维护，不会造成对客户服务的降级或中断。
从客户端到该客户端的权威服务器及最经常使用的域区数据的距离应最小化，该距离按网络质量度量。
使域区传送所消耗的网络带宽最小化，所有授权服务器的域区数据的会合所花的时间最短。
每个客户端应可配置至少两条真正独立的解析路径，并且该解析路径只能提供和完全提供站点安全策略所允许的解析访问。将上面的原则翻译成可用的配置选择就得到以下的推荐做法：
使用带通告功能的增量传输（IXFR）
限制除了预定的DNS服务器之间的以外的数据传输
对所有的解析需求按服务器的类型和域区内容提供并行服务器
根据网络质量将服务器的分布本地化至使用服务器的客户端
使用辅服务器实现冗余备份，负载分布，并减轻客户端对主服务器的压力尤其是存储方式是活动目录集成的。
理解和接受动态更新是缺乏安全保证的或者在动态更新被允许的情况下使用只接收安全更新的活动目录存储。理解记录的所有权是如何被分配的，并监视DNS更新代理组的成员资格（可能使它成为一个受限组）以确保没有机器被错误地当作成员。
只允许受信任的客户端查询用于支持活动目录的域区。
不断清除域区数据中过量的，不需要的资源记录。对任何域区意味着清除一些无用的东西，比如不需要的CNAME记录，而对动态域区来说意味着清除过时的记录。
适当地使用前向和缓存服务器，在不需要将域区数据本地化的地方就不提供它。
在主要的站点之间使用桥头堡传输，本地的辅服务器从所在站点的桥头堡服务器获得信息。
理解动态域区变化率和用非更新间隔参数实现的衰减。
在动态更新被允许时，使用清理参数（甚至调整TTL值）调整DHCP协议的租借期。还需要知道当DHCP服务器是或者不是DNS更新代理组的成员时记录的所有权是如何起作用的。
当本地化的到辅服务器的分布可以被最小化时，将包含多个子域的大域区划分成多个独立的域区。
在有合适理由时将服务器配置成拒绝递归查询，比如你的公共服务器。
使服务器的开销最小化。比如在子网掩码排序无益处时禁止它，或通过清理域区以减少缓存的消耗。
这个列表仍能继续下去，尤其是对特定的DNS服务器层次或服务器类型。比如对一些放置在易受攻击地域的服务器应限制其只能在需要的端口使用TCP/IP或UDP协议。随着时间的推移主动到图表前估计重新配置的可能选择。
13.2对运行中的DNS服务器的监测
在小规模的系统中，DNS基本上不需要维护。当系统的传输层次和站点的分布更加复杂时，提供的服务不很理想的地方的数目就会增加。要判定一个大系统是否处于最优的运行态，需要监视和测量。
13.2.1有效地使用微软管理控制台
本书的前述部分已介绍了DNS服务器管理控制台的几乎所有的开关和设置。如果花一些时间深入使用，则启动和停止服务器或单独的域区，使域区重载，强迫磁盘上的域区存储同步的能力以及其他一些选项是应该学习和掌握的。已经提到在控制台里，许多DNS服务器可以连接到一个DNS控制台以方便地管理一组服务器。现在可能已发现很容易忘记将“view(视图)”菜单下的控制台模式设为高级。
可以看到计算机管理控制台被缺省配置为可以访问事件日志、DNS、DHCP、WINS服务器等，但可能并不知道如何定制控制台。
在定义一个定制的控制台时，可以添加或删除任何可用的微软管理控制台的组件及其扩展。因此可能需要确定所在的计算机上有哪些可用组件。建立可用的组件集合的最容易的方法就是安装windows 2000 资源工具箱和管理工具包。在将相应的CD放入光驱后，资源工具箱的安装程序将自动启动。管理工具包是随windows 2000 服务器版本的CD发行的。可以在CD上的.i386目录或已安装好的服务器的%windir%system32目录下找到名字为ADMINPAK.MSI的windows 安装包。类似于其他MSI包，最好通过添加/删除程序安装该包。但也可使用MSI文件的上下文菜单的安装选项。资源工具箱和管理工具包都可安装在工作站版本上用作服务器的远程管理。
要定义一个定制的服务器，只需按以下步骤操作：
1)在开始菜单中运行mmc启动一个空的管理控制台。
2)在控制台的下拉菜单中选择添加/删除管理单元。
3)单击列表框下的“ADD（添加）”按钮。
4)在添加对话框中，你应按列表的顺序选择和添加管理单元。开始是DNS，先使它处于高亮度状态，然后单击添加按钮。
5)同第4步中的操作，选择并添加事件查看器，运行日志和警告，如果需要的话也添加DHCP和WINS。很可能还需要路由和远程访问。一些管理单元，例如事件查看器，可以分别为本地和远程主机。如果选择了本地，以后也可通过上下文菜单切换到远程。
6)完成选择后单击关闭按钮。
7)一些管理单元有注册的扩展。使用添加/删除管理单元对话框中的扩展选项卡并在下拉框中选择路由和远程访问。选中IP路由扩展旁的复选框。该操作将更新下拉框中的列表，在其中现在可选择新添加的IP路由的选择。
8)已完成对所需管理单元的配置后，单击OK按钮返回新的控制台。
9)在控制台的下拉菜单中选择”SaveAs(另存)”以存储该新控制台，指定存储位置(如桌面)并以.MSC为后缀命名。
通过上述操作已将该工具定制为所需要的。以后只需配置添加的管理单元如DNS,DHCP，WINS连接到要管理的服务器。在配置时，选择缺省的模式为作者（Author）模式。作者模式意味着控制台中所配置的管理单元在打开后是可修改的。通过在控制台的下拉菜单中列出的选项对话框中的设置，控制台也可被存储为一些受限制的用户模式。可以使用受限制的控制台给已经被授权了管理任务的人提供面向任务的接口。
windows 2000 的管理能力的一个好的特点就是增加了runas命令。该命令提供了类似于UNIX下的su命令的功能。该命令使你可以先在普通帐号权限下做一些工作，然后在不需要退出的情况下执行一些需要特权的管理任务，此后又自动返回普通帐号。使用命令runas/?可获得完整的语法选项。例如你可以用命令runas/user:topdomain/schmadmin“mmc%windir%system32schmmgmt.msc”执行架构管理控制台，执行时的身份为topdomain中定义的帐号schmadmin。
一种更容易的使用runas命令的方法是在开始菜单中，为新的定制的控制台创建一个快捷方式。然后在该快捷方式上单击右键弹出其上下文菜单，在其中编辑它的属性，选上标记为“RunasDifferentUser”的检查框。完成以后，无论什么时候单击该快捷方式，都会弹出一个对话框，提示以不同的帐号登录，接着在执行的时候的身份就是该帐号。配置了runas命令所受限制的定制控制台提供了一种有效的授权任务和执行任务所需权力的方法。
