DNS集群架構和優化

本篇文章介紹了DNS現狀和開源軟體Bind的相關內容。

回顧上篇文章：Elasticsearch 原理分析

DNS 現狀以及面臨的問題

在現如今的公司內部，我們可能需要解析成千上萬個內部域名以及內部機器名，而通過在機器上寫死 host IP 對應關係來解決解析問題，在域名與機器數量如此多的情況下，維護機器的 host 文件是一個成本很高的事情，因此在內部提供了 DNS 解析服務，用於提供各個機房的特殊解析服務，是一件很重要的事情。

但是隨著公司的發展越來越快，所需要提供解析也從幾千發展到上萬，我們可能會遇到一下這些問題：

1）修改記錄後生效時間慢，緊急故障切換時產生等待時間。

2）無法高效的記錄 DNS 請求日誌，回查、統計不方便。

3）每台 DNS 都管理自身的 Zone 文件，維護成本大。

4）Bind 性能差，無法充分利用宿主機性能。

在這種情況下，縮短記錄生效時間，減少維護成本，提升 Bind 性能的工作就被提上了日程。

本文在 DNS 解析器的選擇上，使用了 ISC 的開源軟體–Bind。

新版 Bind

1

什麼是 Bind

要說 Bind，就要說什麼是 DNS，DNS 是域名系統 (Domain Name System) 的縮寫，它是由解析器和域名伺服器組成的。

域名伺服器是指保存有該網路中所有主機的域名和對應 IP 地址，並具有將域名轉換為 IP 地址功能的伺服器。其中域名必須對應一個 IP 地址，而 IP 地址不一定有域名。域名系統採用類似目錄樹的等級結構。

域名伺服器為客戶機 / 伺服器模式中的伺服器方，它主要有兩種形式：主伺服器和轉發伺服器。將域名映射為 IP 地址的過程就稱為 「域名解析」。而 Bind 就是一款開源的實現 DNS 域名解析的軟體，它由域名解析器、域名授權伺服器和工具組成。

2

DNS 域名的解析過程

客戶端向發起一個 DNS 請求，如果該請求被本機緩存，則直接返回，否則將會到達本地 DNS 伺服器，本地 DNS 伺服器首先會去查詢自身的區域文件，如果匹配成功，返回結果，如果請求的解析不在自身的區域文件中，則將請求轉發出去，此時該 DNS 請求會根據根提示，逐步查找頂級域名，直到查到結果。

3

Bind 特性

隨著技術的革新，現在的機器的性能越來越高，但如果不修改 Bind 的一些配置限制，會導致 Bind 無法充分利用機器的性能，因此這裡談一下可以提升 Bind 性能的幾個點

1. ISC_SOCKET_MAXEVENTS

Bind 默認會開啟最多 64 個和內核的通信事件數，你可以通過修改源碼來達到增加通信事件數，代碼路徑為

bind-x.x.xx/lib/isc/unix/socket.c

2. ISC_SOCKET_MAXSOCKETS

Bind 默認使用的最大的套接字數目為 4096，你可以通過 named –S 來增加套接字數，注意套接字只能調高無法調低，你也可以在編譯前，在 bind-x.x.xx/lib/isc/unix/socket.c中修改該參數，注意1和2的調節會增加named對內存的使用量。

3. RCVBUFSIZE

Bind 的默認RCVBUFSIZE為32K，如果你想使用更大的接收隊列，可以在編譯前修改define RCVBUFSIZE，代碼路徑為

bind-x.x.xx/lib/isc/unix/socket.c

4. RESOLVER_NTASKS

這個一個很重要的參數，Bind 之所以存在一個性能瓶頸而不是隨著機器的 cpu 的提升而提升，很重要的一點就是因為 Bind 的域名解析過程是帶鎖的 (具體解析過程請參考bind-x.x.xx/bin
amedserver.c)，因此增加 Bind 的解析器任務的個數是非常重要的，增加解析器任務的數量能減少鎖的爭用並提高吞吐量，但這也很大的增加了 named 進程使用的內存，你可以在bind-x.x.xx/bin
amedserver.c和bind-x.x.xx/bin
amedclient.c中修改它。

4

性能測試

測試目標

PPS 峰值

丟包率與時延

測試環境

機器系統版本：Centos 7.3

機器內核版本：3.18

機器 CPU 型號：Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz

機器 CPU 個數：2

機器內存：128G

機器網卡：萬兆網卡

測試步驟與方法

測試工具：queryperf

測試方法：在壓力測試機上使用 queryperf 工具對 Bind 機器模擬請求，請求的總次數為 200W。測試命令為：

逐漸提高 X，來模擬並發，q 的測試值為 20，30，40，50，60，70，80(-q 表示一次發送的請求數默認為 20)。

測試結果

1) 當 q 逐漸變大，QPS 逐漸升高。QPS 峰值為 21W 左右。

2) Bind 伺服器和壓力測試機的網卡吞吐和 CPU 均未滿。Cpu.busy 值在 20% 左右。

Bind 架構

1

架構介紹

為了解決同步生效時間慢，減少維護成本等問題，我們現在的 Bind 架構為 DNS Master/Slave。

如上圖所示，A，B 兩個機房都有 Master DNS 與 Slave DNS，Slave DNS 通過宣告 VIP 的方式來提供集群服務，避免當單台 DNS 宕機時，影響整個 DNS 集群，這樣能有效的提高 DNS 集群的的魯棒性。

2

配置文件詳解

上文提到由於現在使用了 M/S 架構，所以 Master 和 Slave 上的配置文件也是不同的，下面我們就來扯一扯兩類機器配置的問題。先說 Master 的配置：

接下來我們就來解釋一下上述配置文件

Controls 中記錄的是使用 RNDC 相關配置

inet 127.0.0.1 port 953 定義通信 IP 和埠

Keys：定義允許操作的 Key

Allow：來限制允許操作的 IP

Logging 中定義 DNS 的日誌信息

Channel：後跟通道名，這個一個任意但是唯一的名字，用於將類別與通道定義相關連。

File：用於定義文件存放的路徑

Versions：用於保存文件的數量

Size：用於限制單個文件的日誌大小，默認單位為bytes，你也可以使用 K，M，G 等單位

Category：用於控制各種已經定義或者默認的 Channel name 類別，默認可以採用以下值。

Options 中保存著 named 的配置文件

Directory：表示 named 存儲的 Zone 文件路徑

pid-file：表示運行 named 時，pid 文件的路徑

allow-query：表示允許來查詢的 IP 列表，其內容可以是 IP, 可以是網段，

forwarders：表示當本機沒有對應解析時，DNS 會將請求遞歸下一跳機器。

Notify：用於表示是否發送 Notify 請求。可選參數為 notify yes | no | explicit;

Zone 中保存解析的詳細內容

Type：表示該 Zone 的類型，

File：表示該 Zone 解析文件存放的路徑

also-notify：表示當 Zone 文件修改時，Master DNS 會向哪些 Slave DNS 下發 Notify 請求。

最後是 Key ，Key 中保存著這台 DNS 持有的 TSIG 密鑰。

algorithm：表示該密鑰的加密方式，默認為 hmac-md5。

secret：表示該密鑰的密文，

接下來說一下 Slave DNS 的配置文件

Slave DNS 的配置文件與 Master DNS 的配置文件基本相同，主要的差距在於 Zone 中的 Type 為 Slave，且在 Zone 中還包含了 masters 欄位，其作用是記錄這個 Zone 文件會向哪台 Master 同步數據。

那些年我們錯過的注意事項與建議

1

match-clients

首先要說的是 match-clients， match-clients 只能在 view 中使用，其目的是讓 view 被目標客戶端匹配，match-clients 的配置參數如下：

當客戶端的其中一條情況滿足 match-clients 時，match-clients 就會將你的 Query 捕獲進 View，一般來說，區域化解析和智能 DNS，都離不開這個參數。要注意當有一條情況滿足 match-clients 的條件時，這個 Query 就會被這個 View 處理。當你的一個 query 中帶有 TSIG 與 IP 時，match-clients，容易將這個 query 的 tsig 與 IP 當成兩個條件或處理，最後導致你的 Query 命中了錯誤的 View。

2

對 Zone 文件的監控

要對 Zone 文件進行監控，我們首先來講一下 SOA，SOA 全稱為 Start Of Authority，它存放在 Zone 文件的第一行，每個 Zone 文件只能有一個 SOA，SOA 記錄了這個 Zone 負責的 name server，version number 等信息。

對 Zone 文件的監控主要有兩點:

1）該文件是否有錯誤

引起錯誤的原因有很多，比如錯誤的 SOA 內容，一個域名同時存在 A 記錄解析和 CNAME 記錄解析等，當該文件錯誤時，Bind 就無法正常載入該 Zone文件，而它的報錯日常會記錄在我上述所說的 logging 中

2）該文件是否實時生效

當你的 DNS 架構為 M/S 時，且確定 Master 上已經成功載入了對應的 Zone 文件，但是你如何知道 Slave 上已經生效了？有兩個方法 1）通過查看 Slave上的 Xfer-in 日誌，來確定你的記錄是否下發，2) 通過查看 Slave DNS 上 Zone 文件的 SOA 中的 serial number 與 Master 上的是否相同，來確定 Slave DNS 的記錄是否已經生效。

總結

本文介紹了 DNS 的相關知識，以及我們對開源軟體 Bind 的一些理解，以及我們對 Bind 的部署方式，以及優化方法，希望對大家有幫助。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！