BIND 高级特性（一）－－ 转发 forwarder

orward first | only;
forward指令用于设置DNS转发的工作方式：
forward first设置优先使用forwarders DNS服务器做域名解析，如果查询不到再使用本地DNS服务器做域名解析。
forward only设置只使用forwarders DNS服务器做域名解析，如果查询不到则返回DNS客户端查询失败。

最新的 BIND 提供了很多非常好的新特性，今天就先讲其中的一个：转发 （ Forwarder ）。 

某些网络连接不鼓励向本地以外发送很大的数据流量，这要么是因为网络连接是按流量计费的，或网络连接本身是带宽不足。在这样的情况下，如果想将发往外部的 DNS 流量限制到尽可能的小，就需要使用 BIND 的转发机制。或者你的网络中只有一台机器能连接到 Internet ，而你在这台机器上运行了 BIND ，那么你可以将这台 BIND 作为内部网络中的其他 BIND 的转发器，使得其他 DNS 也能查找 Internet 域名。 

转发机制的这样的：当你设置了转发器后，所有非本域的和在缓存中无法找到的域名查询都将转发到设置的 DNS 转发器上，由这台 DNS 来完成解析工作并做缓存，因此这台转发器的缓存中记录了丰富的域名信息。因而对非本域的查询，很可能转发器就可以在缓存中找到答案，避免了再次向外部发送查询，减少了流量。 

转发器的配置格式是： 
options {  
    forwarders { 192.168.24.35; 192.168.24.36; }; 
}; 

这里要注意，转发器本身不用做任何设置，而是对需要转发器的其他 DNS server 做以上配置。还有，如果该 DNS Server 无法联系到转发器，那么 BIND 会自己尝试解析。 

如果你要禁止 BIND 在无法联系到转发器时不做任何操作，那么你还可以使用 forward only 命令，这样 BIND 只能使用区的权威数据和缓存来响应查询了（ 在连接不到转发器的情况下 ）。 
options {  
    forwarders { 192.168.24.35; 192.168.24.36; }; 
    forward only; 
}; 

在 BIND 8.2 以后引入了一个新的特性：转发区（ forward zone ），它允许你把 DNS 配置成只有查找特定域名的时候才使用转发器。（ BIND 9 从9.1.0 才开始有转发区功能 ）例如，你可以使你的服务器将所有对 xmgd.com 结尾的域名查询都转发给 xmgd.com 的两台名字服务器： 
zone "xmgd.com" { 
    type forward; 
    forwarders { 210.52.83.228; 210.52.83.229; }; 
}; 

这样的功能有什么用呢？假设 xmgd.com 和你的网络有一个私有的连接，而 xmgd.com 又没有连接上 Internet ，那么你从 Internet 是无法查到 xmgd.com 后缀的域名的，这时你就要使用转发区的功能了。 

还有一种转发区设置和刚才的设置刚好相反，它允许你设置什么样的查询将不被转发，当然这只适用于在 options 语句中指定了转发器的 DNS 。配置如下： 
options {  
    directory "/var/named";     
    forwarders { 192.168.24.35; 192.168.24.36; }; 
}; 

zone "xmgd.com" { 
    type master; 
    file "zone.xmgd.com"; 
    forwarders {}; 
}; 

这样写你可能会问为什么你要在自己的权威区里禁止转发？难道不是自己回答查询而不使用转发器吗？ 
有这样一种情况，在 xmgd.com 这个区中，你授权了几个子域，例如：zx.xmgd.com、lab.xmgd.com 等，那么在 xmgd.com 的权威服务器上设置转发后，因为对 zx.xmgd.com、lab.xmgd.com 这几个子域不是权威，那么如果有对 www.zx.xmgd.com 这样的子域的域名查询，服务器也将转发。这完全是没有必要的，因为服务器上就有 zx.xmgd.com 子域的 NS 记录，何须再转发。

DNS转发器：
假设我的DNS服务器 192.168.1.10
在BIND中有这么一个配置

[code]

forward only;
forwarders {
192.168.1.12;
};

[/code]

 

这里的192.168.1.10解析不了的，就会被转发到192.168.1.12这就是DNS转发器。

说到这里就不得不说递归了。

 

二、BIND递归查询：
默认 Resolver 发出的是递归查询，而且默认 BIND name server 也处理所有的递归请求

递归查询的工作方式
递归查询是最常见的查询方式，域名服务器将代替提出请求的客户机（下级DNS服务器）进行域名查询，若域名服务器不能直接回答，则域名服务器会在域各树中的各分支的上下进行递归查询，最终将返回查询结果给客户机，在域名服务器查询期间，客户机将完全处于等待状态。
示例： （红色为查询，蓝色为迭代查询返回的提示信息，棕色为递归查询返回的IP信息）

 

 

 

示例说明：A向B发送递归查询请求，B向C发送迭代查询请求（下一节将介绍迭代查询），得到C给出的提示后，B向D发送迭代查询请求，得到D给出的提示后，B向E发出迭代请求，得到E给出的提示后，B向F发出迭代查询请求，得到F给出的提示后，B得到了F返回G的IP地址，B向A返回G的IP地址，整个查询结束。

迭代查询的工作方式
迭代查询又称重指引，当服务器使用迭代查询时能够使其他服务器返回一个最佳的查询点提示或主机地址，若此最佳的查询点中包含需要查询的主机地址，则返回主机地址信息，若此时服务器不能够直接查询到主机地址，则是按照提示的指引依次查询，直到服务器给出的提示中包含所需要查询的主机地址为止，一般的，每次指引都会更靠近根服务器（向上），查寻到根域名服务器后，则会再次根据提示向下查找。从上节的图中可以知道，B访问C、D、E、F、G，都是迭代查询，首先B访问C，得到了提示访问D的提示信息后，开始访问D，这时因为是迭代查询，D又返回给B提示信息，告诉B应该访问E，依次类推。
说明：假设你要寻找一家你从未去过的公司，你会有2种解决方案，1是找一个人替你问路，那可能是你的助手，2是自己问路，每走过一个路口，就问一个人，这就好比递归查询和迭代查询，递归查询在这里代表你的第1种解决方案，而迭代则是第2种解决方案。

 

但某些情况下，服务器应该被配置为不接受递归请求，例如根域服务器。根域服务器不接受递归请求的原因 ：

一、因为根域服务器太忙了，它们没有精力来回答递归查询。
二、接受递归请求将会建立缓存，如此根域服务器的缓存将会变得十分巨大

关于递归/非递归方面的配置语句有 recursion no和 allow-recursion 语句。两者都只能放在 options 或者 view 语句中
recursion no 只对外部域名有效，如果查询的是本地zone域名（仅限于该 name server 上所定义的 zone，不包括下级子域）则可以回答。因为解析外部域名需要查询外部 name server ，这才是 recursion no 控制和关心的部分，如果查询的是本地 zone 的数据，当然不需要担心本地 name server 被诱导，可以直接返回答案。

 

要注意以下几点；
一、保证该非递归服务器不出现在客户机的 /etc/resolv.conf 的
二、保证该非递归服务器不被其他 name server 当成转发器 （forwarder）
三、推荐使用 allow-recursion 而不是 recursion
四、该非递归服务器可以出现在 zone data file 的 NS 记录中。它可以正常的接收其他 name server 发来的查询
五、外部 name server 是通过上级域的 Referral 消息找到该非递归服务器的
六、外部 name server 在得到上级域的 Referral 消息后，向该非递归服务器发送的查询是 iterative query ，而不是 recusive query ，所以该非递归服务器仍然可以回答那些它所权威的 zone 的查询。但不能用于查询外部域名了。