级别： 初级 IBM,
2002 年 8 月 01 日 IBM eServer 开发者园地收集的适用于 IBM eServer 硬件和相关软件开发人员的内容和资源在不断增加，专注于 iSeries、pSeries、xSeries 和 zSeries 开发人员的内容，IBM eServer 开发者园地提供了文章、样本代码、教程、how-to、工具、新闻、案例学习、论坛 — 几乎包含开发人员希望或需要能帮助他们完成工作的所有东西。
Sendmail 和 BIND 有许多共同之处。这两个软件包都是因特网上的实际标准。它们都快有 20 年的历史了。它们都可以免费获得。它们都包含相似的设计特征，如分布式计算模型和面向事务的客户机-服务器协议等。它们有如此多的共同之处或许是因为 Sendmail 和 BIND/域名服务（DNS）一直就非常紧密地集成在一起？这一集成正是为什么任何高性能 Sendmail 解决方案的重要部分都少不了高性能 DNS 的原因所在。
尽管存在几个 BIND 的替代方案，但我们没有对它们进行过评估。本文下面引用了 D.J. Bernstein 的 DNS 服务器作为一个突出的示例。
DNS 配置
DNS 服务器是越新越好，因此请使用版本 9.1.0 或更高版本。我们所有的测试都是使用该版本完成的。DNS 服务器 9.x 版及更高版本使用线程编程范例，该范例能更好地利用多处理器机器，尽管对于除了最忙碌的站点或已实现的站点之外的其它站点而言，使用 IPv6/DNSSEC 将不会有太多好处。请跟上 BIND 的任何变化，并且至少一年计划一次升级。
通常，想法是使 BIND/DNS 尽可能地靠近 Sendmail 服务器。在每台 Sendmail 服务器上放置仅高速缓存（caching-only）的名称服务器是个好主意。它无需维护，并且可以通过累积高速缓存中的记录来降低网络负载。作为另一种方法，您也可以在每台 Sendmail 服务器上安装完整的 DNS 从服务器。如果 Sendmail 服务器面向因特网，那么这些完整的 BIND 从服务器可向因特网第三方查找（他们查找您的记录）提供服务，还可以满足本地 Sendmail 守护程序的需要（您查找其他人的记录）。这还会使本地名称的查找变得更快（它们在从服务器区域文件中），但增加了配置／维护需求。
定期清理 DNS 服务器的高速缓存。最简单的方法可能就是重新启动 named 进程。理论上，这不是必需的，但这是确保您的高速缓存不被塞满的安全方式。
留心观察 BIND 的内存占用。本地记录和高速缓存都保存在内存中，这会使 BIND 随着时间的推移而变大。在大约两周后，记录将以被添加时的近似速率因过期而从高速缓存中删除，因此 BIND 的内存大小应该处于稳定的状态。如果您考虑对内存进行限制，请使用
ulimit -m SIZE来设置一个合理的内存限制。
对于高速缓存服务器和从服务器，您可能需要使用转发器（forwarder），而不是使用缺省设置，后者将对任何新的区域进行递归式根提示（root-hint）搜索。选择一两个可靠的 DNS 服务器，通过它们转发请求。
DNS 大小估计
尽管您的 DNS 服务器可能每天处理着数量惊人的事务，但协议很少并且不需要太多的服务器硬件。在原始容量方面，大多数中型公司只要用两个新式的单处理器工作站级的机器就可以可靠地提供 DNS 服务。将一台机器安装为本地主服务器，另一台则作为从服务器。DNS 有良好的文档记录，并且有极佳的日志记录和统计控制。尽您最大努力按照峰值使用情况确定 DNS 的大小，并且定期收集统计信息以检查您的假设。要进行样本统计信息转储，将“add statistics-file /tmp/named.stats;”加至 /etc/named.conf 的选项部分。然后向 named 进程发送 kill -SIGILL。当前的统计信息将转储至 /tmp/named.stats。将这些信息保留一段时间，并且观察趋势。您或许会对 DNS 服务器所做的大量工作感到惊讶！
操作系统考虑事项
RedHat Linux（和其它操作系统）包括名称服务高速缓存系统，这就带来了高速缓存名称服务器的一些好处。在以别的方式不可能运行完整的高速缓存名称服务器时，这可能有助于减少网络流量，但它的主要作用是加速 NIS+ 查询。遗憾的是，只对 A 记录进行高速缓存，因此没有提供对 MX 记录进行高速缓存的操作。Nscd 是 Glibc-2.2.2 源代码的一部分。
在 Linux 中，确保 /etc/nsswitch.conf 只包含正被使用的名称服务。缺省 Redhat 文件包含对 NIS+/NIS 的引用。这简化了通过 Glibc 的代码路径，并且在理论上会逐步提高名称查找的速度。
对于 /etc/resolv.conf，更多并不意味着更好。列出的服务器不超过三台，因为缺省 glibc 行为是根据后退／重试（fallback/retry）的次数进行连续搜索。当对第四台主机进行查询时，前面所有的进程可能都已经因超时而终止了。
Sendmail 考虑事项
Sendmail 的当前缺省 DNS 行为可能对于大多数安装都是合理的。它只是遵循了 Linux 操作系统在查找事物时所遵循的规则，即 /etc/resolv.conf 和 /etc/nsswitch.conf 控制一切。如果您有更多异乎寻常的需要，请查看 Sendmail 配置文档中的“O ResolverOptions”。另外，“O Timeout.resolver.*”也可用来调整解析器的行为。
参考资料
关于作者  | | | IBM has authored this article |
对本文的评价
| 
