溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
今天就跟大家聊聊有關Bind進階是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
還是出于項目的需要，把Bind比較高級的功能做一個梳理，這其中包含：DNS遞歸迭代查詢、DNS子域授權、DNS轉發、DNS主從區域傳輸、DNS數據加密，每一個內容不僅記錄了它的實現原理，也相應的配上了我一行一行代碼的實踐測試及結果。
所有的測試都是基于我原來的文章：Bind服務搭建及測試上的代碼來進行的，所以下面的代碼如果有不理解的，請去看看我之前寫的文章。
為什么要把DNS的查詢稱之為遞歸迭代查詢：
遞歸是因為：
用戶端向我的服務端發起一次查詢請求，那么服務端如果有結果就返回，如果沒有結果就像上一級服務器再發一次請求，直到找到用戶需要的IP或者域名，這個過程可以稱之為遞歸。
迭代是因為：
當服務端向上一級服務器法請求的時候，它并不是一次請求就結束了，先是根域，再是二級域名這樣了，有多次的請求跟返回動作，這個過程可以稱之為迭代。
我在Bind搭建及測試這篇博文里面，對它們的流程做了更詳細的敘述，這里就不多寫了。
Bind既然有一個復雜的查詢流程，那么與之相對應的就會有一系列的配置項來控制這個流程。下面講的參數都是基于Bind的主配置文件named.conf。
recursion : {yes|no} 是否允許遞歸請求
allow-recursion : {address_match_list|any|none} 允許遞歸請求的范圍
recursion-clients : {number（填數字）} 客戶端執行遞歸請求的數量
named.conf配置文件的內容如下所示：
options {
directory "/var/named";
recursion yes;
};
zone "." {
type hint;
file "named.ca";
};
zone "liumapp.com" {
type master;
file "liumapp.com.zone";
};
zone "cnametest.com" {
type master;
file "cnametest.com.zone";
};
zone "32.29.115.in-addr.arpa" {
type master;
file "115.29.32.zone";
};可以看到，我默認是把遞歸查詢開啟的
隨便查詢一個域名，比如“www.qqq.com” 
可以發現，Bind為了找到www.qqq.com對應的IP地址，往上層域名服務器迭代了7次才找到最終結果。
現在我們將配置文件的recursion改為no，重啟Bind之后再查詢一個新的域名，比如"www.qqqq.com"(www.qqq.com已經做了緩存)
可以看到，關閉遞歸后我們是查不到新域名的解析記錄的。
在DNS迭代查詢的情況下，經常會用到NS記錄，同樣的，在DNS子域授權下面，NS記錄也會經常被用到。
子域授權：
比如我的一臺服務器A負責liumapp.com的權威域名解析，它再授權服務器B對liumapp.com的子域名:child.liumapp.com進行解析，這就叫做子域授權。
DNS迭代查詢利用的就是子域授權：通過根域，到二級域再依次往下迭代查詢。
我的父服務器IP為115.29.32.62，其解析的域名為www.liumapp.com，子服務器IP為106.14.212.41，其解析的域名為www.test.liumapp.com
首先在父服務器上，我們要對子服務器進行授權，具體配置liumapp.com.zone文件，添加如下內容：
test.liumapp.com. IN NS ns1.test ns1.test IN A 106.14.212.41
大意就是給liumapp.com的子域名test.liumapp.com分配權限給ns1.test，然后指定ns1.test的IP為106.14.212.41
重啟父服務器，然后進入子服務器的shell命令面板
首先我們對named.conf做一個備份，然后把它的內容修改為：
options {
directory "/var/named";
};
zone "test.liumapp.com" {
type master;
file "test.liumapp.com.zone";
};然后在/var/named/目錄下添加一個test.liumapp.com.zone文件，其內容為：
$TTL 7200 @ IN SOA test.liumapp.com. liumapp.com.gmail.com. (222 1H 15M 1W 1D) @ IN NS dns1.liumapp.com. dns1.liumapp.com. IN A 106.14.212.41 www.test.liumapp.com. IN A 106.14.212.42
接下來重啟Bind。 然后我們進行測試，首先對父服務器進行解析：
dig @115.29.32.62 www.test.liumapp.com
結果為：
然后我們對子服務器進行解析：
dig @106.14.212.41 www.test.liumapp.com
結果為：
假設有一個局域網，內部有兩臺DNS服務器，命名為A和B，局域網通過防火墻對外開放，但是只有A能夠直接對外提供DNS解析服務，B只能在局域網內的內網進行訪問，那當需要用到B的DNS解析的時候，就是通過A的forwarding轉發來實現。
首先看一下關于轉發的配置項
forwarders : {address_list} 表示轉發的服務器列表
forwarder only : 表示只由目的服務器權威解析
forwarder first : 優先轉發查詢
同樣是父服務器115.29.32.62和子服務器106.14.212.41，我們現在把父服務器用來負責DNS的某一個域作為轉發，子服務器用來負責某一個域的權威解析。
現在我們先配置子服務器的權威解析：
首先進入/var/named目錄，新建一個文件dnstest.com.zone(這個域名我并沒有擁有它，只是為了測試方便隨便寫的)，其內容為：
$TTL 7200 @ IN SOA dnstest.com. liumapp.com.gmail.com. (222 1H 15M 1W 1D) @ IN NS dns.dnstest.com. dns.dnstest.com. IN A 106.14.212.41 www.dnstest.com. IN A 6.6.6.6
然后修改named.conf，添加下列內容:
zone "dnstest.com" {
type master;
file "dnstest.com.zone";
};同時刪除原來的
zone "test.liumapp.com" {
type master;
file "test.liumapp.com.zone";
};重啟Bind。
然后進入父服務器的shell操作面板，在開始之前，我們要注意一點，就是Bind的DNS轉發只有在Bind9版本以上才支持，所以在開始之前，我們先使用命令查看一下Bind的版本：
nslookup -q=txt -class=CHAOS version.bind
我的服務器上出來的結果是：
[root@iZ28vhwdq63Z ~]# nslookup -q=txt -class=CHAOS version.bind. Server: 10.202.72.116 Address: 10.202.72.116#53 version.bind text = "9.9.9-P3-RedHat-9.9.9-2.1.alios6"
然后修改named.conf，添加以下內容：
zone "dnstest.com" {
type forward;
forwarders {106.14.212.41;};
}接下來我們在父服務器上使用dig命令:
dig [@127.0.0.1](https://my.oschina.net/u/567043) www.dnstest.com
請求解析www.dnstest.com域名，結果如下：
同時要注意，forward的正常使用需要遞歸查詢recursion開啟。
區域是DNS服務器的管轄范圍, 是由DNS名稱空間中的單個區域或由具有上下隸屬關系的緊密相鄰的多個子域組成的一個管理單位。 因此, DNS名稱服務器是通過區域來管理名稱空間的,而并非以域為單位來管理名稱空間,但區域的名稱與其管理的DNS名稱空間的域的名稱是一一對應的。或者說，一個區域對應一系列域名的解析。
假設我們有兩臺服務器，分別為dns主服務器Master和dns從服務器slave，那么他們之間的dns主從同步步驟是這樣的：
master發送notify信息給slave
slave去查詢主服務器的SOA記錄
master將SOA記錄發送給slave
slave根據SOA記錄去檢查serial number是否有遞增更新
如果有的話slave向master發起zone transfer請求，然后master返回響應結果，slave更新記錄。如果沒有的話就說明不需要更新。
在開始配置之前，先要注意幾個事項：
確保防火墻的規則不會攔截Bind的監聽端口，默認為53
確保named用戶擁有操作相關目錄的權限（/var/named）
確保主從服務器的時鐘一致
搭建完畢后，若修改主服務器域的配置，serial number必須遞增
Master服務器
zone "liumapp.com" {
type master;
notify yes;
also-notify{106.14.212.41;};
file "liumapp.com.zone";
}上面的notify yes表示開啟notify這個功能，also-notify{}里面放的是slave服務器的IP列表。
Slave服務器
options{
directory "/var/named";
allow-query { any; };
recursion yes;
};
zone "liumapp.com" {
type slave;
file "slaves/liumapp.com.zone";
masters {115.29.32.62;};
};上面的file表示從主服務器同步過來的信息存放地址，我這里就表示存放在/var/named/slaves/liumapp.com.zone
我把IP為115.29.32.62的dns server作為我的master，IP為106.14.212.41的dns server作為我的slave。
首先我們按照上面兩段代碼進行主從服務器的配置。
然后重啟兩臺服務器的Bind，重啟之后，應該就能夠在從服務器的/var/named/slaves/下找到一個liumapp.com.zone文件，它的內容應該跟主服務器的/var/named/liumapp.com.zone一致。
所以，這個時候我們不管使用命令
dig @115.29.32.62 www.liumapp.com
向主服務器請求www.liumapp.com的解析還是
dig @106.14.212.41 www.liumapp.com
向從服務器請求www.liumapp.com的解析，得到的結果最終都是一樣的。
現在我們按照上面的配置走完了一遍之后，來測試一下主從服務器之間的同步。
在Master服務器的/var/named/liumapp.com.zone文件上，我們添加一條解析記錄：
liumei.liumapp.com. IN A 8.8.5.6
然后添加一下它的serial number值，也就是：
liumapp.com. IN SOA liumapp.com. liumapp.com.gmail.com8 (225 1H 15M 1W 1D)
這條記錄里面的倒數第5個數“225”，我們把它改為226即可。
重啟服務器之后，敲命令：
dig @106.14.212.41 liumei.liumapp.com
即可成功在子服務器上解析到liumei.liumapp.com的記錄為8.8.5.6
首先，我們在本地一臺電腦上使用一個命令：
dig @115.29.32.62 axfr liumapp.com
不出意外，應該能夠得到liumapp.com在115.29.32.62這臺DNS server上的所有解析記錄
但是從安全角度來講，我肯定不希望這樣的事情發生，所以就要用到傳輸限制。
基于主機的訪問控制
通過主機IP來限制訪問。
allow-transfer : {address_list | none} , 允許域傳輸的機器列表
事務簽名
通過密鑰對數據進行加密。 事務簽名的測試我會放在后面的DNS數據加密里面來做。
我們在主服務器上的named.conf配置文件中進行修改：
zone "liumapp.com" {
type master;
notify yes;
also-notify {106.14.212.41;};
allow-transfer{106.14.212.41;};
file "liumapp.com.zone";
};重啟Bind之后，回到本地電腦上，繼續使用命令：
dig @115.29.32.62 axfr liumapp.com
結果如下，請求已被拒絕。
但是通過106.14.212.41是可以獲取數據的：
dig @106.14.212.41 axfr liumapp.com
結果如下：
DES 對稱加密
概述：文件加密和解密使用相同的密鑰，簡單快捷。
流程：假定有發送方A和接收方B，A和B有相同的密鑰，A發送明文給B之前，通過密鑰和加密算法，將明文加密成密文，發送給B，B再通過密鑰和解密算法，將密文解密成明文。
IDEA 非對稱加密
概述：密鑰包括公鑰和私鑰，安全性較DES方式高。
流程：假定有發送方A和接收方B，B有自己的私鑰和公鑰，A需要獲取B的公鑰，獲取之后，A首先自己生成一個會話密鑰，然后這個會話密鑰通過B的公鑰進行加密，加密后發送給B，B再通過自己的私鑰對它進行解密，從而得到A生成的會話密鑰。之后，A通過自己的會話密鑰將要發送的明文進行加密，發送給B，B通過事先得到的會話密鑰對發送過來的密文進行解密從而得到明文。
事務簽名可以通過兩種加密方式來實現，分別是：
TSIG:對稱方式
SIGO:非對稱方式
現在比較常用的是TSIG這種方法。
參數：
allow-transfer : {key keyfile}(key及key的文件位置); 事務簽名的key
首先我們進入主服務器，然后生成key：
在主服務器的/usr/key目錄下，注意賦予key目錄named用戶的讀權限
輸入以下命令：
dnssec-keygen -a HMAC-MD5 -b 128 -n HOST liumapp-key
-a : 加密算法
-b : 加密位數
-n : 可以選擇ZONE或者HOST
liumapp-key:密鑰名稱
我生成的公鑰文件和私鑰文件其內容如下所示：
然后我們復制私鑰里面的那段key的內容，再進入/var/named/chroot/etc目錄，新建一個liumapp-key文件
其內容為：
key "liumapp-key" {
Algorithm hmac-md5;
secret "ghWgud4mhN11PKBIITgxbg==";
};上面的secret的值是從生成的私鑰文件中復制來的。
然后編寫named.conf文件，添加以下內容：
include "/var/named/chroot/etc/liumapp-key";
注意，這段內容要放在zone "liumapp.com"之前。
然后修改zone "liumapp.com"的配置，最終配置結果如下：
include "/var/named/chroot/etc/liumapp-key";
zone "liumapp.com" {
type master;
notify yes;
also-notify {106.14.212.41;};
allow-transfer{key "liumapp-key";};
file "liumapp.com.zone";
};上面的allow-transfer的key的值是我命名的那個值。
然后我們重啟Bind，接下來是配置slave從服務器，不過在配置之前，需要先把我們的配置文件liumapp-key拷貝過去：
使用命令：
scp liumapp-key root@106.14.212.41:`pwd`
結果如下所示：
然后在從服務器的named.conf中進行配置，一個是把liumapp-key包含進去，然后配置key，最終結果如下所示：
options{
directory "/var/named";
allow-query { any; };
recursion yes;
};
include "/var/named/chroot/etc/liumapp-key";
server 115.29.32.62 {
keys {"liumapp-key";};
};
zone "dnstest.com" {
type master;
file "dnstest.com.zone";
};
zone "liumapp.com" {
type slave;
file "slaves/liumapp.com.zone";
masters {115.29.32.62;};
};重啟從服務器的Bind服務，然后我們再回到主服務器：
添加一條liumapp.com.zone下的A記錄，當然還需要遞增一下serial number也不知道加了多少，總之最后我的這個ZONE的內容如下所示：
$TTL 7200 liumapp.com. IN SOA liumapp.com. liumapp.com.gmail.com8 (226 1H 15M 1W 1D) liumapp.com. IN NS dns1.liumapp.com. dns1.liumapp.com. IN A 115.29.32.62 www.liumapp.com. IN A 106.14.212.41 liumei.liumapp.com. IN A 8.8.5.6 heiheihei.liumapp.com. IN A 9.9.9.9 @ IN MX 10 mail mail IN A 115.29.32.63 test.liumapp.com. IN NS ns1.test ns1.test IN A 106.14.212.41
然后重啟bind，再使用命令：
tail -f /var/log/messages
得到的信息如下所示：
可以看到，我修改了liumapp.com.zone之后，主服務器馬上同步到了從服務器上，而他們之間的交流，就是用到了TSIG事務簽名。
看完上述內容，你們對Bind進階是怎樣的有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
