DNS的子域授权与智能解析

DNS子域授权 为什么需要子域授权？

子域授权，也就是DNS的分布式。

通过在原有的域上划出一个小的区域，并给新DNS服务器管理。
如果有客户端请求解析在这个划分区域中的域名，则只要找新的子DNS服务器。
这样的做的好处可以减轻主DNS的压力，也便于管理。

配置DNS子域授权 主机名主机地址角色
node1   192.168.2.201   主DNS服务器  
node2   192.168.2.202   从DNS服务器  
node3   192.168.2.203   子域授权服务器  

以上节点均关闭了iptables和selinux

由于篇幅的原因，这次主要是演示子域授权的部分。
关于node1和node2配置主从同步的详细步骤以及注意事项，可以参考上一篇文章。

一、修改node1的资源记录 [root@node1 named]# vim /var/named/bc.com.zone ops IN NS ns3 ns3 IN A 192.168.2.203

在bc.com这个资源记录文件中添加两条记录。
其实这个的意思是说，
ops.bc.com这个域由ns3.bc.com来解析。
ns3.bc.com的IP地址在192.168.2.203

注意：这里需要将SOA记录的序列号手动+1才会触发node2的同步。

二、为node3配置安装dns服务，并配置资源记录 安装服务 [root@node3 ~]# yum install bind -y 修改全局配置 [root@node3 ~]# vim /etc/named.conf options { listen-on port 53 { 192.168.2.203;127.0.0.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; }; dnssec-enable no; dnssec-validation no; } 定义可解析区域 [root@node3 ~]# vim /etc/named.rfc1912.zones zone "ops.bc.com" IN { type master; file "ops.bc.com.zone"; }; 编辑资源记录 $ORIGIN ops.bc.com. $TTL 86400 @ IN SOA ops.bc.com. admin.bc.com. ( 2016042301 1H 5M 7D 1D) ops.bc.com. IN NS ns1 ns1 IN A 192.168.2.203 www IN A 192.168.2.213 * IN A 192.168.2.223 注意： 除了SOA记录之外，这里定义了几条资源记录 ops.bc.com. IN NS ns1 表示ops.bc.com这个域由ns1.ops.bc.com这个DNS服务器负责解析 ns1 IN A 192.168.2.203 表示ns1.ops.bc.com的IP地址是192.168.2.203 www IN A 192.168.2.213 表示的IP地址是192.168.2.213 * IN A 192.168.2.223 表示*.ops.bc.com的IP地址是192.168.2.223 检查语法错误 [root@node3 ~]# named-checkzone ops.bc.com /var/named/ops.bc.com.zone zone ops.bc.com/IN: loaded serial 2016042301 OK

没有问题则可以重启服务，因为dns服务经常配置文件缺少标点而启动不成功。
所以检查语法错误之后才重启，可以避免故障导致服务不可用。

重启服务 [root@node3 ~]# service named restart Redirecting to /bin/systemctl restart named.service 三、测试能否在node1上解析子域的资源记录 [root@node2 ~]# dig -t A ftp.ops.bc.com @192.168.2.201 ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> -t A ftp.ops.bc.com @192.168.2.201 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28811 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ftp.ops.bc.com. IN A ;; ANSWER SECTION: ftp.ops.bc.com. 86400 IN A 192.168.2.223 ;; AUTHORITY SECTION: ops.bc.com. 86400 IN NS ns1.ops.bc.com. ;; ADDITIONAL SECTION: ns1.ops.bc.com. 86400 IN A 192.168.2.203 ;; Query time: 3 msec ;; SERVER: 192.168.2.201#53(192.168.2.201) ;; WHEN: Fri Dec 30 18:02:12 CST 2016 ;; MSG SIZE rcvd: 93

;; ANSWER SECTION:字段中，解析到我们配置的*.ops.bc.com
所以ftp.ops.bc.com的IP地址是192.168.2.223。

后续问题： [root@node3 ~]# nslookup > server 192.168.2.203 Default server: 192.168.2.203 Address: 192.168.2.203#53 > set q=A > Server: 192.168.2.203 Address: 192.168.2.203#53 ** server can't find : NXDOMAIN

我们发现，由于子域的node3中的资源记录只有那么几条。
所以当有客户端请求其他资源记录的时候，就会无法解析。
转而会向根服务器开始迭代，这样会很慢。
所以一般会定义一个转发器，在子域无法解析的时候
转发给特定服务器解析。

配置转发器： [root@node3 ~]# vim /etc/named.conf options { forward only; forwarders { 192.168.2.1; }; }

这里无法解析的请求，都转发给192.168.2.1。
为什么不转发给主DNS服务器？
因为我们在主DNS中定义的资源记录也是有限的，所以主DNS也可能解析不出来。

加了转发器选项之后就可以正常解析了。 [root@node3 ~]# nslookup > server 192.168.2.203 Default server: 192.168.2.203 Address: 192.168.2.203#53 > set q=A > Server: 192.168.2.203 Address: 192.168.2.203#53 Non-authoritative answer: Name: Address: 106.75.2.241 >

有了转发器，就可以把自己负责的区域以外的请求都丢给其他DNS服务器代为处理。

智能DNS