介紹
在學習如何配置網站和服務器時，DNS或域名系統通常是一個難以實現的組件。雖然大多數人可能會選擇使用其託管公司或其域名註冊商提供的DNS服務器，但創建自己的DNS服務器有一些優勢。
在本指南中，我們將討論如何在Ubuntu 16.04計算機上安裝和配置Bind9 DNS服務器作爲緩存或轉發DNS服務器。這兩種配置在服務機器網絡時都具有優勢。
要完成本教程，你需要具備一臺已經設置好可以使用sudo命令的非root賬號的Ubuntu服務器，並且已開啓防火牆。沒有服務器的同學可以在這裏購買，不過我個人更推薦您使用免費的騰訊雲開發者實驗室進行試驗，學會安裝後再購買服務器。
準備和目標
要完成本指南，您首先需要熟悉一些常見的DNS術語。
我們將演示兩個實現類似目標的獨立配置：緩存和轉發DNS服務器。
要繼續，您需要訪問兩臺計算機（其中至少一臺應該是Ubuntu 16.04服務器）。一個將作爲客戶端，另一個將配置爲DNS服務器。使服務器進入良好的初步狀態。
我們的示例配置的詳細信息如下：
角色 | IP地址 |
|---|---|
DNS服務器 | 192.0.2.2 |
客戶 | 192.0.2.100 |
我們將向您展示如何配置客戶端計算機以使用DNS服務器進行查詢。我們將根據您的需要向您展示如何以兩種不同的配置配置DNS服務器。
緩存DNS服務器
第一個配置是用於緩存 DNS服務器。這種類型的服務器也稱爲解析器，因爲它處理遞歸查詢，並且通常可以處理從其他服務器跟蹤DNS數據的繁重工作。
當緩存DNS服務器跟蹤客戶端查詢的答案時，它會將答案返回給客戶端。但是它也在記錄的TTL值允許的時間內將答案存儲在它的緩存中。然後可以將高速緩存用作後續請求的源，以便加速總往返時間。
您在網絡配置中可能擁有的幾乎所有DNS服務器都將緩存DNS服務器。這些彌補了大多數客戶端計算機上缺少足夠的DNS解析器庫的缺陷。對於許多情況，緩存DNS服務器是一個不錯的選擇。如果您不希望依賴您的ISP DNS或其他公共可用的DNS服務器，那麼製作您自己的緩存服務器是一個不錯的選擇。如果它與客戶端計算機的物理距離很近，則很可能會改善DNS查詢時間。
轉發DNS服務器
我們將演示的第二個配置是轉發 DNS服務器。從客戶端的角度來看，轉發DNS服務器看起來與緩存服務器幾乎完全相同，但機制和工作負載卻截然不同。
轉發DNS服務器提供相同的優勢，即維護緩存以改善客戶端的DNS解析時間。但是，它實際上沒有執行任何遞歸查詢。相反，它將所有請求轉發到外部解析服務器，然後緩存結果以用於以後的查詢。
這使轉發服務器可以從其緩存中進行響應，同時不要求它執行遞歸查詢的所有工作。這允許服務器僅發出單個請求（轉發的客戶端請求），而不必經歷整個遞歸例程。在外部帶寬傳輸成本高昂，可能需要經常更改緩存服務器，或者希望將本地查詢轉發到一臺服務器以及將外部查詢轉發到另一臺服務器的環境中，這可能是一個優勢。
在DNS服務器上安裝綁定
無論您希望使用哪種配置選項，實現綁定DNS服務器的第一步是安裝實際的軟件。
Bind軟件在Ubuntu的默認存儲庫中可用，因此我們只需更新本地軟件包索引並使用apt安裝軟件。我們還將包括文檔和一些常用實用程序：
sudo apt-get update sudo apt-get install bind9 bind9utils bind9-doc
現在已經安裝了Bind組件，我們可以開始配置服務器了。轉發服務器將使用緩存服務器配置作爲跳轉點，因此無論您的最終目標如何，首先將服務器配置爲緩存服務器。
配置爲緩存DNS服務器
首先，我們將介紹如何配置Bind以充當緩存DNS服務器。當客戶端發出查詢時，此配置將強制服務器以遞歸方式從其他DNS服務器尋求答案。這意味着它正在進行查詢每個相關DNS服務器的工作，直到它找到整個響應。
Bind配置文件默認保存在/etc/bind目錄中。立即進入該目錄：
cd /etc/bind
我們不會關心此目錄中的大多數文件。主配置文件名爲named.conf（named和bind是同一應用程序的兩個名稱）。此文件只是簡單的提供named.conf.options文件，named.conf.local文件和named.conf.default-zones文件。
對於緩存DNS服務器，我們只會修改named.conf.options文件。使用sudo權限在文本編輯器中打開它：
sudo nano named.conf.options
刪除評論以便於閱讀，文件如下所示：
options {
directory "/var/cache/bind";
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};要配置緩存，第一步是設置訪問控制列表或ACL。
作爲將用於解決遞歸查詢的DNS服務器，我們不希望惡意用戶濫用DNS服務器。稱爲DNS放大攻擊的攻擊尤其麻煩，因爲它可能導致您的服務器參與分佈式拒絕服務攻擊。
DNS放大攻擊是惡意用戶試圖關閉互聯網上的服務器或站點的一種方式。爲此，他們嘗試查找將解析遞歸查詢的公共DNS服務器。他們欺騙受害者的IP地址併發送一個查詢，該查詢將向DNS服務器返回大量響應。在這樣做時，DNS服務器響應具有針對受害者服務器的大有效負載的小請求，有效地放大攻擊者的可用帶寬。
託管公共遞歸DNS服務器需要大量特殊配置和管理。爲避免將服務器用於惡意目的，我們將配置一個我們信任的IP地址或網絡範圍列表。
在options塊上方，我們將創建一個名爲的新塊acl。爲要配置的ACL組創建標籤。在本指南中，我們將致電該集團的客戶。
acl goodclients {
};
options {
. . .在此塊中，列出應允許使用此DNS服務器的IP地址或網絡。由於我們的服務器和客戶端都在我們示例中的同一/ 24子網內運行，因此我們將示例限制在此網絡中。您應該調整此選項以包括您自己的客戶，而不包括外部各方。我們還將添加localhost和localnets，他們將嘗試自動執行此操作：
acl goodclients {
192.0.2.0/24;
localhost;
localnets;
};
options {
. . .現在我們有一個我們想要解析請求的客戶端ACL，我們可以在options塊中配置這些功能。在此塊中，添加以下行：
. . .
options {
directory "/var/cache/bind";
recursion yes;
allow-query { goodclients; };
. . .我們明確地啓用了遞歸，然後配置allow-query參數以使用我們的ACL規範。我們可以使用不同的參數，比如allow-recursion來引用我們的ACL組。如果存在並且遞歸，allow-recursion則將指示可以使用遞歸服務的客戶端列表。
但是，如果allow-recursion未設置，則Bind將返回allow-query-cache列表，然後是allow-query列表，最後只會回到默認值localnets和localhost。由於我們正在配置僅緩存服務器（它沒有自己的權威區域並且不轉發請求），因此allow-query列表將始終僅適用於遞歸。我們正在使用它，因爲它是指定ACL的最常用方法。
完成這些更改後，保存並關閉該文件。
這實際上是緩存DNS服務器所需的全部內容。如果您確定這是您希望使用的服務器類型，請隨時跳過以瞭解如何檢查配置文件，重新啓動服務以及實現客戶端配置。
否則，請繼續閱讀以瞭解如何設置轉發DNS服務器。
配置爲轉發DNS服務器
如果轉發DNS服務器更適合您的基礎架構，我們可以輕鬆地設置它。
我們將從緩存服務器配置中的配置開始。named.conf.options文件應如下所示：
acl goodclients {
192.0.2.0/24;
localhost;
localnets;
};
options {
directory "/var/cache/bind";
recursion yes;
allow-query { goodclients; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};我們將使用相同的ACL列表將DNS服務器限制爲特定的客戶端列表。但是，我們需要更改配置，以便服務器不再嘗試自己執行遞歸查詢。
要做到這一點，我們就不會改變recursion到沒有。轉發服務器仍然通過回答對其不具有權威性的區域的查詢來提供遞歸服務。相反，我們需要設置一個緩存服務器列表來轉發我們的請求。
這將在options {}塊內完成。首先，我們在被調用的內部創建一個塊forwarders，其中包含我們要轉發請求的遞歸名稱服務器的IP地址。在我們的指南中，我們將使用Google的公共DNS服務器（8.8.8.8和8.8.4.4）：
. . .
options {
directory "/var/cache/bind";
recursion yes;
allow-query { goodclients; };
forwarders {
8.8.8.8;
8.8.4.4;
};
. . .之後，我們應該將forward指令設置爲“only”，因爲此服務器將轉發所有請求，並且不應嘗試自行解析請求。
完成後，配置文件將如下所示：
. . .
options {
directory "/var/cache/bind";
recursion yes;
allow-query { goodclients; };
forwarders {
8.8.8.8;
8.8.4.4;
};
forward only;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};我們應該做的最後一個改變是dnssec參數。使用當前配置，根據轉發的DNS服務器的配置，您可能會在日誌中看到一些如下所示的錯誤：
Jun 25 15:03:29 cache named[2512]: error (chase DS servers) resolving 'in-addr.arpa/DS/IN': 8.8.8.8#53 Jun 25 15:03:29 cache named[2512]: error (no valid DS) resolving '111.111.111.111.in-addr.arpa/PTR/IN': 8.8.4.4#53
要避免這種情況，請將dnssec-validation設置更改爲“yes”並顯式啓用dnssec：
. . . forward only; dnssec-enable yes; dnssec-validation yes; auth-nxdomain no; # conform to RFC1035 . . .
完成後保存並關閉文件。您現在應該有一個轉發DNS服務器。繼續下一部分以驗證配置文件並重新啓動守護程序。
測試配置並重新啓動綁定
現在您已將Bind服務器配置爲緩存DNS服務器或轉發DNS服務器，我們已準備好實施我們的更改。
在我們採用插件並在我們的系統上重新啓動Bind服務器之前，我們應該使用Bind的附帶工具來檢查配置文件的語法。
我們可以通過輸入以下內容輕鬆完成：
sudo named-checkconf
如果配置中沒有語法錯誤，則shell提示將立即返回，而不顯示任何輸出。
如果配置文件中存在語法錯誤，則會向您發出錯誤和行號的警報。如果發生這種情況，請返回並檢查文件是否有錯誤。
驗證配置文件沒有任何語法錯誤後，重新啓動Bind守護程序以實現更改：
sudo systemctl restart bind9
如果您按照初始服務器設置指南進行操作，則會在您的服務器上啓用UFW防火牆。我們需要允許DNS流量到我們的服務器以響應客戶端請求。
通過鍵入以下內容爲Bind的防火牆策略啓用例外：
sudo ufw allow Bind9
然後，在設置客戶端計算機時，請密切關注服務器日誌，以確保一切順利進行。讓它在服務器上運行：
sudo journalctl -u bind9 -f
現在，打開一個新的終端窗口來配置客戶端計算機。
配置客戶端計算機
現在您已啓動並運行服務器，您可以將客戶端計算機配置爲使用此DNS服務器進行查詢。
登錄到您的客戶端計算機。確保在您爲DNS服務器設置的ACL組中指定了您正在使用的客戶端。否則，DNS服務器將拒絕爲客戶端提供請求。
我們需要編輯/etc/resolv.conf文件以將服務器指向名稱服務器。此處所做的更改將持續到重新啓動，這非常適合測試。如果我們對測試結果感到滿意，我們可以將這些更改永久化。
在文本編輯器中使用sudo權限打開文件：
sudo nano /etc/resolv.conf
該文件將列出用於通過設置nameserver指令來解析查詢的DNS服務器。註釋掉所有當前條目並添加指向DNS服務器的行nameserver：
nameserver 192.0.2.2 # nameserver 8.8.4.4 # nameserver 8.8.8.8 # nameserver 209.244.0.3
保存並關閉文件。
現在，您可以通過使用一些常用工具進行測試以確保查詢可以正確解析。
您可以用ping來測試可以對域進行的連接：
ping -c 1 google.com
Output PING google.com (173.194.33.1) 56(84) bytes of data. 64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms --- google.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms
這意味着我們的客戶端可以使用我們的DNS服務器連接google.com。
我們可以使用dig等DNS特定工具獲取更詳細的信息。這次嘗試使用其他域名：
dig linuxfoundation.org
Output ; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35417 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;linuxfoundation.org. IN A ;; ANSWER SECTION: linuxfoundation.org. 6017 IN A 140.211.169.4 ;; Query time: 36 msec ;; SERVER: 192.0.2.2#53(192.0.2.2) ;; WHEN: Wed Jun 25 15:45:57 EDT 2014 ;; MSG SIZE rcvd: 64
您可以看到查詢花了36毫秒。如果我們再次發出請求，服務器應該從其緩存中提取數據，從而減少響應時間：
dig linuxfoundation.org
Output ; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18275 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;linuxfoundation.org. IN A ;; ANSWER SECTION: linuxfoundation.org. 6012 IN A 140.211.169.4 ;; Query time: 1 msec ;; SERVER: 192.0.2.2#53(192.0.2.2) ;; WHEN: Wed Jun 25 15:46:02 EDT 2014 ;; MSG SIZE rcvd: 64
如您所見，緩存的響應速度明顯加快。
我們還可以使用我們在dig -x選項中建立的IP地址（在我們的例子中的140.211.169.4）測試反向查找：
dig -x 140.211.169.4
Output ; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 140.211.169.4 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61516 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;4.169.211.140.in-addr.arpa. IN PTR ;; ANSWER SECTION: 4.169.211.140.in-addr.arpa. 3402 IN CNAME 4.0-63.169.211.140.in-addr.arpa. 4.0-63.169.211.140.in-addr.arpa. 998 IN PTR load1a.linux-foundation.org. ;; Query time: 31 msec ;; SERVER: 192.0.2.2#53(192.0.2.2) ;; WHEN: Wed Jun 25 15:51:23 EDT 2014 ;; MSG SIZE rcvd: 117
如您所見，反向查找也成功。
回到DNS服務器上，您應該看到在測試期間是否記錄了任何錯誤。可能出現的一個常見錯誤如下所示：
Output from sudo journalctl -u bind9 -f . . . Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.net/A/IN': 2001:dc0:4001:1:0:1836:0:140#53 Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.com/A/IN': 2001:503:a83e::2:30#53 Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'sns-pb.isc.org/AAAA/IN': 2001:500:f::1#53 Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'ns3.nic.fr/A/IN': 2a00:d78:0:102:193:176:144:22#53
這些表示服務器正在嘗試解析IPv6信息，但服務器未配置IPv6。您可以通過告訴Bind僅使用IPv4來解決此問題。
爲此，我們可以修改啓動Bind9的systemd單元文件：
sudo systemctl edit --full bind9
在顯示的文件中，添加-4到ExecStart行的末尾以將服務器限制爲IPv4請求：
[Unit] Description=BIND Domain Name Server Documentation=man:named(8) After=network.target [Service] ExecStart=/usr/sbin/named -f -u bind -4 ExecReload=/usr/sbin/rndc reload ExecStop=/usr/sbin/rndc stop [Install] WantedBy=multi-user.target
完成後保存並關閉文件。
重新加載systemd守護程序以將已更改的單元文件讀入init系統：
sudo systemctl daemon-reload
重新啓動Bind9服務以實現更改：
sudo systemctl restart bind9
您不會再次在日誌中看到這些錯誤。
使客戶端DNS設置永久化
如前所述，將客戶端計算機指向我們的DNS服務器的/etc/resolv.conf設置將無法在重新啓動後繼續存在。要使更改持續，我們需要修改用於生成此文件的文件。
如果客戶端計算機正在運行Debian或Ubuntu，請使用sudo權限打開/etc/network/interfaces文件：
sudo nano /etc/network/interfaces
尋找dns-nameservers參數。您可以刪除現有條目並將其替換爲DNS服務器，或者只添加DNS服務器作爲以下選項之一：
. . .
iface eth0 inet static
address 192.168.2.100
netmask 255.255.255.0
gateway 192.168.2.1
dns-nameservers 192.0.2.2
. . .完成後保存並關閉文件。下次啓動時，將應用您的設置。
如果客戶端運行CentOS或Fedora，則需要打開/etc/sysconfig/network/network-scripts/ifcfg-eth0文件：
sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0
在裏面，尋找以它開頭的線條DNS。切換DNS1到您的DNS服務器。如果您不想將其他DNS服務器用作後備，請刪除其他條目：
. . . DNS1=192.0.2.2 . . .
完成後保存並關閉文件。您的客戶端應在下次啓動時使用這些設置。
結論
您現在應該配置一個緩存或轉發DNS服務器來爲您的客戶端提供服務。這可以是加速您管理的計算機的DNS查詢的好方法。
想要了解更多關於配置綁定爲緩存或轉發DNS服務器的相關教程，請前往騰訊雲+社區學習更多知識。
參考文獻：《How To Configure Bind as a Caching or Forwarding DNS Server on Ubuntu 16.04》