《DNS与BIND（第5版）》——4.8运行一个slave名称服务器

本节书摘来自异步社区《DNS与BIND&＃xff08;第5版&＃xff09;》一书中的第4章&＃xff0c;第4.8节,作者&＃xff1a; 【美】Joseph Davies 更多章节内容可以访问云栖社区“异步社区”公众号查看。

4.8 运行一个slave名称服务器

为增强健壮性&＃xff0c;需要再建立一个名称服务器。可以&＃xff08;并且最终可能会&＃xff09;为区域建立两个以上的权威名称服务器。当然两个名称服务器是最低要求了。如果只有一个名称服务器而它又宕机了&＃xff0c;那么就没有人可以查询域名了。第二个名称服务器可以分担第一个名称服务器的负载&＃xff0c;或在第一个名称服务器宕机时承担全部工作。可以再建立一个primary名称服务器&＃xff0c;但本书不推荐这样做。本书推荐再建立一个slave名称服务器。如果决定耗费额外的精力去运行多个primary名称服务器&＃xff0c;也可以随时将slave名称服务器改成primary名称服务器。

服务器是如何知道它是某个区域的primary还是slave呢&＃xff1f;named.conf文件会告诉名称服务器它是某个区域的primary名称服务器还是slave名称服务器。NS记录并不会告知哪个服务器是区域的primary以及哪些服务器是区域的slave&＃xff1b;它们只会告知这些服务器是谁。&＃xff08;总的来说&＃xff0c;DNS并不在乎名称服务器是primary还是slave&＃xff1b;对于实际的名称解析而言&＃xff0c;slave服务器与primary服务器并无区别。&＃xff09;

那么primary名称服务器和slave名称服务器之间到底有何区别呢&＃xff1f;最关键的区别在于服务器从哪里获取数据的。primary名称服务器是从区域数据文件中读取数据的。而slave名称服务器则是通过网络从其他名称服务器那里加载数据的。这个过程被称作区域传输&＃xff08;zone transfer&＃xff09;。

slave名称服务器不仅可以通过primary名称服务器加载区域数据&＃xff0c;还能通过其他的slave名称服务器加载区域数据。

slave名称服务器的最大好处在于&＃xff1a;对于一个区域只需维护一份区域数据文件&＃xff0c;也就是primary名称服务器上的那份文件。不用担心这些名称服务器之间的文件同步问题&＃xff1b;slave名称服务器会做好这些事情。需要注意的是&＃xff0c;slave名称服务器的再同步&＃xff08;resynchronize&＃xff09;并不是实时的&＃xff1a;它会以轮询&＃xff08;poll&＃xff09;的方式来查看区域数据是否是最新的。决定轮询间隔时间的是SOA记录中的一个还没有解释过的数字。&＃xff08;BIND 8和BIND 9支持一种加速区域数据分发的机制&＃xff0c;本书在后面会讨论到。&＃xff09;

slave名称服务器并不需要从网络上获得所有的区域数据文件。像db.cache和db.127.0.0这两个系统必备的文件&＃xff0c;在slave和primary上是一样的&＃xff0c;因此只要在slave名称服务器上保存一份本地副本即可。这意味着slave名称服务器其实是0.0.127.in-addr的primary。当然也可以将它设置为0.0.127.in-addr的slave&＃xff0c;但该区域的数据永远不会改变&＃xff1b;它就像primary一样。

4.8.1 建立
为了建立slave名称服务器&＃xff0c;需要在运行slave名称服务器的主机上为区域数据文件创建一个目录&＃xff08;例如&＃xff0c;/var/named&＃xff09;&＃xff0c;并将文件/etc/named.conf、db.cache和db.127.0.0复制过去&＃xff1a;

https://yqfile.alicdn.com/5dbb30131df2441548b3c9df98e5baca02ce73d4.png" >

必须修改slave名称服务器上的/etc/named.conf文件。将每个出现的master都改为slave&＃xff08;0.0.127.in-addr.arpa区域除外&＃xff09;。并且添加带有primary名称服务器IP地址的masters行。

如果原先的配置文件中有如下所示的行&＃xff1a;

https://yqfile.alicdn.com/854616a6780e86a53aa85f5bf795c593e34a2042.png" >

那么修改过后会变成下面这个样子&＃xff1a;

https://yqfile.alicdn.com/0c5512580084f8f0f93954f204556776ab5df991.png" >

这会告诉名称服务器&＃xff0c;它是区域movie.edu的slave&＃xff0c;并且应该追踪名称服务器192.249.249.3上所保存的该区域的版本。slave名称服务器会在本地文件bak.movie.edu上保留该区域的一个备份。

对于电影大学而言&＃xff0c;在wormhole.movie.edu上建立了其slave名称服务器。回忆一下toystory.movie.edu&＃xff08;primary名称服务器&＃xff09;上的配置文件&＃xff0c;看起来就像这样&＃xff1a;

https://yqfile.alicdn.com/cebbe36991d45f6ab0cfc00501834b1954ac4a81.png" >

将/etc/named.conf、db.cache以及db.127.0.0复制到wormhole.movie.edu上&＃xff0c;并像先前描述的那样来编辑配置文件。现在wormhole.movie.edu上的配置文件看起来就像这样&＃xff1a;

这将导致wormhole.movie.edu上的名称服务器通过网络&＃xff0c;从位于192.249.249.3&＃xff08;toystory.movie.edu&＃xff09;上的名称服务器那里加载movie.edu、249.249.192.in-addr.arpa以及253.253.192.in-addr.arpa。它也会将这些文件备份到/var/named目录下。你可能会发现把这些区域数据文件的备份独立放到一个子目录中会更加方便。在给备份文件命名时加入了像bak这样唯一的前缀&＃xff0c;因为在极少数情况下&＃xff0c;可能必须得手工删除所有的备份文件。这样做还有一个好处&＃xff0c;就是能够让人一眼就发现它们是区域数据文件的备份&＃xff0c;这样就不会误编辑它们了。稍后会进一步介绍备份文件。

现在启动slave名称服务器。就像启动primary名称服务器时那样检查syslog文件中的错误消息。同primary名称服务器一样&＃xff0c;启动slave名称服务器的命令也是&＃xff1a;

与primary名称服务器不同的是&＃xff0c;对于slave名称服务器而言&＃xff0c;还得检查它是否创建了备份文件。在启动wormhole.movie.edu上的slave名称服务器之后不久&＃xff0c;就应该会看到bak.movie.edu、bak.192.249.249以及bak.192.253.253出现在/var/named目录下。这就意味着slave名称服务器已经成功地从primary名称服务器上加载了这些区域&＃xff0c;并保存了一份备份副本。

要完成slave名称服务器的建立工作&＃xff0c;还得尝试查找一下原先在primary名称服务器启动后查找过的那些域名。这次必须在运行slave名称服务器的主机上运行nslookup程序&＃xff0c;以保证所查询的是slave名称服务器。如果slave名称服务器运行正常&＃xff0c;就在系统的启动文件中添加相应的行&＃xff0c;以便slave名称服务器能够随着系统一同启动&＃xff0c;并将hostname(1)设置成一个域名。

4.8.2 备份文件
slave名称服务器并未被要求保存区域数据的备份副本。如果有备份副本的话&＃xff0c;则slave服务器就会在启动时读取它&＃xff0c;并且随后再检查master服务器上是否有更新的副本&＃xff0c;而不是一开始就从master服务器上加载一个新的副本。如果primary名称服务器有了较新的副本&＃xff0c;那么slave名称服务器就会将其下载并保存在备份文件中。

为什么要保存一个备份副本呢&＃xff1f;设想一下&＃xff0c;在slave名称服务器启动时&＃xff0c;primary名称服务器宕机了。则slave将无法进行区域传输&＃xff0c;并且在master服务器恢复前&＃xff0c;它也无法作为这个区域的名称服务器来提供服务。有了备份后&＃xff0c;slave名称服务器就有了区域数据&＃xff0c;尽管可能有些过时。由于slave不再需要master服务器始终处于运行状态&＃xff0c;所以这种设置更加健壮。

如果不想要备份副本的话&＃xff0c;就移除配置文件中的file行。然而&＃xff0c;本书还是推荐将所有slave名称服务器都配置成保存备份副本。保存区域数据文件的备份只需花费很小的代价&＃xff0c;可一旦遇到非常需要备份文件却没有的时候&＃xff0c;就要付出沉重的代价了。

4.8.3 SOA值
还记得下面的SOA记录吗&＃xff1f;

本书还没有解释括号中间的这些数值都是做什么用的。

区域中的所有数据都会用到序号&＃xff08;serial number&＃xff09;。这里选择“1”这个逻辑上的起点来作为起始序号。但是很多人发现使用日期作为序号会更有用&＃xff0c;就像2005012301。这个日期的格式是YYYYMMDDNN&＃xff0c;YYYY代表年份&＃xff0c;MM代表月份&＃xff0c;DD代表天&＃xff0c;而NN则代表当日区域数据被修改的次数。这个字段只有在这种排序下才起作用&＃xff0c;因为没有其他的排序能总是随着时间的改变而增加。无论选用何种格式&＃xff0c;在更新了区域数据后&＃xff0c;都不要忘记增加序号的值&＃xff0c;这很重要。

当slave名称服务器联系其master服务器以获取区域数据时&＃xff0c;会首先请求相关数据的序号。如果slave中该区域的序号比master服务器的小&＃xff0c;就表示slave的区域数据过时了。在这种情况下&＃xff0c;slave就会下载一份新的区域数据副本。如果slave名称服务器启动时没有可读取的备份文件&＃xff0c;它总是会从其master服务器那儿加载区域数据。正如所猜想的那样&＃xff0c;当修改primary上的区域数据文件时&＃xff0c;必须增加序号值。关于如何更新区域数据文件的问题&＃xff0c;本书将在第7章中予以介绍。

接下来的4个字段指定了四种时间间隔&＃xff0c;默认单位是秒。

refresh&＃xff08;更新&＃xff09;

更新间隔时间&＃xff08;refresh interval&＃xff09;用来告知区域的slave名称服务器&＃xff0c;间隔多长时间检查一次区域的数据是否有更新。需要注意的是&＃xff0c;这个功能会对系统负载造成影响&＃xff0c;slave名称服务器每隔一个更新间隔时间就对每个区域进行一次SOA查询。这里所选的数值是3小时&＃xff0c;这属于相当快的频率了。大多数用户在等待他们的新工作站变得可用之前&＃xff0c;可以容忍半个工作日的延迟&＃xff0c;以便让区域数据扩散开来。如果站点提供的是24小时服务&＃xff0c;那么应该考虑将这个值提高到8小时。如果区域数据并不经常改变&＃xff0c;或者所有的slave名称服务器散布得很远&＃xff08;就像root名称服务器那样&＃xff09;&＃xff0c;那么可以考虑将这个值设置得更长一些&＃xff0c;比如24小时。

retry&＃xff08;重试&＃xff09;

如果slave名称服务器在更新间隔时间到来后无法访问其master名称服务器&＃xff08;主机可能宕机了&＃xff09;&＃xff0c;它就会开始每隔一个重试间隔时间&＃xff08;retry interval&＃xff09;就尝试重新连接一次。通常重试间隔时间会比更新间隔时间短&＃xff0c;但这不是必须的。

expire&＃xff08;过期&＃xff09;

如果slave名称服务器在过期时间到来时仍无法联系到其master名称服务器&＃xff0c;则slave就会使该区域失效。使一个区域失效意味着slave将不再回答对于该区域的查询&＃xff0c;因为该区域的数据已经过于陈旧而不能使用了。本质上&＃xff0c;这个字段的意义在于&＃xff1a;在某个时刻&＃xff0c;数据变得太陈旧了&＃xff0c;与其提供陈旧的数据还不如不提供的好。通常过期时间会以周为单位&＃xff0c;如果在访问更新源时频繁出现问题&＃xff0c;可以将该时间设得长一些&＃xff0c;例如1个月。过期时间总是远远长于更新间隔时间和重试间隔时间。如果过期时间比更新间隔时间小&＃xff0c;那么slave名称服务器会在尝试加载新的数据前就使该区域失效。

negative caching TTL&＃xff08;否定缓存TTL&＃xff09;

TTL代表着生存时间&＃xff08;time to live&＃xff09;。这个值适用于所有来自该区域权威名称服务器的否定响应。

提示

在BIND 8.2之前的版本中&＃xff0c;SOA记录中的最后一个字段既是区域的默认生存时间&＃xff0c;也是该区域的否定缓存生存时间。
看过本书早期版本的读者可能会注意到&＃xff0c;SOA记录的数字字段所使用的格式发生了改变。从前&＃xff0c;BIND只允许以秒为单位来设定前面介绍的四个字段。&＃xff08;因此&＃xff0c;所有那一代的管理员都知道一周有608 400秒。&＃xff09;现在&＃xff0c;除了最老的BIND名称服务器&＃xff08;BIND &＃xff09;&＃xff0c;其他的BIND名称服务器都允许使用秒以外的单位来设定这四个字段的数值&＃xff0c;以及作为TTL控制语句的参数&＃xff0c;就像本章前面所展示的那样。例如&＃xff0c;可以指定用3h、180m&＃xff0c;甚至是2h60m来指定3个小时的更新间隔时间。还可以用d代表天&＃xff0c;用w代表周。

SOA记录的最佳设定值完全取决于站点的需要。一般来说&＃xff0c;较长的时间可以降低名称服务器的负载&＃xff0c;但是会增加变动的传播时间&＃xff1b;较短的时间会增加名称服务器的负载&＃xff0c;但是可以缩短变动的传播时间。本书中所使用的数值对于大多数站点都是合适的。RFC 1537建议顶级名称服务器采用如下数值&＃xff1a;

有一个功能的实现应该要了解下。对于早期版本&＃xff08;之前的版本&＃xff09;的BIND&＃xff0c;slave名称服务器在加载区域时会停止响应查询。因此&＃xff0c;新版的BIND被修改为将加载区域的时间分散开来&＃xff0c;以缩短不能响应查询的时间。所以&＃xff0c;即使设置了一个很短的更新间隔时间&＃xff0c;slave名称服务器也可能无法按照所要求的时间来进行检查。BIND会尝试加载一定数量的区域数据&＃xff0c;然后等待15分钟以后&＃xff0c;再加载下一批。

现在已经介绍了slave名称服务器是如何保持其数据是最新的&＃xff0c;BIND 8和BIND 9还改变了区域数据的传播方式&＃xff01;轮询功能依然存在&＃xff0c;但BIND 8和BIND 9还增加了当区域数据变动时发出通知的功能。如果primary名称服务器和slave名称服务器运行的都是BIND 8或者BIND 9&＃xff0c;那么primary会在区域数据发生变动后15分钟内&＃xff0c;通知slave加载新的区域数据。该通知会导致slave名称服务器缩短更新间隔时间&＃xff0c;并试图立即加载区域数据。本书会在第10章中进一步介绍。

4.8.4 多个master服务器
还有其他方法能让slave名称服务器的配置变得更加健壮吗&＃xff1f;答案是肯定的&＃xff0c;可以最多指定10个master服务器的IP地址。在配置文件中&＃xff0c;把这些地址添加到第一个IP地址之后&＃xff0c;并用分号隔开&＃xff1a;

在BIND 9.3及其后续版本中&＃xff0c;可以为master服务器的IP地址列表指定一个名称&＃xff0c;然后引用这个名称。这样就不用为每个区域重复列出这些IP地址了。下面是一个例子&＃xff1a;

https://yqfile.alicdn.com/f983a6bd91a65fe6f1938a6a56e801779b1841aa.png" >

slave名称服务器会按照列表中IP地址的排列顺序&＃xff0c;来依次查询每个master服务器&＃xff0c;直到其得到答复。一直到BIND &＃xff0c;slave名称服务器都是选择第一个响应的、拥有较高序号的master名称服务器来进行区域传输。只有在前面的master名称服务器无响应时&＃xff0c;slave才会尝试查询随后的master。然而&＃xff0c;从BIND 8.2开始&＃xff0c;slave名称服务器实际上会查询列出的每个master名称服务器&＃xff0c;并选择拥有最高序号的master来进行区域传输。如果有多个master服务器都拥有最高的序号&＃xff0c;那么slave名称服务器就会选择列在最前面的那个来进行区域传输。

这个功能的初衷是&＃xff0c;如果运行区域的primary名称服务器的主机是多宿主主机的话&＃xff0c;那么就能够列出其所有的IP地址了。然而&＃xff0c;因为无法判断所联系的名称服务器是primary还是slave&＃xff0c;所以如果对设置有帮助的话&＃xff0c;就可以列出该区域所有运行slave名称服务器的主机的IP地址。这样一来&＃xff0c;如果第一个master名称服务器宕机或者不可达的话&＃xff0c;slave名称服务器还能通过另一个master名称服务器传输区域数据。