前言：在实际生产环境中由于需求和环境不同，所需DNS实现功能也不同，本节介绍DNS实现主从、子域的配置、DNS转发和
智能DNS功能，另外补充了点儿与排错相关的内容。
1.搭建DNS主从服务器
搭建DNS主从服务器的目的就是为了实现容错。
yum -y install bind
iptables -F 关闭防火墙
setenforce 0 关闭selinux
systemctl enable named
service named restart
ss -ntl 查看53端口打开
一切OK后
vim /etc/named.conf
vim /etc/named.rfc1912.zones
named-checkconf
rndc reload
重新加载zone，将自动从主DNS那边加载数据zone
cat /var/named/slaves/heiye.com.slave.zone
对于从DNS服务器，centos7.X上为加密的，而centos6.x则为明文。
在另一台主机上测试：
到此主从DNS搭建完成！
在这种情况下，一旦主DNS发生故障，将自动利用DNS从服务器进行解析，实现了某种程度上的容错。
2. DNS子域的实现
子域授权：分布式数据库
正向解析区域子域方法：如果主机不多，则直接加子域的A记录即可，如果主机较多，则可单建一个独立子域。
vim /etc/named.rfc1912.zones
vim /var/named/wuhan.heiye.com.zone
$TTL 86400 ; 1 day @ IN SOA dns1 465925664.heiye.com. ( 2017102002 ; serial 86400 ; refresh (1 day) 3600 ; retry (1 hour) 604800 ; expire (1 week) 10800 ; minimum (3 hours) ) NS dns1 dns1 A 172.18.251.219 websev A 172.18.250.111 www CNAME websev
用dig测试：
当然也可以把父域和子域分离在两台主机上，此时需在父域主机的zone里上定义wuhan NS dnsN
dns10 A IP
之后在子域的主机上直接像定义父域那样定义zone就OK了，这样就实现的父子域分离，原理就像根域往下指派子域一样。
3.DNS转发功能的实现
当用户查询DNS服务器，当DNS数据库有相应的记录时则会回应用户，如果没有，则DNS会直接区询问根域，然后根域会一级一级的询问相应的子域
直到帮用户查询到相应记录，当然，当DNS没有对应记录时我们也可以让他把询问请求转发到我们指定的服务器上去查询。这就是DNS转发功能的实现
DNS转发功能的实现主要是方便优先共享DNS数据库资源，节省查询时间，而不必每次一级一级的递归去询问根，这样节省带宽流量的时间。
注意：被转发的服务器需要能够为请求者做递归，否则转发请求不予进行
(1) 全局转发: 对非本机所负责解析区域的请求，全转发给指定的服务器
Options {
forward first | only;
forwarders { ip;};
};
即 vim /etc/named.conf
加两行
first意思是如果请求不能得到响应，则DNS会向根一级级询问，而only如果不能响应就会报无法解析。
(2) 特定区域转发：仅转发对特定的区域的请求，比全局转发优先级高
vim /etc/named.rfc1912.zones
加个zone
zone "ZONE_NAME" IN {
type forward;
forward first|only;
forwarders { ip;};
};
注意：关闭dnssec功能： dnssec-enable no; dnssec-validation no;
如果局域网网关防火墙设置了禁ping，那么无法通过dig向根递归查询，只能依靠内网指定的DNS作解析，同样114.114.114.114也用不了（坑！）
4.构造DNS根域的Internet的实现
每个DNS都知道根的地址，在文件/var/named/named.ca中
而named.ca文件则是由/etc/named.conf指定
因此只要把根主机中的/etc/named.conf中文件路径改了或者把named.ca中根地址改了，再覆盖到所有子域服务器根相应文件路径即可实现修改根地址。
而根主机上需指定自己为根！即在/etc/named.rfc1912.zones里定义zone时，ZONE_NAME为 “.” ,file 为“root.zone”,再把/etc/named.conf中关于
根文件路径那段删了，同时把根域下相应的如.com、.cn等的子域的A记录填上就OK了
5.智能DNS的实现
原理拓扑图如下：
bind view：
view:视图，一个bind服务器可定义多个view，每个view中可 定义一个或多个zone
每个view用来匹配一组客户端
多个view内可能需要对同一个区域进行解析，但使用不同的 区域解析库文件
格式： view VIEW_NAME {
match-clients { testacl; };
zone “heiye.com” {
type master;
file “heiye.com.zone”;
};
或include "/etc/named.rfc1912.zones"（二选一）
};
注意： (1) 一旦启用了view，所有的zone都只能定义在view中
(2) 仅在允许递归请求的客户端所在view中定义根区域
(3) 客户端请求到达时，是自上而下检查每个view所服务 的客户端列表
下面这个时/etc/named.conf的底部，要把根zone删除，然后把include "/etc/named.rfc1912.zones"删除，之后定义view
配置/var/named/heiye.com.zone.wh 和/var/named/heiye.com.zone.bj
rndc restart 重新加载zone或者重启服务
测试：
测试成功！
智能DNS设置起来比较麻烦，因为IP地址段太多也不能漏掉以致难以维护，解决方案有两个：
第一：加个otherview，把地址段设为any，即不在智能范围的走其中任一一个DNS服务器即可。
第二：CDN加速：相当与在zone的资源记录中加个别名，别名A记录指向CDN加速的厂商，让专业的CDN厂家帮你快速智能解析。
CDN: Content Delivery Network -------服务商：蓝汛，网宿，帝联等
智能DNS: dnspod 、dns.la
6.编译安装DNS
二进制安装就是已经编译好了的程序，你只要下载解包(安装)它们以后 就马上可以使用
编译安装则是源代码包里面包括了程序原始的程序代码 你需要编译以后才可以运行源码安装与二进制发行版本相比，如果我们选择了通过源代码
进行编译安装，那么在安装过程中我们能够对该软件
所做的调整将会更多更灵活一些。因为通过源代码编译我们可以：
a) 针对自己的硬件平台选用合适的编译器来优化编译后的二进制代码；
b) 根据不同的软件平台环境调整相关的编译参数；
c) 针对我们特定应用场景选择需要什么组件不需要什么组件；
d) 根据我们的所需要存储的数据内容选择只安装我们需要的字符集；
e) 同一台主机上面可以安装多个该软件服务；
f) 等等其他一些可以根据特定应用场景所作的各种调整。
在源码安装给我们带来更大灵活性的同时，同样也给我们带来了可能引入的隐患：
a) 对编译参数的不够了解造成编译参数使用不当可能使编译出来的二进制代码不够稳定；
b) 对自己的应用环境把握失误而使用的优化参数可能反而使系统性能更差；
c) 还有一个并不能称之为隐患的小问题就是源码编译安装将使安装部署过程更为复杂，所花费的
时间更长；
过程：源码->二进制文件->rpm->安装
二进制格式的包名字很长，都带有版本号、适应平台、适应的硬件类型等，而源码格式仅仅就是一个版本号的tar包。
实际的生产环境绝大多数还是源码编译安装，经多次测试，基于源码编译安装的软件服务性能要明显高于rpm或二进制安装！
在一个没有装bind的系统上下载bind本次编译使用bind-9.11.0-P1.tar
tar xvf bind-9.11.0-P1.tar.gz 解压缩
yum -y groupinstall "development tools"装开发包组
useradd -r -m -d /var/named -s /sbin/nologin named
cd bind-9.11.0-P1/
./configure --prefix=/app/bind9 --sysconfdir=/etc/bind9 --without-openssl
make -j 4&& make install
dig -t ns . @172.18.0.1 >/var/named/named.ca
vim /etc/profile.d/env.sh
. /etc/profile.d/env.sh
vim /etc/bind9/named.conf
vim /var/named/test.com.zone
$TTL 1d
@ IN SOA dns1. admin (
2016061801
1h
5m
7d
1d
)
IN NS dns1.
dns1. IN A 172.18.250.128
www IN A 6.6.6.6
vim /etc/man_db.conf
. /etc/man_db.conf
named-checkconf
named-checkzone "test.com" /var/named/test.com.zone
named -u named -f -g -d 3
到此，DNS编译的初步环境已经搭建完毕，如果没有问题的话，可以在不同主机上简单测试一下
后续完善：配置rndc
cd /app/bind9/sbin/
rndc-confgen -r /dev/urandom >/etc/bind9/rndc.conf
vim /etc/bind9/rndc.conf
cp 其中下面的服务器的那段，然后把那段发送到相应的named.conf 后面
options{ directory "/var/named/"; }; zone "." { type hint; file "named.ca"; }; zone "test.com" { type master; file "test.com.zone"; }; key "rndc-key" { algorithm hmac-md5; secret "ZlhJrIU3tJd7JaPgtSTWpw=="; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; };
rndc是个很强大的工具，
rndc reload
rndc status
压力测试：
cd /root/bind-9.11.0-P1/contrib/queryperf/
./configure
make -j 4
vim /app/test.txt
./queryperf -d /app/test.txt
打开日志功能：
rndc querylog
rndc status
queryperf -d test.txt -s 127.0.0.1
wc -l /var/log/message
7.DNS排错
dig A example.com
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> A example.com
;; global options: +cmd • ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30523
...
SERVFAIL:The nameserver encountered a problem while processing the query.----可使用dig +trace排错，可能是网络和防火墙导致
NXDOMAIN：The queried name does not exist in the zone. ----可能是CNAME对应的A记录不存在导致
REFUSED：The nameserver refused the client's DNS request due to policy restrictions.----可能是DNS策略导致
NOERROR不代表没有问题，也可以是过时的记录
查看是否为权威记录，flags:aa标记判断
被删除的记录仍能返回结果，可能是因为*记录存在 • 如：*.example.com． IN A 172.25.254.254 泛域名解析
注意“.”的使用 • 避免CNAME指向CNAME记录，可能产生回环 test.example.com. IN CNAME lab.example.com.
lab.example.com. IN CNAME test.example.com.
正确配置PTR记录，许多服务依赖PTR，如sshd,MTA
正确配置轮询round-robin记录
做实验时遇到的坑：
1.关闭防火墙!
2.默认网关只有一个，不然跨网关通信时，路由不知道选哪个网关会导致不能跨网段通信！
3.DNS绝大多数故障是由于配置文件语法的问题。甚至有时候连named-checkconf和named-checkzone也检查不出来，所以我把重要且容易出错的源码
贴上，这样以后只需稍做修改即可使用！
4.另外：除了上述介绍的DNS工具外，还有像dlint（详细的语法检查和排错工具）、dnstop(交互式查看S和D的)、whosi（精确查找DNS包括地址和传真
）、VisualRoute（高度集成的可视化强大工具），有兴趣可以了解下。
5.补充：关于/dev/random和/dev/urandom的区别：dev/random和/dev/urandom是Linux系统中提供的随机伪设备，这两个设备的任务，是提供永不为
空的随机字节数据流。很多解密程序与安全应用程序（如SSH Keys,SSL Keys等）需要它们提供的随机数据流。这两个设备的差异在于：/dev/random
的random pool依赖于系统中断，因此在系统的中断数不足时，/dev/random设备会一直封锁，尝试读取的进程就会进入等待状态，直到系统的中断
数充分够用,/dev/random设备可以保证数据的随机性。/dev/urandom不依赖系统的中断，也就不会造成进程忙等待，但是数据的随机性也不高。在cat
的过程中发现，/dev/random产生的速度比较慢，有时候还会出现较大的停顿，而/dev/urandom的产生速度很快，基本没有任何停顿。