（一）瞭解DNS整個工作流程
域名解析是把域名指向網站空間IP，讓人們通過註冊的域名可以方便的訪問到網站的一種服務。IP地址是網絡上表示站點的數字地址，爲了方便記憶，採用域名來代替IP地址標識站點地址。域名解析就是域名到IP地址的轉換過程。域名的解析工作有DNS服務器完成。
域名解析也叫域名指向、服務器設置、域名配置以及反向IP登記等。說得簡單點就是將好記的域名解析成IP，服務器由DNS服務器完成，是把域名解析到一個IP地址，然後在此IP地址的主機上將一個子目錄與域名綁定。互聯網中的地址是數字的IP地址，域名解析的作用主要就是爲了便於記憶。
假設我們現在有一臺PC客戶端需要訪問百度服務器www.baidu.com 。我們知道www.baidu.com 代表的是baidu.com域中的一臺主機服務器，而baidu.com域中除了存在提供Web服務的服務器，還可能會存在提供文件傳輸的ftp.baidu.com，提供郵件服務的mail.baidu.com等等，它們都是baidu.com域中的一臺臺主機。然而這臺PC客戶端並不知道www.baidu.com 的IP地址是多少，但是如果這臺PC客戶端需要和遠端的www.baidu.com 服務器進行通信，它必須需要通過本地的DNS服務器獲取。比如這臺PC在深圳，那麼它會通過撥號上網連接到深圳電信DNS服務器發出查詢請求：“請問你是否知道www.baidu.com 主機的IP地址是多少？”此時深圳電信DNS服務器並不能告訴這臺PC客戶端具體的IP地址是多少，而在全球世界各地存在着13臺DNS服務器，它們稱之爲根域DNS服務器，爲全世界提供根域查詢的服務。此時深圳電信DNS服務器便會通過算法查詢到最近的一臺根域DNS服務器，併發出查詢請求：“請問你是否知道www.baidu.com 主機的IP地址是多少？”此時根域DNS服務器回覆：“查詢的信息太精確，無法回答，但是你查詢的com域是註冊在我根域中的域名，可以去向com查詢具體結果。”這時候深圳電信DNS服務器會向com頂級域中的DNS服務器發出查詢請求：“請問你是否知道www.baidu.com 主機的IP地址是多少？”此時com域的DNS服務器會回覆：“查詢的信息太精確，無法回答，但是你查詢的baidu域是註冊在我服務器上的，可以去向baidu域查詢具體結果。”此時深圳電信會向baidu域的DNS服務器發出查詢請求：“請問你是否知道www.baidu.com 主機的IP地址是多少？”由於www.baidu.com 主機的IP地址是由DNS.baidu.com服務器維護的，所以baidu域的DNS服務器會回覆：“知道，查詢的IP地址是xxx”。此時深圳電信DNS便知道了www.baidu.com 服務器的IP地址，它會將結果告訴這臺PC客戶端，所以最後這臺PC機就可以使用查詢到的IP地址和www.baidu.com 服務器進行通信了。其中PC機向深圳電信DNS發出查詢請求，就必須要得到深圳電信DNS服務器的返回結果，深圳電信DNS經過一層層的查詢最後返回給客戶端PC機得到的結果，這種有深圳電信DNS查詢結果返回給客戶端查詢方式稱爲“遞歸查詢”；但是深圳電信DNS在向根域DNS服務器查詢時，根域DNS服務器知道結果就返回給詢問方，不知道結果就不回答或者只是指引其向下查詢的路徑，後面的頂級com域DNS服務器也是按照這個方式迴應深圳電信DNS查詢，深圳DNS主機通過這種方式查詢到結果的方式稱爲“迭代查詢”。
並不是所有的本地DNS服務器都會執行遞歸查詢的請求，有時候地區的運營商可能只會對自己所管理的網段用戶提供遞歸查詢的操作以此來提高服務效率。例如有用戶帶着筆記本電腦從深圳到北京出差，用戶的IP地址使用網絡自動獲取的北京運營商提供的IP地址，但是用戶筆記本的DNS服務器的地址仍然使用深圳地區運營商IP地址，這時候用戶就會發現QQ，微信，釘釘等通訊軟件可以正常的使用，但網頁也只有深圳地區極個別網頁能打開，其他的網頁都顯示無法打開的情況，這時候其實最好的辦法就是也將DNS服務器的地址也設置爲自動獲取即可，其實在互聯網中也存在着一些DNS服務器，對全球的主機查詢都提供遞歸查詢請求的服務，例如8.8.8.8,4.4.4.4,114.114.114.114等DNS服務器主機，有時候我們也可以很好的利用起來。
（二）配置unbound作爲DNS服務器
(2.1)我們使用unbound軟件來進行DNS服務的配置，首先在vms001主機上安裝unbound軟件。
(2.2)在我們的系統中通常會使用如下的DNS服務系統架構，有兩臺DNS服務器，分別是主DNS：master和輔DNS：slave，其中主DNS服務器上的數據都會定期同步到輔DNS上，在進行主輔信息同步的時候使用的是tcp的53端口；而客戶端一般會設置兩個DNS地址用於查詢請求，當客戶端PC向主DNS或者輔DNS查詢的時候使用的是UDP的53端口。所以我們一般也是要在防火牆中設置開放DNS服務。
(2.3)進入到/etc/unbound/目錄中，編輯unbound.conf配置文件。
(2.4)整個unbound.conf的框架主要包括server，local-zone，remote-control，stub-zone，forward-zone五個部分。
(2.5)在unbound.conf配置文件中的server框架下有一個參數爲interface，需要進行設置，將其服務對外開放。
(2.6)但是我們設置interface爲0.0.0.0後發現unbound服務重啓失敗了，這是由於我們的系統中有虛擬化環境存在，裝過了虛擬化環境後默認會有一個dnsmasq存在，這也是一個DNS服務，也是運行監聽在virbr0網卡的53端口。而我們設置interface時指定運行在所有網卡上，這和虛擬化環境中的dnsmasq產生了衝突，纔會導致我們配置完後服務重啓失敗。
(2.7)我們可以將interface設置爲本機IP地址192.168.26.101，這樣DNS服務就可以正常的重啓了。
(2.8)接着在server框架中我們設置access-control即unbound服務器的訪問控制列表也是允許所有主機可以訪問。
(2.9)然後在server框架中我們設置username的值爲空即可，一般username是做認證使用的。
(2.10)在server框架中我們常用到的配置就包含interface、access-control和username這三個。接下來include: /etc/unbound/local.d/*.conf表明在unbound.conf配置文件默認是會包含/etc/unbound/local.d/目錄下的所有後綴爲conf的文件的，一般我們的local-zone的信息就是通過這樣的方式提供的。配置完成後記得需要將unbound服務重啓一下。
(2.11)配置完成後我們可以檢查一下配置是否有錯誤：# unbound-checkconf
(2.12)我們使用vms002主機進行測試，我們將vms002主機的DNS服務器IP地址設置爲192.168.26.101
(2.13)接着我們在vms002主機上進行測試。
(2.14)我們繼續對local-zone中的存在於/etc/unbound/local.d/目錄下的aa.conf的配置文件中第二行進行配置。SOA（Start of Authority）表示驗證的開始。
(2.15)最後我們將vms001主機的DNS服務器的IP地址也指向192.168.26.101，並重啓網絡服務。至此我們便完成了配置unbound作爲DNS服務器。
（三）配置僅轉發DNS服務器
有時候我們在家裏上網的時候，會使用家庭版的路由器，這個時候家庭路由器通過WAN口將PC客戶端的請求和互聯網進行連接，家庭PC地址會設置在一個網段內，例如192.168.26.0網段，PC的IP地址爲192.168.26.10，網關的地址爲192.168.26.1。我們發現家裏的路由器中並沒有配置DNS的相關local-zone的條目，但是我們PC客戶端配置了DNS指向這個家庭路由器後仍然可以爲我們解析IP地址。這種類型其實就是一種僅轉發DNS服務器，當它接收到客戶端的域名解析的請求時，它是不會做解析的，它會連接到當地的互聯網運營商的DNS服務器，將接收到請求轉發到互聯網運營商的DNS服務器處理。
(3.1)我們將vms002主機配置爲僅轉發DNS服務器，安裝unbound軟件。
(3.2)在vms002主機上的/etc/unbound/目錄下，配置unbound.conf文件，設置vms002主機監聽IP地址爲192.168.26.102的53端口。
(3.3)設置access-control允許所有主機進行查詢的請求。
(3.4)然後在我們設置username的值爲空即可，一般username是做認證使用的。
(3.5)進入到/etc/unbound/目錄中，找到unbound.conf文件，使用forward-zone的模板信息，接着我們進入到/etc/unbound/local.d/目錄中，創建一個aa.conf的配置文件。
(3.6)在vms002主機的aa.conf配置文件中設置轉發的域名爲“example.com”，表示當外部客戶端只有在請求解析example.com域名時才做轉發服務，其他情況例如查詢“baidu.com”，則不作任何的操作。轉發的地址設置爲vms001主機地址：192.168.26.101
(3.7)在vms002主機上需要設置防火牆規則，允許DNS服務的通信，並將設置在防火牆中寫入持久態。並將unbound服務啓動起來。
(3.8)接着我們啓動一臺測試DNS效果的DNSClient客戶端，設置IP地址爲192.168.26.23
(3.9)然後我們在vms001主機和vms002主機執行抓包命令，在DNSClient主機執行請求解析的命令。可以看到vms001和vms002主機都有如下的抓包結果（圖3-13）
(3.10)以vms002提取的抓包結果爲例，首先DNSClient會向vms002主機詢問example.com的IP地址是多少，vms002主機會將詢問轉發到vms001主機進行查詢，vms001主機回覆了vms002主機的查詢結果爲192.168.26.101，此時因爲有DNSKEY的問題，所以vms002主機並不信任vms001主機的回覆結果。
(3.11)此時我們需要取消vms002主機向vms001主機回覆結果後的密鑰驗證步驟，可以進入vms001主機和vms002主機的/etc/unbound/目錄，編輯unbound.conf配置文件。
(3.12)此時vms002主機作爲一臺僅轉發的DNS服務器，便實現了正常的解析DNSClient客戶端的查詢請求了。
(3.13)如果我們希望這臺僅轉發DNS服務器可以解析所有的主機名解析請求，那麼就可以將name參數設置爲“.”即可，並將轉發的DNS地址設置爲一臺已經配置好DNS服務的主機上，這樣就可以建立起一個實用的僅轉發DNS服務器了。
小技巧：有時候我們也可以使用# dig +trace www.baidu.com 命令查詢DNS地址解析的過程。