一文搞懂 DNS 基礎知識，收藏起來有備無患~

DNS（Domain Name System），也叫網域名稱系統，是互聯網的一項服務。它實質上是一個域名和 IP 相互映射的分佈式數據庫，有了它，我們就可以通過域名更方便的訪問互聯網。

DNS 有以下特點：

分佈式的
協議支持 TCP 和 UDP，常用端口是 53
每一級域名的長度限制是 63
域名總長度限制是 253

那麼，什麼情況下使用 TCP，什麼情況下使用 UDP 呢?

最早的時候，DNS 的 UDP 報文上限大小是 512 字節，所以當某個 response 大小超過 512 (返回信息太多)，DNS 服務就會使用 TCP 協議來傳輸。後來 DNS 協議擴展了自己的 UDP 協議，DNS client 發出查詢請求時，可以指定自己能接收超過 512 字節的 UDP 包，這種情況下，DNS 還是會使用 UDP 協議。

分層的數據庫結構

DNS 的結構跟 Linux 文件系統很相似，像一棵倒立的樹。下面用站長之家的域名舉例：

最上面的. 是根域名，接着是頂級域名 com，再下來是站長之家域名 chinaz 依次類推。使用域名時，從下而上。s.tool.chinaz.com. 就是一個完整的域名，www.chinaz.com. 也是。

之所以設計這樣複雜的樹形結構，是爲了防止名稱衝突。這樣一棵樹結構，當然可以存儲在一臺機器上，但現實世界中完整的域名非常多，並且每天都在新增、刪除大量的域名，存在一臺機器上，對單機器的存儲性能就是不小的挑戰。另外，集中管理還有一個缺點就是管理不夠靈活。可以想象一下，每次新增、刪除域名都需要向中央數據庫申請是多麼麻煩。所以現實中的 DNS 都是分佈式存儲的。

根域名服務器只管理頂級域，同時把每個頂級域的管理委派給各個頂級域，所以當你想要申請 com 下的二級域名時，找 com 域名註冊中心就好了。例如你申請了上圖的 chinaz.com 二級域名，chinaz.com 再向下的域名就歸你管理了。當你管理 chinaz.com 的子域名時，你可以搭建自己的 nameserver，在 .com 註冊中心把 chinaz.com 的管理權委派給自己搭建的 nameserver。自建 nameserver 和不自建的結構圖如下:

一般情況下，能不自建就不要自建，因爲維護一個高可用的 DNS 也並非容易。據我所知，有兩種情況需要搭建自己的 nameserver：

搭建對內的 DNS。公司內部機器衆多，通過 IP 相互訪問太過凌亂，這時可以搭建對內的 nameserver，允許內部服務器通過域名互通
公司對域名廠商提供的 nameserver 性能不滿意。雖然頂級域名註冊商都有自己的 nameserver，但註冊商提供的 nameserver 並不專業，在性能和穩定性上無法滿足企業需求，這時就需要企業搭建自己的高性能 nameserver，比如增加智能解析功能，讓不同地域的用戶訪問最近的 IP，以此來提高服務質量

概括一下 DNS 的分佈式管理，當把一個域委派給一個 nameserver 後，這個域下的管理權都交由此 nameserver 處理。這種設計一方面解決了存儲壓力，另一方面提高了域名管理的靈活性 (這種結構像極了 Linux File System, 可以把任何一個子目錄掛載到另一個磁盤，還可以把它下面的子目錄繼續掛載出去)

頂級域名

像 com 這樣的頂級域名，由 ICANN 嚴格控制，是不允許隨便創建的。頂級域名分兩類:

通用頂級域名
國家頂級域名

通用頂級域名常見的如. com、.org、.edu 等，國家頂級域名如我國的. cn，美國的. us。一般公司申請公網域名時，如果是跨國產品，應該選擇通用頂級域名；如果沒有跨國業務，看自己喜好（可以對比各家頂級域的服務、穩定性等再做選擇）。這裏說一下幾個比較熱的頂級域，完整的頂級域參見維基百科。

me
me 頂級域其實是國家域名，是黑山共和國的國家域名，只不過它對個人開發申請，所以很多個人博主就用它作爲自己的博客域名（本博客也是這麼來的~)

io
很多開源項目常用 io 做頂級域名，它也是國家域名。因爲 io 與計算機中的 input/output 縮寫相同，和計算機的二機制 10 也很像，給人一種 geek 的感覺。相較於. com 域名，.io 下的資源很多，更多選擇。

DNS 解析流程

聊完了 DNS 的基本概念，我們再來聊一聊 DNS 的解析流程。當我們通過瀏覽器或者應用程序訪問互聯網時，都會先執行一遍 DNS 解析流程。標準 glibc 提供了 libresolv.so.2 動態庫，我們的應用程序就是用它進行域名解析（也叫 resolving）的，它還提供了一個配置文件/etc/nsswitch.conf 來控制 resolving 行爲，配置文件中最關鍵的是這行：

hosts:      files dns myhostname

它決定了 resolving 的順序，默認是先查找 hosts 文件，如果沒有匹配到，再進行 DNS 解析。默認的解析流程如下圖：

上圖主要描述了 client 端的解析流程，我們可以看到最主要的是第四步請求本地 DNS 服務器去執行 resolving，它會根據本地 DNS 服務器配置，發送解析請求到遞歸解析服務器（稍後介紹什麼是遞歸解析服務器)，本地 DNS 服務器在 /etc/resolv.conf 中配置。下面我們再來看看服務端的 resolving 流程：

我們分析一下解析流程：

客戶端向本地 DNS 服務器 (遞歸解析服務器) 發出解析 tool.chinaz.com 域名的請求
本地 dns 服務器查看緩存，是否有緩存過 tool.chinaz.com 域名，如果有直接返回給客戶端；

如果沒有執行下一步
本地 dns 服務器向根域名服務器發送請求，查詢 com 頂級域的 nameserver 地址
拿到 com 域名的 IP 後，再向 com nameserver 發送請求，獲取 chinaz 域名的 nameserver 地址
繼續請求 chinaz 的 nameserver，獲取 tool 域名的地址，最終得到了 tool.chinaz.com 的 IP，本地 dns 服務器把這個結果緩存起來，以供下次查詢快速返回
本地 dns 服務器把把結果返回給客戶端

遞歸解析服務器 vs 權威域名服務器

我們在解析流程中發現兩類 DNS 服務器，客戶端直接訪問的是遞歸解析服務器，它在整個解析過程中也最忙。它的查詢步驟是遞歸的，從根域名服務器開始，一直詢問到目標域名。

遞歸解析服務器通過請求一級一級的權威域名服務器，獲得下一目標的地址，直到找到目標域名的權威域名服務器

簡單來說：遞歸解析服務器是負責解析域名的，權威域名服務器是負責存儲域名記錄的

遞歸解析服務器一般由 ISP 提供，除此之外也有一些比較出名的公共遞歸解析服務器，如谷歌的 8.8.8.8，聯通的 114，BAT 也都有推出公共遞歸解析服務器，但性能最好的應該還是你的 ISP 提供的，只是可能會有 DNS 劫持的問題

緩存

由於整個解析過程非常複雜，所以 DNS 通過緩存技術來實現服務的魯棒性。當遞歸 nameserver 解析過 tool.chianaz.com 域名後，再次收到 tool.chinaz.com 查詢時，它不會再走一遍遞歸解析流程，而是把上一次解析結果的緩存直接返回。並且它是分級緩存的，也就是說，當下次收到的是 www.chinaz.com 的查詢時，由於這臺遞歸解析服務器已經知道 chinaz.com 的權威 nameserver，所以它只需要再向 chinaz.com nameserver 發送一個查詢 www 的請求就可以了。

根域名服務器遞歸解析服務器是怎麼知道根域名服務器的地址的呢？根域名服務器的地址是固定的，目前全球有 13 個根域名解析服務器，這 13 條記錄持久化在遞歸解析服務器中：

爲什麼只有 13 個根域名服務器呢，不是應該越多越好來做負載均衡嗎？之前說過 DNS 協議使用了 UDP 查詢，由於 UDP 查詢中能保證性能的最大長度是 512 字節，要讓所有根域名服務器數據能包含在 512 字節的 UDP 包中，根服務器只能限制在 13 個，而且每個服務器要使用字母表中單字母名

智能解析

智能解析，就是當一個域名對應多個 IP 時，當你查詢這個域名的 IP，會返回離你最近的 IP。

由於國內不同運營商之間的帶寬很低，所以電信用戶訪問聯通的 IP 就是一個災難，而智能 DNS 解析就能解決這個問題。

智能解析依賴 EDNS 協議，這是 google 起草的 DNS 擴展協議，修改比較簡單，就是在 DNS 包裏面添加 origin client IP, 這樣 nameserver 就能根據 client IP 返回距離 client 比較近的 server IP 了

國內最新支持 EDNS 的就是 DNSPod 了，DNSPod 是國內比較流行的域名解析廠商，很多公司會把域名利用 DNSPod 加速，它已經被鵝廠收購

域名註冊商

一般我們要註冊域名，都要需要找域名註冊商，比如說我想註冊 hello.com，那麼我需要找 com 域名註冊商註冊 hello 域名。com 的域名註冊商不止一家，這些域名註冊商也是從 ICANN 拿到的註冊權，參見如何申請成爲. com 域名註冊商

那麼，域名註冊商和權威域名解析服務器有什麼關係呢？

域名註冊商都會自建權威域名解析服務器，比如你在狗爹上申請一個. com 下的二級域名，你並不需要搭建 nameserver，直接在 godaddy 控制中心裏管理你的域名指向就可以了，原因就是你新域名的權威域名服務器默認由域名註冊商提供。當然你也可以更換，比如從 godaddy 申請的境外域名，把權威域名服務器改成 DNSPod，一方面加快國內解析速度，另一方面還能享受 DNSPod 提供的智能解析功能

用 bind 搭建域名解析服務器

由於網上介紹 bind 搭建的文章實在太多了，我就不再贅述了，喜歡動手的朋友可以網上搜一搜搭建教程，一步步搭建一個本地的 nameserver 玩一玩。這裏主要介紹一下 bind 的配置文件吧

bind 的配置文件分兩部分: bind 配置文件和 zone 配置文件

bind 配置文件

bind 配置文件位於 /etc/named.conf，它主要負責 bind 功能配置，如 zone 路徑、日誌、安全、主從等配置

其中最主要的是添加 zone 的配置以及指定 zone 配置文件。recursion 開啓遞歸解析功能，這個如果是 no，那麼此 bind 服務只能做權威解析服務，當你的 bind 服務對外時，打開它會有安全風險，如何防禦不當，會讓你的 nameserver 被 hacker 用來做肉雞

zone 配置文件

zone 的配置文件在 bind 配置文件中指定，下圖是一份簡單的 zone 配置：

zone 的配置是 nameserver 的核心配置，它指定了 DNS 資源記錄，如 SOA、A、CNAME、AAAA 等記錄，各種記錄的概念網上資料太多，我這裏就不重複了。其中主要講一下 SOA 和 CNAME 的作用。

SOA 記錄

SOA 記錄表示此域名的權威解析服務器地址。上文講了權威解析服務器和遞歸解析服務器的差別，當所有遞歸解析服務器中有沒你域名解析的緩存時，它們就會回源來請求此域名的 SOA 記錄，也叫權威解析記錄

CNAME

CNAME 的概念很像別名，它的處理邏輯也如此。一個 server 執行 resloving 時，發現 name 是一個 CNAME，它會轉而查詢這個 CNAME 的 A 記錄。一般來說，能使用 CNAME 的地方都可以用 A 記錄代替，那麼爲什麼還要發明 CNAME 這樣一個東西呢？它是讓多個域名指向同一個 IP 的一種快捷手段，這樣當最低層的 CNAME 對應的 IP 換了之後，上層的 CNAME 不用做任何改動。就像我們代碼中的硬編碼，我們總會去掉這些硬編碼，用一個變量來表示，這樣當這個變量變化時，我們只需要修改一處

配置完之後可以用 named-checkconf 和 named-checkzone 兩個命令來 check 我們的配置文件有沒有問題，之後就可以啓動 bind 服務了：

我們用 netstat -ntlp 來檢查一下服務是否啓動:

53 端口已啓動，那麼我們測試一下效果，用 dig 解析一下 www.hello.com 域名，使用 127.0.0.1 作爲遞歸解析服務器

我們看到 dig 的結果跟我們配置文件中配置的一樣是 1.2.3.4，DNS 完成了它的使命，根據域名獲取到 IP，但我們這裏用來做示範的 IP 明顯是個假 IP:)

用 DNS 實現負載均衡

一個域名添加多條 A 記錄，解析時使用輪詢的方式返回隨機一條，流量將會均勻分類到多個 A 記錄。

複製代碼上面的配置中，我們給 www 域添加了兩條 A 記錄，這種做法叫 multi-homed hosts，它的效果是：當我們請求 nameserver 解析 www.hello.com 域名時，返回的 IP 會在兩個 IP 中輪轉（默認行爲，有些智能解析 DNS 會根據 IP 判斷，返回一個離 client 近的 IP，距離請搜索 DNS 智能解析）。

其實每次 DNS 解析請求時，nameserver 都會返回全部 IP，如上面配置，它會把 1.2.3.4 和 1.2.3.5 都返回給 client 端。那麼它是怎麼實現 RR 的呢？nameserver 只是每次返回的 IP 排序不同，客戶端會把 response 裏的第一個 IP 用來發請求。

DNS 負載均衡 vs LVS 專業負載均衡

和 LVS 這種專業負載均衡工具相比，在 DNS 層做負載均衡有以下特點:

實現非常簡單
默認只能通過 RR 方式調度
DNS 對後端服務不具備健康檢查
DNS 故障恢復時間比較長（DNS 服務之間有緩存）
可負載的 rs 數量有限（受 DNS response 包大小限制)

真實場景中，還需要根據需求選擇相應的負載均衡策略

子域授權

我們從 .com 域下申請一個二級域名 hello.com 後，發展到某一天我們的公司擴大了，需要拆分兩個事業部 A 和 B，並且公司給他們都分配了三級域名 a.hello.com 和 b.hello.com，域名結構如下圖：

再發展一段時間，A 部門和 B 部門內部業務太多，需要頻繁的爲新產品申請域名，這個時候他們就想搭建自己的 namserver，並且需要上一級把相應的域名管理權交給自己，他們期望的結構如下：

注意第一階段和第二階段的區別：第一階段，A 部門想申請 a.hello.com 下的子域名，需要向上級申請，整個 a.hello.com 域的管理都在總公司；第二階段，A 部門先自己搭建 nameserver，然後總公司把 a.hello.com 域管理權轉交給自建的 nameserver，這個轉交管理權的行爲，就叫子域授權

子域授權分兩部操作:

A 部門自建 nameserver，並且在 zone 配置文件中指定 a.hello.com 的權威解析服務器爲自己的 nameserver 地址
總公司在 nameserver 上增加一條 NS 記錄，把 a.hello.com 域授權給 A 部門的 nameserver

第一步我們在用 bind 搭建域名解析服務器裏講過，只要在 zone 配置文件裏指定 SOA 記錄就好:

@       IN     SOA      ns.a.hello.com    admin.a.hello.com. (……)複製代碼

第二步，在 hello.com 域的 nameserver 上添加一條 NS 記錄:

這樣當解析 xx.a.hello.com 域名時，hello.com nameserver 發現配置中有 NS 記錄，就會繼續遞歸向下解析

DNS 調試工具

OPS 常用的 DNS 調試工具有：host，nslookup，dig

這三個命令都屬於 bind-utils 包，也就是 bind 工具集，它們的使用複雜度、功能依次遞增。關於它們的使用， man 手冊和網上有太多教程，這裏簡單分析一下 dig 命令的輸出吧：

dig 的參數非常多，功能也很多，詳細使用方法大家自行 man 吧

其他

DNS 放大攻擊

DNS 放大攻擊屬於 DoS 攻擊的一種，是通過大量流量佔滿目標機帶寬，使得目標機對正常用戶的請求拒絕連接從而掛掉。

思路

正常的流量攻擊，hack 機向目標機建立大量 request-response，但這樣存在的問題是需要大量的 hack 機器。因爲服務器一般的帶寬遠大於家用網絡，如果我們自己的家用機用來做 hack 機器，還沒等目標機的帶寬佔滿，我們的帶寬早超載了。

原理

DNS 遞歸解析的流程比較特殊，我們可以通過幾個字節的 query 請求，換來幾百甚至幾千字節的 resolving 應答（流量放大），並且大部分服務器不會對 DNS 服務器做防禦。那麼 hacker 們只要可以僞裝 DNS query 包的 source IP，從而讓 DNS 服務器發送大量的 response 到目標機，就可以實現 DoS 攻擊。

但一般常用的 DNS 服務器都會對攻擊請求做過濾，所以找 DNS 服務器漏洞也是一個問題。詳細的放大攻擊方法大家有興趣自行 google 吧，這裏只做一個簡單介紹 :)

作者：多米諾
鏈接：https://juejin.cn/post/6844903497494855687

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/r5TH1y3AS-f6hjGAQNdaTw