要搭建缓存服务器（Caching only DNS）需要先了解DNS名称解析方式以及域(domain)、区域(zone)的基本概念。下面就介绍这些基本概念。
一、域、区域的概念及DNS名称解析方式
一个域(domain)可以理解为一个或多个区域(zone)的集合，这些区域是体现在DNS服务器的解析库文件上的，也就是一个解析库对应一个区域。对于一个域来说，受其管理的有下层的子域或主机，既可以根据FQDN解析为IP地址，也可以根据IP地址反向解析为FQDN。而区域有正向解析区域和反向解析区域两种，正向解析区域负责由FQDN查询到IP地址，而反向解析区域负责由IP地址解析到FQDN。
因此，域(domain)是一个逻辑概念，而区域(zone)则是一个物理概念。一个区域有真正用于实现解析功能的解析库文件，它是真正“看得着、摸得见”的。当然，域和区域的关系并非是域总是大于区域，因为一个区域同样可以由多个该区域负责的域的子域和主机组成。
总结一下，DNS名称的解析方式有两种：
①正向解析：根据FQDN查询到IP地址的流程。
②反向解析：根据IP地址查询到FQDN的流程。
二、DNS资源记录类型
上面提到，一个区域可以是正向解析区域或者反向解析区域，每个区域都有其对应的解析库文件，而每个解析库文件一般由多条资源记录（Resource Record，简称RR）组成，这些资源记录包含了当前区域的信息，例如当前域（要解析的是哪个域）、资源记录类型（有什么样的资源）以及TTL值（记录的缓存时间）等。接下来介绍一下DNS的资源记录类型有哪些。
| Resource Record | 记录类型说明 |
| SOA | Start Of Authority，起始授权记录。一个区域解析库有且只能有一个SOA记录，而且必须放在解析库文件中的第一条位置。 |
| NS | Name Server，域名服务记录。一个区域解析库可以有多个NS记录，其中有一个NS记录为主DNS服务器的记录。 |
| A | Address，地址记录。根据A记录可以依据FQDN查询到IPv4地址，即实现正向解析。 |
| AAAA | 地址记录。根据AAAA记录可以依据FQDN查询到IPv6地址，即实现正向解析。 |
| PTR | PoinTeR（就是指向的缩写），反向解析记录，根据PTR记录可以依据IP地址查询到FQDN。 |
| CNAME | Canonical Name，别名记录。 |
| MX | Mail eXchanger，邮件交换器。 |
资源记录的定义格式：
语法： Name TTL IN RR_TYPE value
其中对于不同的资源记录类型来说，这里的Name和value的含义各不相同。
SOA记录：
Name：当前区域的名字，例如"itab.com."或者"2.3.4.in-addr.arpa."。
value：由三部分组成：
(1)当前区域的区域名称（也可以是当前区域内的主DNS服务器名称）。
(2)当前区域管理员的邮箱地址。但邮箱地址中不能使用@符号，一般使用点号替代。
(3)主从服务协调属性的定义以及否定答案的缓存时间TTL（这部分内容用括号括起来表示）。
示例：
itab.com. IN SOA ns1.itab.com. dnsadmin.itab.com. ( 2017032901 ; serial 1H ; refresh 10M ; retry 2H ; expire 1W ) ; negative answer ttl
主从服务协调属性的定义以及否定答案的缓存时间TTL的解释：
serial：表示序列号，当主DNS服务器更新解析库文件时，需要把'serial'这个值增大，修改之后重载DNS服务就可以实现主从同步了。
refresh：表示从DNS服务器多久与主DNS服务器检查并同步一次，就是更新的意思。
retry：如果上面在从DNS服务器更新时连接主DNS服务器失败时，定义多久之后重新尝试连接一次。一般这个值应当小于上面'refresh'的值。
expire：如果在从DNS服务器重新尝试连接失败时，定义多久之后失效，并且从DNS服务器关闭DNS服务。这时需要系统管理员去查看故障并恢复服务。
negative answer ttl：表示否定答案在DNS客户端上的缓存时间。
NS记录：
Name：当前区域的区域名称。
value：当前区域的某DNS服务器的FQDN，例如：ns.itab.com.。需要注意的是，一个区域可以有多台DNS服务器，因此就可以有多个NS记录。
示例：
itab.com. 86400 IN NS ns1.itab.com. itab.com. 86400 IN NS ns2.itab.com.
MX记录：
Name：当前区域的区域名称。
value：当前区域的某邮件交换器的FQDN。需要注意的是，一个区域可以有多台邮件交换器，因此就可以有多个MX记录。而且，在每个MX记录的value之前都应该有一个数字表示其优先级。
示例：
itab.com. 86400 IN MX 10 mx1.itab.com. itab.com. 86400 IN MX 20 mx2.itab.com.
为什么要为每个MX记录设置优先级呢？这是因为如果在一个区域内有多台邮件交换器，那么当别人发送邮件过来时应该由谁接收才好？所以，优先级的好处就在这里，优先级越高的邮件交换器负责接收即可，这里而其他邮件交换器则起到冗余作用。在MX记录中，邮件交换器的优先级范围是0-99，且数字越小优先级越高。
A记录：
Name：某FQDN.
value：某IPv4地址。
示例：
www.itab.com. 86400 IN A 192.168.10.140 bbs.itab.com. 86400 IN A 192.168.10.150
AAAA记录：
Name：某FQDN.
value：某IPv6地址。
示例：
www.google.com. 3147 IN AAAA 200:2:4e10:310f::
PTR记录：
Name：某IP地址，但写法遵循特定格式（把IP反过来写、加特定后缀），例如1.2.3.4的记录应该写为4.3.2.1.in-addr.arpa.。
value：某FQDN.
示例：
140.10.168.192.in-addr.arpa. 86400 IN PTR www.itab.com.
以上各种资源记录类型的格式就是填写在区域解析库文件中的格式，另外需要注意的有以下四点：
(1)记录的缓存时间TTL可全局继承，也就是在区域解析库文件开头全局声明TTL值，而在之后每条记录都无需再写明TTL值。
(2)当前区域的区域名称可用@符号表示。
(3)相邻两条记录的Name相同时，后一条记录的Name可省略。
(4)对于正向解析区域来说，各MX，NS等类型的记录的value为FQDN，此FQDN应该有对应的一个A记录。
三、DNS解析答案
当DNS客户端向DNS服务器发出解析请求时，不管是否能够查询到想要的结果，都会返回一个解析答案。根据是否能够查询到想要的结果，可分为肯定答案和否定答案；根据解析答案是否由直接负责的DNS服务器返回，可分为权威答案和非权威答案。
根据是否能够查询到想要的结果：
①肯定答案：存在查询的键(key)，并且存在与其查询键对应的值(value)。
②否定答案：不存在查询的键(key)，因此，自然不存在与其查询键(value)对应的值。
根据解析答案是否由直接负责的DNS服务器返回：
①权威答案：由直接负责的DNS服务器返回的答案。
②非权威答案：不是由直接负责的DNS服务器返回的答案。这种情况下一般是由其他DNS服务器直接返回缓存的解析结果。
四、DNS协议的一种开源实现--bind
4.1 bind的相关概念
我们说DNS是一种协议，而对于每一种协议的实现都需要程序员开发出遵循这种协议规范的软件程序来实现，这里要介绍的BIND就是DNS协议的一种开源实现。据统计，使用bind作为DNS服务器软件的DNS服务器大约占所有DNS服务器的九成。BIND全称为Berkeley Internet Name Domain，因为当今互联网上的通信几乎都必须借助于DNS服务器来解析主机名，得到通信对方的IP地址，而在DNS服务器上最常用的软件就是bind，所以，bind这款软件几乎可以说是当今互联网上常用的软件了。
目前bind由ISC.org（Internet Systems Consortium，互联网系统协会）负责开发与维护。
学习bind这款软件之前，务必掌握以下基本概念：
dns：协议 bind：dns协议的一种开源实现 named：bind程序运行起来后的进程名
4.2 bind相关的程序包
bind不仅提供了主包，还提供了各种bind的支包，它们用于实现不同的功能。而在众多bind支包中，最常用到的有：bind-utils, bind-libs, bind-chroot等。
bind相关的程序包如下：
bind：提供dns server程序，以及几个常用的测试工具。 bind-utils：bind客户端程序集，例如提供dig, nslookup, dig等工具。 bind-libs：提供bind和bind-utils包中的程序共同用到的库文件。 bind-chroot：选装，让bind程序(named进程)运行于jail进程之下。
4.3 bind的相关配置文件
主配置文件：
/etc/named.conf
以及包含进来的其它配置文件：
/etc/named.iscdlv.key /etc/named.rfc1912.zones /etc/named.root.key
解析库文件：
存放于/var/named/目录下，一般名字为ZONE_NAME.zone
要点：
(1)一台DNS服务器可同时为多个区域提供解析。
(2)DNS服务器必须要有根区域解析库文件：named.ca.
(3)DNS服务器还应该有两个区域解析库文件：localhost和127.0.0.1的正反向解析库，这两个文件分别如下：
①正向解析库文件：/var/named/named.localhost
②反向解析库文件：/var/named/named.loopback
查看named.localhost文件：
[root@www ~]# cat /var/named/named.localhost $TTL 1D @ IN SOA @ rname.invalid. ( 0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum NS @ A 127.0.0.1 //关键就是这一条记录。 AAAA ::1
查看named.loopback文件：
[root@www ~]# cat /var/named/named.loopback $TTL 1D @ IN SOA @ rname.invalid. ( 0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum NS @ A 127.0.0.1 AAAA ::1 PTR localhost. //关键就是这一条记录。
4.4 利用rndc命令管理DNS服务器
我们知道，DNS服务默认的监听端口是53，当我们在主机上启动DNS服务之后，用netstat查看监听端口，显示如下：
[root@www ~]# netstat -tunlp | grep named tcp 0 0 192.168.10.140:53 0.0.0.0:* LISTEN 20563/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 20563/named tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 20563/named tcp6 0 0 ::1:53 :::* LISTEN 20563/named tcp6 0 0 ::1:953 :::* LISTEN 20563/named udp 0 0 192.168.10.140:53 0.0.0.0:* 20563/named udp 0 0 192.168.122.1:53 0.0.0.0:* 20563/named udp 0 0 127.0.0.1:53 0.0.0.0:* 20563/named udp6 0 0 ::1:53 :::* 20563/named
上面结果显示，除了能够看到53号端口之外，还能看到953端口，那是namd在953端口多启动了一个服务，这就是rndc了。
这个rndc的全称是Remote Name Domain Controller，它可以帮助用户更方便地管理DNS服务器，包括可以检查DNS服务器的状态与统计信息、重载配置文件及zone或单独重载某个区域而不需要重新启动整个DNS服务，还有查看已存在DNS缓存当中的资料等。
rndc服务默认监听在tcp的953端口，且默认监听于127.0.0.1地址，因此默认仅允许本地使用。
rndc的常见用法：
rndc reload：在不重新启动DNS服务的情况下，重新加载配置文件及zone.
rndc reload zone：重新加载指定的zone.
rndc status：查看当前DNS服务器的状态。
rndc stats：将当前系统的DNS统计数据记录下来，默认会将数据存储为一个文件：/var/named/data/named_stats.txt.
rndc dumpdb：将当前DNS高速缓存中的数据记录下来，与stats类似，默认会将数据存储为一个文件：/var/named/data/cache_dump.db.、
rndc flush：清空当前DNS服务器上的所有缓存。
在命令行直接输入rndc可查询其用法：
Usage: rndc [-b address] [-c config] [-s server] [-p port] [-k key-file ] [-y key] [-V] command command is one of the following: reload Reload configuration file and zones. reload zone [class [view]] Reload a single zone. refresh zone [class [view]] Schedule immediate maintenance for a zone. retransfer zone [class [view]] Retransfer a single zone without checking serial number. freeze Suspend updates to all dynamic zones. freeze zone [class [view]] # 其它的信息省略。
使用本地搭建的DNS服务器（事先搭好）查询www.baidu.com对应的IP地址：
[root@www ~]# dig -t A www.baidu.com @127.0.0.1 ; <<>> DiG 9.9.4-RedHat-9.9.4-37.el7 <<>> -t A www.baidu.com @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45330 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.baidu.com. IN A ;; ANSWER SECTION: www.baidu.com. 485 IN CNAME www.a.shifen.com. www.a.shifen.com. 300 IN A 163.177.151.109 www.a.shifen.com. 300 IN A 163.177.151.110 ;; AUTHORITY SECTION: a.shifen.com. 494 IN NS ns5.a.shifen.com. a.shifen.com. 494 IN NS ns4.a.shifen.com. a.shifen.com. 494 IN NS ns3.a.shifen.com. a.shifen.com. 494 IN NS ns2.a.shifen.com. a.shifen.com. 494 IN NS ns1.a.shifen.com. ;; ADDITIONAL SECTION: ns5.a.shifen.com. 494 IN A 119.75.222.17 ns4.a.shifen.com. 494 IN A 115.239.210.176 ns3.a.shifen.com. 494 IN A 61.135.162.215 ns1.a.shifen.com. 494 IN A 61.135.165.224 ns2.a.shifen.com. 494 IN A 180.149.133.241 ;; Query time: 37 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: 四 3月 30 19:39:57 CST 2017 ;; MSG SIZE rcvd: 271
将当前DNS高速缓存中的数据记录下来：
[root@www ~]# rndc dumpdb [root@www ~]# cat /var/named/data/cache_dump.db ; ; Start view _default ; ; ; Cache dump of view '_default' (cache _default) ; $DATE 20170330114125 ; authanswer . 517594 IN NS l.root-servers.net. 517594 IN NS h.root-servers.net. 517594 IN NS a.root-servers.net. 517594 IN NS e.root-servers.net. 517594 IN NS g.root-servers.net. 517594 IN NS j.root-servers.net. 517594 IN NS i.root-servers.net. # 中间的信息省略。 baidu.com. 171997 NS dns.baidu.com. 171997 NS ns2.baidu.com. 171997 NS ns3.baidu.com. 171997 NS ns4.baidu.com. 171997 NS ns7.baidu.com. ; glue dns.baidu.com. 171997 A 202.108.22.220 ; glue ns2.baidu.com. 171997 A 61.135.165.235 ; glue ns3.baidu.com. 171997 A 220.181.37.10 ; glue ns4.baidu.com. 171997 A 220.181.38.10 ; glue ns7.baidu.com. 171997 A 119.75.219.82 ; authanswer www.baidu.com. 397 CNAME www.a.shifen.com. ; glue shifen.com. 172006 NS dns.baidu.com. 172006 NS ns2.baidu.com. 172006 NS ns3.baidu.com. 172006 NS ns4.baidu.com. ; authauthority a.shifen.com. 406 NS ns5.a.shifen.com. 406 NS ns4.a.shifen.com. 406 NS ns3.a.shifen.com. 406 NS ns1.a.shifen.com. 406 NS ns2.a.shifen.com. ; glue ns1.a.shifen.com. 406 A 61.135.165.224 ; glue ns2.a.shifen.com. 406 A 180.149.133.241 ; glue ns3.a.shifen.com. 406 A 61.135.162.215 ; glue ns4.a.shifen.com. 406 A 115.239.210.176 ; glue ns5.a.shifen.com. 406 A 119.75.222.17 ; authanswer www.a.shifen.com. 212 A 163.177.151.110 212 A 163.177.151.109 ; glue a.gtld-servers.net. 171994 A 192.5.6.30 ; glue 171994 AAAA 2001:503:a83e::2:30 # 其它的信息这里省略。
在这个缓存文件中可以看到刚才解析www.baidu.com时的查询结果（A记录）以及查询过程中询问的DNS服务器信息（NS记录和A记录）
清空当前DNS服务器上的所有缓存：
[root@www ~]# rndc flush //虽然清空了高速缓存，但原来保存在文件中的缓存数据还在。 [root@www ~]# rndc dumpdb //再次把当前缓存保存在文件cache_dump.db中。 [root@www ~]# cat /var/named/data/cache_dump.db ; ; Start view _default ; ; ; Cache dump of view '_default' (cache _default) ; $DATE 20170330123214 ; ; Address database dump ; ; ; Unassociated entries ; ; ; Bad cache ; ; ; Start view _bind ; ; ; Cache dump of view '_bind' (cache _bind) ; $DATE 20170330123214 ; ; Address database dump ; ; ; Unassociated entries ; ; ; Bad cache ; ; Dump complete
因为缓存已被清空，所以再次保存时会覆盖掉原来在cache_dump.db文件中的内容，因此再次打开之后就看不到原来的数据了。
五、bind主配置文件格式
bind可以直接使用yum进行安装，安装完成之后，默认即可作为本地的缓存DNS服务器使用。如果没有专门负责要解析的区域，可以直接启动服务，启动操作如下：
CentOS 6： # service start named 或： # /etc/init.d/named start CentOS 7： # systemctl start named.service
如果想作为其他人使用的缓存DNS服务器，则需要再修改配置文件。在修改之前，我们先了解一下bind的配置文件的内容。
bind主配置文件/etc/named.conf的格式：
全局配置段：
options { ... };
日志配置段：
logging { ... };
区域配置段：
zone { ... };
全局配置段：
至于options内的比较重要的子参数简单叙述如下：
listen-on port 53 { any; };
监听在当前主机上的哪个网络接口。默认是监听在localhost，也就是只有本机才能够查询，这显然是不符合现实需要的，因此可以改为any，表示可以监听多个网络接口，any之后要加上分号才算结束。只要监听在能够与外网主机进行通信的网络接口上，就可以为外网主机提供解析服务，当前前提是别人知道自己主机的IP地址。这里也可以监听在指定的网络接口上，可以监听多个接口，每个地址后面都需要加上分号。
directory "/var/named";
这里的意思是如果在/etc/named.conf（包括被包含进来的配置文件）中定义了正反解区域解析库文件的文件名时，该文件名默认应该存放于哪个目录下，默认是存放在/var/named/目录下。需要注意的是，如果安装了bind-chroot程序包，则这些区域解析库文件最终会被主动链接到/var/named/chroot/var/named/这个目录。
dump-file、statistics-file、memstatistics-file
与named这个服务有关的许多统计信息，如果想要输出为文件的话，默认的文件名就由这三项指定。
allow-query { any; };
这是针对DNS客户端的设置，表示谁可以向我的DNS服务提出查询请求的意思。默认设置为localhost，表示仅允许本地查询，这里修改为any，表示对所有的用户开放（当然，防火墙必须放行才行）。
allow-transfer { none; };
当架设主-从DNS服务器时，允许哪台从DNS服务器向我的这台DNS服务器转发区域解析库文件的数据。
recursion yes;
是否允许为DNS客户端做递归查询。默认为yes.
关于forward的相关配置子参数会在后面的定义转发部分进行介绍。
日志配置段：
区域配置段：
区域配置段在下一篇博文中介绍。
缓存DNS服务器配置步骤：
(1)开放监听端口，使DNS服务监听在能与外部主机进行通信的地址。
修改全局配置段：
listen-on port 53 { any; }; //表示监听在任何地址上，也可以指定监听在某个或某些地址上。
(2)设置允许其他主机查询，默认是仅本地主机查询。
修改全局配置段：
allow-query { any; }; //表示允许任何主机查询，也可以指定仅允许某个或某些主机查询。
(3)关闭dnssec。
修改全局配置段： dnssec-enable no; dnssec-validation no; dnssec-lookaside no;
(4)检查配置文件错误。
[root@www ~]# named-checkconf //检查主配置文件（包括主配置文件包含进来的其他配置文件） [root@www ~]# //没有任何信息显示，说明没有语法错误，可以重启服务了。
(5)重启DNS服务。
如果DNS服务还没启动，直接按照前面所说方式启动即可。如果已经启动了，则可用rndc重载DNS服务器，如下：
[root@www ~]# rndc reload server reload successful //重载成功。
这样一个缓存DNS服务器就配置好了。
分析：什么时候有搭建缓存DNS服务器的需求？
在某些公司有可能会用到，例如公司内不允许员工利用公司的网络资源做自己的事情，所以被限制的防火墙主机上针对Internet的连接会作比较大的限制。而如果又希望这台主机能够提供DNS服务，可以在那台防火墙主机上，配置一个缓存DNS服务，并在防火墙主机上设置放行DNS功能。这样这台防火墙主机就可以帮助Client端解析hostname <--> IP了，而Client端直接设置该防火墙主机的IP为DNS服务器的IP即可。
以用户访问www.baidu.com为例，当使用缓存DNS服务器进行查询时，示意图如下：
六、定义转发(forwarding)功能
上面已经配置好了一个缓存DNS服务器，但缓存DNS服务器没有专门负责解析哪一个或哪些区域，在接收到用户的查询请求时，首先查看本地是否有缓存，如果没有缓存则从根区域开始迭代查询。那有没有办法不向根区域服务器查询，而直接把查询请求发给其他指定的DNS服务器，然后让这个指定的DNS服务器帮我们查询并返回查询结果，接着本地主机再将查询结果返回给用户呢？这就需要用到forwarding功能了。但需要注意的是，被指定转发的服务器必须允许为当前服务器做递归查询。
转发功能分为区域转发和全局转发两种。
区域转发：
功能：仅转发对某特定区域的解析请求。
配置方式：配置区域段(zone)，如下：
zone "ZONE_NAME" IN {
type forward;
forward {first|only};
forwarders {SERVER_IP};
};
# first：首先转发。当转发器不回应时，自行去迭代查询。
# only：只转发给指定的转发器。
注意：forwarders后面的's'不能漏掉。
全局转发：
功能：针对凡本地没有通过zone定义的区域查询请求，通通转发给某转发器。在这种情况下连根域的解析库文件都不需要了。
配置方式：配置全局段(options)，如下：
options {
... ...
forward {first|only};
forwarders {SERVER_IP};
... ...
};
以用户访问www.baidu.com为例，当全局转发时，配置有forwarding的DNS服务器的查询方式示意图如下：
区域转发则仅转发特定区域的解析请求，如果用户请求解析这些特定区域时，整个查询方式和全局转发时一样；如果用户请求解析的不是这些特定区域时，则转发过程几乎和前面使用缓存DNS服务器进行查询相同。
总的来说，具有forwarding功能的DNS服务器就是把原本自己要去从根开始迭代查询的这个任务交给了其他DNS服务器去处理。
这里在原来配置好的缓存DNS服务器上定义转发：
[root@www ~]# vim /etc/named.conf
在全局配置段进行配置。
options {
listen-on port 53 { any; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { any; };
allow-transfer { none; };
recursion yes;
forward only; //定义只转发。
forwarders { 223.5.5.5; 226.6.6.6; };
//这两个地址是阿里云提供的公共DNS服务器，先用223.5.5.5，再用223.6.6.6.
};
为了方便测试，排除是本地DNS服务器自己从根域开始迭代查询的可能性，因此这里注释掉根域的相关配置，使其失效：
#zone "." IN {
# type hint;
# file "named.ca";
#};
配置好之后重载named服务：
[root@www ~]# rndc reload server reload successful
将配置/etc/resolv.conf中配置的DNS服务器指向注释掉，排除是该配置文件中指向的DNS服务器查询的可能性：
[root@www ~]# vim /etc/resolv.conf # Generated by NetworkManager #nameserver 114.114.114.114
测试：
[root@www ~]# dig -t A www.redhat.com @127.0.0.1 ; <<>> DiG 9.9.4-RedHat-9.9.4-37.el7 <<>> -t A www.redhat.com @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12858 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 13, ADDITIONAL: 27 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.redhat.com. IN A ;; ANSWER SECTION: www.redhat.com. 30 IN CNAME ds-www.redhat.com.edgekey.net. ds-www.redhat.com.edgekey.net. 30 IN CNAME ds-www.redhat.com.edgekey.net.globalredir.akadns.net. ds-www.redhat.com.edgekey.net.globalredir.akadns.net. 30 IN CNAME e3396.ca2.s.tl88.net. e3396.ca2.s.tl88.net. 30 IN A 119.145.144.215 ;; AUTHORITY SECTION: . 514752 IN NS l.root-servers.net. . 514752 IN NS b.root-servers.net. . 514752 IN NS h.root-servers.net. . 514752 IN NS i.root-servers.net. . 514752 IN NS m.root-servers.net. . 514752 IN NS k.root-servers.net. . 514752 IN NS c.root-servers.net. . 514752 IN NS e.root-servers.net. . 514752 IN NS f.root-servers.net. . 514752 IN NS d.root-servers.net. . 514752 IN NS g.root-servers.net. . 514752 IN NS a.root-servers.net. . 514752 IN NS j.root-servers.net. ;; ADDITIONAL SECTION: a.root-servers.net. 514752 IN A 198.41.0.4 a.root-servers.net. 514752 IN AAAA 2001:503:ba3e::2:30 b.root-servers.net. 514752 IN A 192.228.79.201 b.root-servers.net. 514752 IN AAAA 2001:500:84::b c.root-servers.net. 514752 IN A 192.33.4.12 c.root-servers.net. 514752 IN AAAA 2001:500:2::c d.root-servers.net. 514752 IN A 199.7.91.13 d.root-servers.net. 514752 IN AAAA 2001:500:2d::d e.root-servers.net. 514752 IN A 192.203.230.10 e.root-servers.net. 514752 IN AAAA 2001:500:a8::e f.root-servers.net. 514752 IN A 192.5.5.241 f.root-servers.net. 514752 IN AAAA 2001:500:2f::f g.root-servers.net. 514752 IN A 192.112.36.4 g.root-servers.net. 514752 IN AAAA 2001:500:12::d0d h.root-servers.net. 514752 IN A 198.97.190.53 h.root-servers.net. 514752 IN AAAA 2001:500:1::53 i.root-servers.net. 514752 IN A 192.36.148.17 i.root-servers.net. 514752 IN AAAA 2001:7fe::53 j.root-servers.net. 514752 IN A 192.58.128.30 j.root-servers.net. 514752 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 514752 IN A 193.0.14.129 k.root-servers.net. 514752 IN AAAA 2001:7fd::1 l.root-servers.net. 514752 IN A 199.7.83.42 l.root-servers.net. 514752 IN AAAA 2001:500:9f::42 m.root-servers.net. 514752 IN A 202.12.27.33 m.root-servers.net. 514752 IN AAAA 2001:dc3::35 ;; Query time: 786 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: 四 3月 30 22:13:39 CST 2017 ;; MSG SIZE rcvd: 976
测试结果说明：
我这里主机上并没有配置关于redhat.com这个区域的解析库文件，而且没有从根域开始迭代查询，同时在/etc/resolv.conf中没有配置任何DNS指向，所以，只存在一种可能，那就是这个查询结果是由223.5.5.5这个转发器帮忙查询从根域开始查询后返回的。
这是定义全局转发的实验，而如果是定义区域转发，则有可能还需要有根域的相关配置。测试到此结束。
forwarders的好处和问题分析
关于forwarders的使用是好是坏，有两种意见：
①利用forwarders可以提高查询效率。
这种观点认为，因为当很多DNS服务器都使用forwarders时，那个被设置为forwarders的DNS转发器，会因为积累了大量的缓存，因此查询效率会大大提高。
②利用forwarders反而会降低整体查询效率。
这种观点则认为，当被设置为forwarders的DNS转发器业务繁忙时，如果有其他的DNS服务器还向它要查询数据，这时候反而会导致查询速度减慢，这种情况下双方都会受到影响。
总结一下，当DNS转发器业务不繁忙时，forwarders可以提高效率的，而当其业务繁忙时，可能会导致查询效率更低。
参考链接：
TWNIC，《Bind 简介》，http://dns-learning.twnic.net.tw/bind/intro1.html
转载于:https://blog.51cto.com/xuweitao/1912150
169
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
