上次博文我们具体配置了一台DNS服务器并实现了主辅之间的区域传送，本次博文我们来看看DNS的一些高级配置。
【本次博文的主要内容】
- 子域授权
- 转发域
- acl
- 视图（view）
【实验环境】
实验说明：
本次博文的实验只做正向解析；
VMware station 10
BIND服务器：两台CentOS 6.4虚拟机做主辅DNS
windows 7物理机做客户端
Domain Name：test.com. 192.168.80.0/24
主DNS：Master.test.com. 192.168.80.11
辅助DNS：Slave.test.com. 192.168.80.13
web主机：www.test.com. 192.168.80.11 192.168.1.201 192.168.80.14
ftp主机：ftp.test.com. CNAME www.test.com.
mx邮件服务器：mx.test.com. 192.168.80.11
######################################规划子域##################################################
子域：SubZone.test.com.
子域DNS：ns1.SubZone.test.com. 192.168.80.12
web主机：www.SubZone.test.com. 192.168.80.12
imap：CNAME www
一、子域授权：
【DNS服务器的主辅配置】
主DNS配置好后，test.com区域文件如下所示：
辅助DNS上的区域文件是从主DNS复制过去的，如下所示：
所有资源记录都有了哈。下面我们来配置子域DNS，并在其父域DNS上完成授权。
【子域授权】
子域授权创建步骤：
第一步、划分子域：
这里，我们划分的子域为SubZone.test.com. 在192.168.80.12主机上，配置子域的区域解析文件：
（1）修改主配置文件，在/etc/named.rfc1912.zones文件中添加如下条目：
（2）创建“SubZone.test.com.zone”区域解析文件，并修改属组和权限：
（3）检查主配置文件和区域文件的语法错误（语法检查没问题了别急着启动服务或重新载入区域文件，需要先到父域DNS上完成授权）
第二步、完成授权：
（1）在主DNS（192.168.80.11主机）上完成子域的授权，即在区域文件/var/named/test.com.zone中添加子域相应的NS记录和粘附A记录：
（2）检查区域文件语法错误并重新加载主DNS的区域文件：
（3）回到子域DNS，启动named服务或重新加载区域文件；
至此，子域授权的过程结束。
【验证子域授权】：
1、回到父域DNS，查看区域解析情况：
授权是自上而下的哈，父域能知道子域的存在。
Tis：如果检查区域文件语法错误时出现了以下情况：
2、在父域的辅助DNS（192.168.80.13主机）上，查看区域解析情况：
3、回到子域DNS，查看区域解析情况：
能够解析，而且是权威应答哈。思考一下，子域DNS能够解析父域吗？我你们来试一下哈！
结论：授权是自上而下的，上级（父域）知道下级（子域）的存在，而下级（子域）并不知道上级（父域）的存在（因此子域的解析从根开始层层往下迭代）
那如何才能让子域解析父域呢？通过转发！
二、DNS名称解析转发器：
1、问题的引入：什么是转发器？为什么需要转发器？
担当DNS名称解析的服务器被称为“DNS转发器”。转发器也是网络上的DNS服务器，用来将内部DNS名称的DNS查询转发给该网络外的DNS服务器。
如果不将特定DNS服务器指定为转发器，所有DNS服务器可使用其根提示在网络外发送查询。这样，许多内部可能非常重要的DNS信息都可暴露在公网上。除了安全和隐私问题，该解析方法可导致大量的外部通信，且通信费用昂贵，对于慢速Internet连接的网络或Internet服务成本很高的公司来说效率低下。而将DNS服务器指定为转发器时，转发器将负责处理外部通信，从而将DNS服务器有限地暴露给公网。转发器将建立外部DNS信息的巨大缓存，因为网络中的所有外部DNS查询都是通过它解析的。你在很短的时间内，转发器将使用该缓存数据解析大部分外部DNS查询，从而减少网络的Internet通信与DNS客户端的响应时间。
2、转发的原理：
转发是一种链式结构，如下图所示：
（1）当本地DNS服务器（也是转发器）收到查询时，它会尝试使用它主持和缓存的主要和辅助区域解析该查询；
（2）如果不能使用本地数据解析查询，此时它作为客户端，会将查询转发给外网DNS服务器；
（3）本地DNS（转发器）收到客户端的请求后会等待一段很短的时间，等待来自外网DNS的应答；
（4）对于外网DNS来说，它接收到的查询请求是递归查询，此时，它自己需要向外层层迭代找到最终答案返回给转发器（此时转发器作为DNS客户端）
（5）转发器将外网DNS返回的查询结果送到客户端（非权威答案），完成解析过程。
注：转发的前提——接收转发请求的服务器（这里是外网DNS）必须能够为请求者（这里是本地DNS，也是转发器）做递归查询；
3、转发的类型：
（1）无条件转发：转发所有针对非本机负责解析的区域的请求；
options { forwarders { ip; }; #指明转发器是谁 forward only|first; #only表示仅转发 ；first表示先进行转发，如果没查询到结果，那么它自己还会根据根提示向外迭代查询 };
（2）条件转发：仅转发对特定区域的请求（即转发域）；
【举例说明】
######################################规划转发器#################################################
上面的例子中，子域DNS（192.168.80.12主机）无法与外网通信，且无法解析父域；
辅助DNS服务器（192.168.80.13主机）能够与外网通信，现在将其作为子域DNS的转发器；
1、无条件转发：在子域DNS上设置转发，让子域能够解析父域且能够通过转发器解析公网的查询：
第一步、在子域DNS上配置转发。修改主配置文件/etc/named.conf，实现无条件转发即转发所有非本机负责解析的区域的请求：
第二步、重新加载配置文件，并清空DNS缓存：
第三步、用dig命令进行测试，看看通过转发子域是否能够解析父域：
第四步、用dig命令测试，看看通过转发能否解析外网的查询：
可以看出，通过无条件转发，可以解析针对非本地负责的区域的查询哈。
现在假设这样一个场景：
如果子域DNS能够与外网通信而转发器DNS服务器（192.168.80.13主机）不能与外网通信，并且子域DNS能够根据根提示做DNS查询，那么将转发选项设置为“first”，结果怎样呢？
（1）设置外网网关，让子域DNS服务器能够与外网通信：
（2）在转发器DNS服务器（192.168.80.13主机）上，设置网关，让其无法与外网通信：
（3）在子域DNS上修改主配置文件，把转发选项改为”first“：
（4）重新加载子域DNS的配置文件并清除DNS缓存：
（5）用dig命令测试，看是否还能够解析外网的区域：
能够解析哈，说明不能从转发器查询外网之后，它自己用根提示出去迭代查询到了结果。
2、条件转发：配置转发域，使得只对test.com域的查询能够通过转发器解析：
第一步、修改主配置文件/etc/named.conf，将上例中的无条件转发选项注释掉：
第二步、修改/etc/named.rfc1912.zone，配置转发域test.com：
第三步、在转发器DNS服务器上（192.168.80.13主机），设置“允许递归”：
第四步、在子域DNS上用dig命令进行测试，看是否可以解析转发域：
能够解析哈，那现在是否可以解析baidu.com呢？试试看哈。
不能解析哈。
三、DNS的ACL配置：
1、问题的引入：为什么需要ACL？
因为安全和DNS服务器性能，如果没有ACL，那么任何人都可以到我们的DNS服务器上做递归查询，这样是非常危险的。而且DNS的区域传送是多主复制，如果不设置ACL，那么任何主机都可以到我们的DNS上来做完全区域传送，这也是很危险的，而且会让我们的DNS服务器忙死。
2、BIND的ACL：
（1）BIND中常用4个常用的控制指令：
以上4段可以放到全局配置中对全局配置生效，也可放在某个区域中，只针对于某个区域生效；而allow-recursion参数要加入到全局配置中，其他两项一般是放到区域配置中。
（2）BIND的ACL：
如果allow-transfer 和 allow-query 放到区域配置中一般后期修改ip地址会非常的麻烦，所以可以定义acl访问规则：
#对于配置文件的格式以及参数调整，具体可以查看man手册 ，命令：man named.conf
定义acl的格式如下：
可以看到如上所示信息，定义格式非常简单：使用bind访问控制列表，明确定义一组客户端或者一组主机并使用一个名称来定义它们；
其中，定义的参数有四种，分别是：any、none、local、localnet。
acl只有先定义才可以使用，因此acl定义必须在acl调用的最上方即放在配置文件的最上方。
【配置ACL】
在子域DNS上配置ACL，只允许本机地址127.0.0.1查询：
（1）先定义acl：
（2）acl定义后需要应用在区域文件中（编辑区域配置文件/etc/named.rfc1912.zone）：
（3）重新载入配置文件；
（4）验证结果（在子域DNS服务器上用dig命令测试）：
首先用本机的IP地址192.168.80.12来解析：
拒绝查询哈！
然后用127.0.0.1来解析：
能够解析哈，说明ACL起作用了。
四、通过VIEW实现智能DNS：
1、BIND VIEW是什么：
BIND的view是基于人的脑裂（brain split）原理，灵活控制哪些客户机能看到哪个view视图的访问控制列表，view功能可以实现不同网段发出同样的请求却得到不同的DNS解析结果，可以有效的分流网络流量，提高访问控制能力。
2、VIEW语句的介绍：
通过view语句可以完成DNS的智能解析功能，其语法如下：
3、配置VIEW，实现智能DNS解析：
######################################规划VIEW##################################################
实验拓扑还是采用子域授权的那一个，每个虚拟机上都配置了两块网卡（参见拓扑图），将来自192.168.80.0/24网段的IP作为内网的主机，192.168.1.0/24网段的IP和所有其它IP作为外网的主机，用win7物理机与虚拟机通信时，访问192.168.80.0/24网段采用的是NAT地址转换，会将物理机的IP地址192.168.1.3转换为192.168.80.254来访问。使用acl来定义控制列表。
【配置VIEW】
（1）在主DNS（192.168.80.11主机）上，编辑主配置文件/etc/named.conf，配置acl和view：
（2）使用named-checkconf来检测主配置文件是否有存在语法错误：
（3）分别创建内外网用户访问test.com域服务器所使用的正向解析区域文件：
内网（internal）的zone文件/var/named/internal.test.com.zone ：
外网（external）的zone文件/var/named/external.test.com.zone ：
（4）将internal和external所使用的解析区域数据文件的属组及权限分别改为named和640：
（5）使用named-checkzone分别检测internal和external所使用的区域数据文件是否存在语法错误；
（6）重新加载配置文件和区域文件，并打开查询日志：
（7）分别在192.168.80.0/24和192.168.1.0/24网段上进行测试，并查看结果：
说明：我的win7物理机的IP是192.168.1.3，DNS服务器上配置了两块网卡，IP地址分别为192.168.80.11和192.168.1.58
查询日志的情况如下：
访问的是内网视图，物理机的IP（192.168.1.3）被转换成了192.168.80.254；
查询日志情况如下：
由此，通过VIEW实现了智能DNS哈。
【小结】
本次博文主要知识点：
1、DNS的子域授权：
- 子域的概念：在域内划分出小域即为子域。
- 授权也称为委派，子域授权的步骤：
（1）划分子域
（2）完成授权
- 授权是自上而下的过程，父域知道子域的存在并知道子域的主DNS服务器地址（父域的名称解析库中有子域的NS记录和主机A记录），而子域并不知道父域的存在，因此子域需要从根域开始查找。
- 如果想让子域解析父域，最简单的办法就是设置转发。
2、DNS的转发：
转发的前提——接收转发请求的服务器必须能够为请求者做递归查询；
3、BIND的ACL：
（1）BIND中常用4个常用的控制指令：
（2）BIND的ACL定义：
其中，定义的参数有四种，分别是：any、none、local、localnet。
acl只有先定义才可以使用，因此acl定义必须在acl调用的最上方即放在配置文件的最上方。
4、通过视图（view）实现智能DNS：
通过view语句可以完成DNS的智能解析功能，其语法如下：
本次博文的内容就这么多哈,下次我们给出一个综合案例来总结下DNS的知识；欢迎各位大大拍砖~~
原文链接：https://blog.51cto.com/sweetpotato/1607383
