前言：在實際生產環境中由於需求和環境不同，所需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的產生速度很快，基本沒有任何停頓。