本节书摘来自异步社区《DNS与BIND（第5版）》一书中的第10章，第10.12节,作者： 【美】Joseph Davies 更多章节内容可以访问云栖社区“异步社区”公众号查看。
10.12 系统优化
对于大多数名称服务器来说，在BIND的默认配置下就能工作得很好，然而可能其中某个还需要进一步调优。本节将讨论可以用来优化名称服务器的所有配置项。
10.12.1 区域传输
区域传输会给名称服务器带来沉重的负担。所以BIND提供一些机制，可以限制slave名称服务器给master服务器带来的区域传输负载。
1．限制请求单个名称服务器传输的区域数量
在slave名称服务器上，可以限制其一次能够向单个master名称服务器请求传输的区域数量。这样master名称服务器的管理员应该会松一口气，因为当所有区域都发生变化（尤其是牵涉到数百个区域）时，主机不会再由于区域传输而崩溃了。
配置文件的语句如下：
在BIND 9中，还可以针对个别的服务器进行限制，以取代对全局的限制。要达到此目的，需要在server语句中使用transfers子语句，此处的服务器就是想要予以限制的名称服务器：
这个配置将覆盖设置在options语句中的所有全局限制。默认的限制是每个master名称服务器可以同时启动2个区域的传输。这个限制看起来很小，但是它很管用。实际操作起来是这样的：假设名称服务器需要从master名称服务器上载入4个区域，名称服务器会先启动前2个区域的传输并等待传输第3和第4个区域。当前2个区域中的一个传输完毕后，名称服务器开始请求传输第3个区域。当前2个区域中的另一个也传输完毕后，名称服务器开始请求传输第4个区域。最终的结果和限制前一样，所有区域全部传输完毕，但是工作量分散了。
什么时候需要放宽这个限制条件呢？如果发现与master名称服务器完成同步需要花费很长时间，并且知道原因在于需要等待依次传输而不是由于主机间的网络太慢，那就需要放宽限制了。这种情况只有在需要维护成百上千的区域时才可能发生。还要确保master名称服务器和网络能够处理同时传输更多区域所增加的工作量。
2．限制请求传输的区域总数
前面介绍的限制条件只作用于单个master名称服务器。现在所要介绍的限制条件，可以作用于多个master名称服务器。BIND允许对名称服务器同一时间能够请求传输的区域总数进行限制。该限制的默认值是10。前面曾经解释过，名称服务器默认只能同时从任何单个master名称服务器请求传输2个区域。如果名称服务器同时向5台master服务器各请求传输2个区域，则该服务器就已经达到了上限，所以它会将接下来的区域传输请求延后，直到当前的某个区域传输完毕。
在BIND 8和9中，named.conf文件的语句如下：
如果主机或网络无法同时处理10个区域的传输，就应该降低该数值。如果服务器支持成百上千个区域，并且主机和网络能够承受这样的负载，则可以放宽限制（提高该数值）。如果放宽了这个限制，还需要同时放宽对单个名称服务器传输数量的限制。（例如，如果名称服务器只从4台远程名称服务器载入区域，并且名称服务器同时只能对每个远程名称服务器启动2个区域的传输，则服务器最多只能同时传输8个区域。所以除非同时放宽对每个名称服务器传输数量的限制，否则即使放宽了对传输区域总数的限制，也没有任何效果。）
3．限制区域传输服务的总数
BIND 9名称服务器还可以对其同时提供的区域传输服务总数进行限制，这无疑比限制对名称服务器区域传输的请求更加有用。因为如果没有该功能，则只能寄希望于slave名称服务器的管理员大发慈悲，不要让master服务器过载。下面是BIND 9的语句：
该限制条件的默认值是10。
4．限制区域传输的持续时间
BIND还允许限制入站（inbound）区域传输的持续时间。默认情况下，区域传输的持续时间被限制在120分钟（2个小时）。这样做的原因是：超过120分钟的区域传输可能已经失去响应并且无法完成了，该进程只是毫无必要地占用着资源。可以根据实际情况减少或增加该限制时间，比如由于区域中的某个slave名称服务器通常要花费超过120分钟的时间来接收区域数据，则可以使用如下语句：
甚至可以在zone语句中使用max-transfer-time-in子语句对特定区域的传输时间进行限制。例如，如果rinkydink.com区域总是需要很长时间（比如3个小时）进行传输，可能是因为该区域太大，或者因为到master名称服务器的线路太慢，并且还想把其他区域的传输限制到更短的时间（比如1个小时），则可以这么做：
在BIND 9中，可以使用相同的方式（在options语句中或在zone语句中）配置max-transfer-time-out子语句。该语句可以控制出站（outbound）区域传输（也就是向slave发送区域数据）的持续时间。和max-transfer-time-in一样，该语句的默认值也是120分钟。
BIND 9名称服务器甚至允许对区域传输的空闲时间（继续进行区域传输前的停顿时间）进行限制。max-transfer-idle-in和max-transfer-idle-out这两条配置子语句，分别用来控制入站和出站区域传输的空闲时间。如同对传输时间的限制，这两条配置可以作为options或zone的子语句。默认将区域传输空闲时间限制为60分钟。
5．限制区域传输的频率
将一个区域的更新间隔时间设置得太短可能导致区域的slave名称服务器负担过重。例如，如果名称服务器是数千个区域的slave，其中某些区域的管理员将更新间隔时间设置得非常短，则名称服务器可能无法应付所有到来的更新。（如果名称服务器是许多区域的slave，则一定要仔细阅读.6节“限制SOA查询”；因为可能还需要调整允许的SOA查询的数量。）另一方面，没有经验的管理员可能会将区域的更新间隔时间设置得太长，以至于该区域的primary和slave名称服务器之间的数据长期不一致。
BIND 及其后续版本允许使用max-refresh-time和min-refresh-time来限制更新间隔时间。如果在options中使用这两个子语句，则可以限制所有master、slave及stub区域的更新间隔时间；如果在zone中使用这两个子语句，则只能限制特定的区域。两者都以秒数作为参数：
BIND 及其后续版本的名称服务器还允许使用max-retry-time和min-retry-time子语句来限制重试间隔时间，其语法和前面相同。
6．更高效的区域传输
本书前面曾经介绍过，区域传输由多条DNS消息通过TCP连接进行端到端的发送所组成。传统的区域传输中，每条DNS消息仅包含一条资源记录。这很浪费空间：因为每条DNS消息都需要一个完整的TCP报头（header），即使只包含一条记录。这就像只有一个人却开了一辆雪佛兰Suburban（9座的SUV）一样。通过TCP连接发送的DNS消息其实可以携带更多记录：其最大值是64KB！
BIND 8和9名称服务器可以使用一种新的区域传输格式，称为many-answers。这种格式会在一条DNS消息中放入尽可能多的记录。以many-answers格式进行区域传输会节省带宽，因为其开销（即TCP报头）更少，也更节省CPU时间，因为花在解读DNS消息上的时间减少了。
区域的master名称服务器可以通过transfer-format子语句控制区域传输的格式。也就是说，其决定了名称服务器使用哪种格式向它的slave传输区域数据。transfer-format可以作为options和server的子语句：作为options的子语句时，transfer-format控制名称服务器的全局区域传输格式。BIND 8默认使用老的one-answer区域传输格式，以便同BIND 4名称服务器进行交互操作。而BIND 9默认使用many-answers格式。下面的语句：
将名称服务器配置为对所有slave服务器使用many-answers格式进行区域传输，除非使用server语句明确针对特定slave进行如下配置：
如果想充分利用这种新的、更高效的区域传输格式，请执行下列操作之一。
如果大多数slave运行的是BIND 8、BIND 9或Microsoft的DNS服务器（都支持many-answers格式）1，那么可以将名称服务器的全局区域传输格式设置为many-answers（如果运行的是BIND 9，则无须做任何配置）。
如果大多数slave运行的是BIND 4，那么可以将名称服务器的全局区域传输格式设置为one-answer。然后在server中使用transfer-format子语句为例外的服务器调整全局设置。
切记，如果使用BIND 9的master，则需要为所有运行BIND 4的slave，增加一条server语句，明确地将其传输格式更改为one-answer。
**
10.12.2 资源限制**
有时，需要对名称服务器作出限制：禁止使用超出限制值的内存，禁止打开超出限制值的文件。在BIND 8和9中，可以强制进行许多此类限制。
1．改变数据段的大小限制
某些操作系统默认会限制一个进程能够使用的内存数量。如果操作系统禁止名称服务器使用更多的内存，则服务器可能无法正常运行甚至退出。除非名称服务器需要处理非常大量的数据，或者对内存用量限制得比较严格，否则不太可能遇到这种问题。但是如果遇到了，对BIND 8和BIND 及其后续版本的名称服务器而言，提供了相应的配置选项来改变系统对数据段（data segment）大小的默认限制。可以使用这些选项，放宽对named进程的内存限制。
BIND 8和9的配置语句如下：
其中，size是一个整数值，默认单位为byte。如果要指定其他单位，可以通过在数值后附加以下字符之一：k（kilobyte）、m（megabyte）或g（gigabyte）。例如，“64m”就是指64 megabytes。
提示 并非所有操作系统都支持增加单个进程的数据段大小。如果不支持，则名称服务器会发出LOG_WARNING等级的syslog信息，提醒该功能无法实现。
2．改变堆栈（stack）的大小限制
除了可以改变名称服务器数据段的大小限制，BIND 8和BIND 及其后续版本的名称服务器还允许调整系统对named进程堆栈能够使用的内存数量所做的限制。语法如下：
其中，size的格式和上面datasize的一样。同样，该功能只在操作系统允许进程修改堆栈大小的限制时才有效。
3．改变核心文件的大小限制
如果不想让named在文件系统中留下巨大的核心文件，则使用coresize至少可以让其变小一些。相反，如果由于操作系统的严格限制，named无法转储完整的核心文件，则可以使用coresize放宽该限制。
coresize的语法如下：
如同datasize，该功能只在操作系统允许进程修改核心文件大小的限制时才有效，并且BIND 9在之前的版本中不支持该功能。
4．改变打开文件数量的限制
如果名称服务器是许多区域的权威服务器，则named进程启动时会打开许多文件——每个权威区域一个（假使在作为slave的区域上使用备份的区域数据文件的话）。同样地，如果运行名称服务器的主机有许多虚拟的网络接口2，named需要为每个接口生成一个文件描述符（file descriptor）。大多数UNIX操作系统会对每个进程所能同时打开的文件数量加以限制。如果名称服务器试图打开的文件数量超过此限制值，则会在sys__log的输出中看到如下信息：
如果操作系统允许更改每个进程可以打开的文件数量，则可以使用BIND的files子语句来增加它：
默认值是unlimited（这也是一个有效值），虽然这表示名称服务器对同时打开的文件数量不做限制；然而，操作系统却可能会做限制。另外，BIND 9在之前的版本中不支持该功能。
5．限制客户端的数量
BIND 9允许对名称服务器可以同时服务的客户端数量加以限制。可以使用recursive-clients子语句，限制递归型客户端（解析器以及将该名称服务器作为转发器的名称服务器）的数量：
P264C
默认值是1000。如果发现名称服务器拒绝递归查询，并在日志中记录了如下错误信息：
则可能需要提高限制值。相反，如果发现名称服务器疲于应付接踵而来的递归查询，则可以降低该限制值。
还可以使用tcp-clients子语句，限制名称服务器可以同时处理的TCP连接（区域传输和基于TCP的查询）的数量。TCP连接比UDP连接消耗更多的资源，因为主机需要追踪TCP连接的状态。默认的限制值是100。
6．限制SOA查询的数量
BIND 及其后续版本的名称服务器，可以限制名称服务器允许等待处理的SOA查询数量。如果名称服务器是上千个区域的slave，那么随时都可能有许多针对这些区域SOA记录的查询请求等待处理。追踪每个查询请求都需要一定数量的内存，因此，在默认情况下，BIND 8名称服务器将等待处理的SOA查询数量限制为4。如果发现名称服务器无法完成其作为slave的职责，则可能需要使用serial-queries子语句来提高该限制值：
BIND 9不使用serial-queries子语句。BIND 9所限制的是并发查询的速率（每秒20条），而不是等待处理的查询数量。可以使用options的子语句serial-query-rate对限制值加以调整，该子语句使用一个整数（每秒查询条数）作为参数。
10.12.3 维护间隔时间
BIND名称服务器会周期性地进行维护工作，例如更新区域数据（如果该服务器是slave的话）。在BIND 8和9中，可以控制维护工作的频率，或者是否进行维护。
1．清理间隔时间
所有的名称服务器只会被动地从缓存中清除过时的条目。在名称服务器返回一条记录给查询者之前，它会检查该记录的TTL值是否过期。如果已经过期，则该名称服务器会启动解析进程，以取得最新的数据。然而，完全依靠这种机制可能会导致大量不必要的缓存占用。名称服务器在一连串的域名解析后可能会缓存大量的记录，并且只是让它们留存在缓存中，占用宝贵的内存空间，即使这些记录已经过期。
为解决该问题，BIND名称服务器会在每次清理间隔时间到期时，主动查看缓存并清除过期记录。这有助于减少缓存数据使用的内存数量。另一方面，清理进程也会占用CPU时间，在非常慢或者非常忙碌的名称服务器上，可能不想清理得太频繁。
清理间隔时间默认为60分钟。可以在options语句中使用cleaning-interval子语句来调整此间隔时间。例如：
该配置将清理间隔时间设置为120分钟。要完全关闭缓存清理功能，可以将该值设置为0。
2．接口的检查间隔时间
前面曾经说过，BIND在默认情况下，会监听主机的所有网络接口。BIND 8和9实际上更聪明，能够知道主机上的网络接口何时启用和停用。为了做到这点，它们会定期扫描主机的网络接口。这会按照接口的检查间隔时间（默认为60分钟）来执行。如果运行名称服务器的主机没有动态的网络接口，则可以将接口的检查间隔时间设置为0，从而停止扫描新的接口，以避免每个小时产生不必要的开销：
另一方面，如果主机过于频繁地启用或停用网络接口，则可以将检查间隔时间缩短。
3．统计间隔时间
虽然调整统计间隔时间（BIND 8名称服务器将统计信息转储到统计文件中的间隔时间）不会对性能造成多大影响，但是将其与其他维护间隔时间一起，放在这里进行介绍更为合适。
statistics-interval子语句的语法跟其他维护间隔时间完全一样：
并且，与其他维护间隔时间一样，其默认值也是60分钟，设置为0则停止定期转储统计信息。因为BIND 9不会将统计信息写入syslog，所以它没有可配置的统计间隔时间。
10.12.4 TTL值
在内部，BIND会将缓存记录的TTL值削减至合理的值。BIND 8和9名称服务器允许配置此限制值。
在BIND 8.2及其后续版本以及所有BIND 9名称服务器中，可以使用options的子语句max-ncache-ttl对缓存中否定信息（negative information）的TTL值加以限制。这给升级至8.2及其新的否定缓存方案（RFC 2308以及相关内容，本书第4章已进行说明）的人提供了一张安全网。新版本名称服务器会根据区域SOA记录最后一个字段的设置来缓存否定信息，但是许多区域管理员仍将该字段当作区域的默认TTL值来使用——这对于否定信息来说可能太长了。因此，一个谨慎的名称服务器管理员可以使用如下子语句：
这会将否定缓存的TTL值削减至1小时。其默认值是10 800秒（即3小时）。如果没有这种预防措施，可能会出现如下状况：有人查询一条新的记录却得到否定应答（可能因为这条新记录还没有到达区域的slave），并且其名称服务器会将该应答缓存相当长的时间，从而导致该记录无法解析。
BIND 9名称服务器允许使用max-cache-ttl子语句，配置缓存记录TTL值的上限。默认值为1周。BIND 8名称服务器也将该TTL值削减为1周，但并不允许对该上限进行配置。
最后，还有一个被称为lame TTL的名词，实际上它并不是一个TTL值，而是指名称服务器缓存问题服务器（指给定的远程名称服务器不是所授权区域的权威服务器）的时间。这可以避免名称服务器浪费宝贵的时间和资源，向另一名称服务器询问其一无所知的域名信息。BIND 8自8.2版开始、BIND 9自版开始，允许使用options的子语句lame-ttl来调整lame TTL值。其默认值为600秒（即10分钟），最大值为30分钟。甚至可以将该值设置为0以关闭对问题名称服务器的缓存，尽管这么做会非常糟糕。
