前兩天我發(fā)的文章，被部分粉絲發(fā)現(xiàn)同步到其他網(wǎng)站上了，比如：今日頭條，網(wǎng)易新聞等渠道。

這些同步的人都不是我，從作者名稱也可以看出來，都不是“業(yè)余草”。希望大家在私信聊天時(shí)，注意上當(dāng)受騙。也感謝群友的發(fā)現(xiàn)，再次感謝各位粉絲的支持。

我今年前半年已經(jīng)發(fā)過一篇 DNS 相關(guān)知識(shí)的文章了，超清晰的 DNS 原理入門指南，如果沒看懂，我們進(jìn)行繼續(xù)聊。

DNS（Domain Name System）， 也叫網(wǎng)域名稱系統(tǒng)，是互聯(lián)網(wǎng)的一項(xiàng)服務(wù)。它實(shí)質(zhì)上是一個(gè) 域名 和 IP 相互映射的分布式數(shù)據(jù)庫，有了它，我們就可以通過域名更方便的訪問互聯(lián)網(wǎng)。

DNS 有以下特點(diǎn)：

• 分布式的
• 協(xié)議支持 TCP 和 UDP，常用端口是 53
• 每一級(jí)域名的長度限制是 63
• 域名總長度限制是 253

「那么，什么情況下使用 TCP，什么情況下使用 UDP 呢?」

最早的時(shí)候，DNS 的 UDP 報(bào)文上限大小是 512 字節(jié)， 所以當(dāng)某個(gè) response 大小超過512 (返回信息太多)，DNS 服務(wù)就會(huì)使用 TCP 協(xié)議來傳輸。后來 DNS 協(xié)議擴(kuò)展了自己的UDP 協(xié)議，DNS client 發(fā)出查詢請(qǐng)求時(shí)，可以指定自己能接收超過512字節(jié)的 UDP 包， 這種情況下，DNS 還是會(huì)使用 UDP 協(xié)議。

分層的數(shù)據(jù)庫結(jié)構(gòu)

DNS 的結(jié)構(gòu)跟 Linux 文件系統(tǒng)很相似，像一棵倒立的樹。下面用站長之家的域名舉例：

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

之所以設(shè)計(jì)這樣復(fù)雜的樹形結(jié)構(gòu)， 是為了防止名稱沖突。這樣一棵樹結(jié)構(gòu)，當(dāng)然可以存儲(chǔ)在一臺(tái)機(jī)器上，但現(xiàn)實(shí)世界中完整的域名非常多，并且每天都在新增、刪除大量的域名，存在一臺(tái)機(jī)器上，對(duì)單機(jī)器的存儲(chǔ)性能就是不小的挑戰(zhàn)。另外，集中管理還有一個(gè)缺點(diǎn)就是管理不夠靈活。可以想象一下，每次新增、刪除域名都需要向中央數(shù)據(jù)庫申請(qǐng)是多么麻煩。所以現(xiàn)實(shí)中的 DNS 都是分布式存儲(chǔ)的。

根域名服務(wù)器只管理頂級(jí)域，同時(shí)把每個(gè)頂級(jí)域的管理委派給各個(gè)頂級(jí)域，所以當(dāng)你想要申請(qǐng)com下的二級(jí)域名時(shí)，找 com 域名注冊(cè)中心就好了。例如你申請(qǐng)了上圖的 chinaz.com 二級(jí)域名，chinaz.com 再向下的域名就歸你管理了。當(dāng)你管理 chinaz.com 的子域名時(shí)，你可以搭建自己的 nameserver，在 .com 注冊(cè)中心把 chinaz.com 的管理權(quán)委派給自己搭建的nameserver。自建nameserver 和不自建的結(jié)構(gòu)圖如下:

一般情況下，能不自建就不要自建，因?yàn)榫S護(hù)一個(gè)高可用的 DNS 也并非容易。據(jù)我所知，有兩種情況需要搭建自己的 nameserver：

• 搭建對(duì)內(nèi)的 DNS。公司內(nèi)部機(jī)器眾多，通過 IP 相互訪問太過凌亂，這時(shí)可以搭建對(duì)內(nèi)的 nameserver，允許內(nèi)部服務(wù)器通過域名互通

• 公司對(duì)域名廠商提供的 nameserver 性能不滿意。雖然頂級(jí)域名注冊(cè)商都有自己的nameserver，但注冊(cè)商提供的 nameserver 并不專業(yè)，在性能和穩(wěn)定性上無法滿足企業(yè)需求，這時(shí)就需要企業(yè)搭建自己的高性能 nameserver，比如增加智能解析功能，讓不同地域的用戶訪問最近的 IP，以此來提高服務(wù)質(zhì)量

概括一下 DNS 的分布式管理， 當(dāng)把一個(gè)域委派給一個(gè)nameserver后，這個(gè)域下的管理權(quán)都交由此nameserver處理。這種設(shè)計(jì)一方面解決了存儲(chǔ)壓力，另一方面提高了域名管理的靈活性 (這種結(jié)構(gòu)像極了Linux File System, 可以把任何一個(gè)子目錄掛載到另一個(gè)磁盤，還可以把它下面的子目錄繼續(xù)掛載出去)

頂級(jí)域名

像 com 這樣的頂級(jí)域名，由 ICANN 嚴(yán)格控制，是不允許隨便創(chuàng)建的。頂級(jí)域名分兩類:

• 通用頂級(jí)域名
• 國家頂級(jí)域名

通用頂級(jí)域名常見的如.com、.org、.edu等， 國家頂級(jí)域名如我國的.cn， 美國的.us。一般公司申請(qǐng)公網(wǎng)域名時(shí)，如果是跨國產(chǎn)品，應(yīng)該選擇通用頂級(jí)域名；如果沒有跨國業(yè)務(wù)，看自己喜好（可以對(duì)比各家頂級(jí)域的服務(wù)、穩(wěn)定性等再做選擇）。這里說一下幾個(gè)比較熱的頂級(jí)域，完整的頂級(jí)域參見維基百科。

「me」

me頂級(jí)域其實(shí)是國家域名， 是黑山共和國的國家域名，只不過它對(duì)個(gè)人開發(fā)申請(qǐng)，所以很多個(gè)人博主就用它作為自己的博客域名

「io」

很多開源項(xiàng)目常用io做頂級(jí)域名，它也是國家域名。因?yàn)閕o 與計(jì)算機(jī)中的 input/output 縮寫相同，和計(jì)算機(jī)的二機(jī)制10也很像，給人一種geek的感覺。相較于.com域名，.io下的資源很多，更多選擇。

DNS 解析流程

聊完了 DNS 的基本概念，我們?cè)賮砹囊涣?DNS 的解析流程。當(dāng)我們通過瀏覽器或者應(yīng)用程序訪問互聯(lián)網(wǎng)時(shí)，都會(huì)先執(zhí)行一遍 DNS 解析流程。標(biāo)準(zhǔn) glibc 提供了 libresolv.so.2 動(dòng)態(tài)庫，我們的應(yīng)用程序就是用它進(jìn)行域名解析（也叫 resolving）的， 它還提供了一個(gè)配置文件/etc/nsswitch.conf 來控制 resolving 行為，配置文件中最關(guān)鍵的是這行：

hosts:      files dns myhostname

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

上圖主要描述了 client 端的解析流程，我們可以看到最主要的是第四步請(qǐng)求本地 DNS 服務(wù)器去執(zhí)行 resolving，它會(huì)根據(jù)本地 DNS 服務(wù)器配置，發(fā)送解析請(qǐng)求到遞歸解析服務(wù)器（稍后介紹什么是遞歸解析服務(wù)器)， 本地 DNS 服務(wù)器在 /etc/resolv.conf 中配置。下面我們?cè)賮砜纯捶?wù)端的 resolving 流程：

我們分析一下解析流程：

• 客戶端向本地DNS服務(wù)器(遞歸解析服務(wù)器) 發(fā)出解析tool.chinaz.com域名的請(qǐng)求

• 本地dns服務(wù)器查看緩存，是否有緩存過tool.chinaz.com域名，如果有直接返回給客戶端；如果沒有執(zhí)行下一步

• 本地dns服務(wù)器向根域名服務(wù)器發(fā)送請(qǐng)求，查詢com頂級(jí)域的nameserver 地址

• 拿到com域名的IP后，再向com nameserver發(fā)送請(qǐng)求，獲取chinaz域名的nameserver地址

• 繼續(xù)請(qǐng)求 chinaz 的nameserver，獲取 tool 域名的地址，最終得到了tool.chinaz.com 的 IP，本地 dns 服務(wù)器把這個(gè)結(jié)果緩存起來，以供下次查詢快速返回

• 本地dns服務(wù)器把把結(jié)果返回給客戶端

「遞歸解析服務(wù)器 vs 權(quán)威域名服務(wù)器」

我們?cè)诮馕隽鞒讨邪l(fā)現(xiàn)兩類 DNS 服務(wù)器，客戶端直接訪問的是 遞歸解析服務(wù)器， 它在整個(gè)解析過程中也最忙。它的查詢步驟是遞歸的，從根域名服務(wù)器開始，一直詢問到目標(biāo)域名。

遞歸解析服務(wù)器通過請(qǐng)求一級(jí)一級(jí)的權(quán)威域名服務(wù)器，獲得下一目標(biāo)的地址，直到找到目標(biāo)域名的權(quán)威域名服務(wù)器

簡單來說：遞歸解析服務(wù)器是負(fù)責(zé)解析域名的，權(quán)威域名服務(wù)器是負(fù)責(zé)存儲(chǔ)域名記錄的

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

「緩存」

由于整個(gè)解析過程非常復(fù)雜，所以 DNS 通過緩存技術(shù)來實(shí)現(xiàn)服務(wù)的魯棒性。當(dāng)遞歸nameserver 解析過 tool.chianaz.com 域名后，再次收到 tool.chinaz.com 查詢時(shí)，它不會(huì)再走一遍遞歸解析流程，而是把上一次解析結(jié)果的緩存直接返回。并且它是分級(jí)緩存的，也就是說，當(dāng)下次收到的是 www.chinaz.com 的查詢時(shí)， 由于這臺(tái)遞歸解析服務(wù)器已經(jīng)知道 chinaz.com 的權(quán)威 nameserver，所以它只需要再向 chinaz.com nameserver 發(fā)送一個(gè)查詢 www 的請(qǐng)求就可以了。

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

為什么只有 13 個(gè)根域名服務(wù)器呢，不是應(yīng)該越多越好來做負(fù)載均衡嗎？之前說過 DNS 協(xié)議使用了 UDP 查詢， 由于 UDP 查詢中能保證性能的最大長度是 512 字節(jié)，要讓所有根域名服務(wù)器數(shù)據(jù)能包含在512字節(jié)的UDP包中， 根服務(wù)器只能限制在13個(gè)， 而且每個(gè)服務(wù)器要使用字母表中單字母名

「智能解析」

智能解析，就是當(dāng)一個(gè)域名對(duì)應(yīng)多個(gè) IP 時(shí)，當(dāng)你查詢這個(gè)域名的 IP，會(huì)返回離你最近的 IP。

由于國內(nèi)不同運(yùn)營商之間的帶寬很低，所以電信用戶訪問聯(lián)通的IP就是一個(gè)災(zāi)難，而智能 DNS 解析就能解決這個(gè)問題。

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

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

域名注冊(cè)商

一般我們要注冊(cè)域名，都要需要找域名注冊(cè)商，比如說我想注冊(cè) hello.com，那么我需要找com域名注冊(cè)商注冊(cè)hello域名。com的域名注冊(cè)商不止一家， 這些域名注冊(cè)商也是從ICANN 拿到的注冊(cè)權(quán)， 參見如何申請(qǐng)成為.com域名注冊(cè)商

那么，域名注冊(cè)商 和 權(quán)威域名解析服務(wù)器  有什么關(guān)系呢？

域名注冊(cè)商都會(huì)自建權(quán)威域名解析服務(wù)器，比如你在狗爹上申請(qǐng)一個(gè).com下的二級(jí)域名，你并不需要搭建nameserver， 直接在godaddy控制中心里管理你的域名指向就可以了， 原因就是你新域名的權(quán)威域名服務(wù)器默認(rèn)由域名注冊(cè)商提供。當(dāng)然你也可以更換，比如從godaddy申請(qǐng)的境外域名，把權(quán)威域名服務(wù)器改成DNSPod，一方面加快國內(nèi)解析速度，另一方面還能享受DNSPod 提供的智能解析功能

用 bind 搭建域名解析服務(wù)器

bind搭建的文章網(wǎng)上很多，百度直接搜，我這里就不細(xì)說了，如果有不會(huì)的微信私信我。

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

「bind 配置文件」

bind 配置文件位于 /etc/named.conf，它主要負(fù)責(zé) bind 功能配置，如 zone 路徑、日志、安全、主從等配置

其中最主要的是添加 zone 的配置以及指定 zone 配置文件。recursion 開啟遞歸解析功能， 這個(gè)如果是 no， 那么此 bind 服務(wù)只能做權(quán)威解析服務(wù)，當(dāng)你的 bind 服務(wù)對(duì)外時(shí)，打開它會(huì)有安全風(fēng)險(xiǎn)，如何防御不當(dāng)，會(huì)讓你的 nameserver 被hacker 用來做肉雞

「zone 配置文件」

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

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

「SOA記錄」

SOA 記錄表示此域名的權(quán)威解析服務(wù)器地址。上文講了權(quán)威解析服務(wù)器和遞歸解析服務(wù)器的差別， 當(dāng)所有遞歸解析服務(wù)器中有沒你域名解析的緩存時(shí)，它們就會(huì)回源來請(qǐng)求此域名的SOA記錄，也叫權(quán)威解析記錄

「CNAME」

CNAME 的概念很像別名，它的處理邏輯也如此。一個(gè)server 執(zhí)行resloving 時(shí)，發(fā)現(xiàn) name 是一個(gè) CNAME， 它會(huì)轉(zhuǎn)而查詢這個(gè) CNAME 的A記錄。一般來說，能使用CNAME的地方都可以用A記錄代替， 那么為什么還要發(fā)明 CNAME 這樣一個(gè)東西呢？它是讓多個(gè)域名指向同一個(gè) IP 的一種快捷手段， 這樣當(dāng)最低層的 CNAME 對(duì)應(yīng)的IP換了之后，上層的 CNAME 不用做任何改動(dòng)。就像我們代碼中的硬編碼，我們總會(huì)去掉這些硬編碼，用一個(gè)變量來表示，這樣當(dāng)這個(gè)變量變化時(shí)，我們只需要修改一處

配置完之后可以用 named-checkconf 和 named-checkzone 兩個(gè)命令來check我們的配置文件有沒有問題， 之后就可以啟動(dòng) bind 服務(wù)了：

$> service named start
Redirecting to /bin/systemctl restart  named.service

我們用 netstat -ntlp 來檢查一下服務(wù)是否啟動(dòng):

53 端口已啟動(dòng)，那么我們測(cè)試一下效果， 用 dig 解析一下 www.hello.com 域名，使用127.0.0.1 作為遞歸解析服務(wù)器

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

用 DNS 實(shí)現(xiàn)負(fù)載均衡

一個(gè)域名添加多條A記錄，解析時(shí)使用輪詢的方式返回隨機(jī)一條，流量將會(huì)均勻分類到多個(gè)A記錄。

www     IN      A       1.2.3.4
www     IN      A       1.2.3.5

復(fù)制代碼上面的配置中，我們給 www 域添加了兩條A記錄， 這種做法叫 multi-homed hosts， 它的效果是：當(dāng)我們請(qǐng)求 nameserver 解析 www.hello.com 域名時(shí)，返回的IP會(huì)在兩個(gè)IP中輪轉(zhuǎn)（默認(rèn)行為，有些智能解析 DNS 會(huì)根據(jù) IP 判斷，返回一個(gè)離client近的IP，距離 請(qǐng)搜索 DNS 智能解析）。

其實(shí)每次DNS解析請(qǐng)求時(shí)，nameserver都會(huì)返回全部IP，如上面配置，它會(huì)把1.2.3.4 和1.2.3.5 都返回給client端。那么它是怎么實(shí)現(xiàn)RR的呢？nameserver 只是每次返回的IP排序不同，客戶端會(huì)把response里的第一個(gè)IP用來發(fā)請(qǐng)求。

「DNS負(fù)載均衡 vs LVS專業(yè)負(fù)載均衡」

和 LVS 這種專業(yè)負(fù)載均衡工具相比，在DNS層做負(fù)載均衡有以下特點(diǎn):

• 實(shí)現(xiàn)非常簡單

• 默認(rèn)只能通過RR方式調(diào)度

• DNS 對(duì)后端服務(wù)不具備健康檢查

• DNS 故障恢復(fù)時(shí)間比較長（DNS 服務(wù)之間有緩存）

• 可負(fù)載的 rs 數(shù)量有限（受 DNS response 包大小限制)

真實(shí)場景中，還需要根據(jù)需求選擇相應(yīng)的負(fù)載均衡策略

子域授權(quán)

我們從 .com 域下申請(qǐng)一個(gè)二級(jí)域名 hello.com 后， 發(fā)展到某一天我們的公司擴(kuò)大了，需要拆分兩個(gè)事業(yè)部A和B， 并且公司給他們都分配了三級(jí)域名  a.hello.com 和 b.hello.com， 域名結(jié)構(gòu)如下圖：

再發(fā)展一段時(shí)間，A部門和B部門內(nèi)部業(yè)務(wù)太多，需要頻繁的為新產(chǎn)品申請(qǐng)域名， 這個(gè)時(shí)候他們就想搭建自己的 namserver，并且需要上一級(jí)把相應(yīng)的域名管理權(quán)交給自己，他們期望的結(jié)構(gòu)如下：

注意第一階段和第二階段的區(qū)別：第一階段，A 部門想申請(qǐng) a.hello.com 下的子域名，需要向上級(jí)申請(qǐng)，整個(gè) a.hello.com 域的管理都在總公司；第二階段，A 部門先自己搭建 nameserver，然后總公司把 a.hello.com 域管理權(quán)轉(zhuǎn)交給自建的 nameserver， 這個(gè)轉(zhuǎn)交管理權(quán)的行為，就叫子域授權(quán)

子域授權(quán)分兩部操作:

• A部門自建 nameserver，并且在 zone 配置文件中指定 a.hello.com 的權(quán)威解析服務(wù)器為自己的 nameserver 地址

• 總公司在 nameserver 上增加一條 NS 記錄， 把 a.hello.com 域授權(quán)給 A 部門的 nameserver

第一步我們?cè)谟?bind 搭建域名解析服務(wù)器里講過， 只要在 zone 配置文件里指定SOA記錄就好:

@       IN     SOA      ns.a.hello.com    admin.a.hello.com. (……)

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

a.hello.com      IN       NS       ns.a.hello.com
ns.a.hello.com      IN      A        xx.xx.xx.xx (自建nameserver的IP)

這樣當(dāng)解析xx.a.hello.com 域名時(shí)， hello.com nameserver 發(fā)現(xiàn)配置中有NS記錄，就會(huì)繼續(xù)遞歸向下解析

DNS 調(diào)試工具

OPS 常用的 DNS 調(diào)試工具有:  host,  nslookup,  dig

這三個(gè)命令都屬于 bind-utils 包， 也就是bind工具集， 它們的使用復(fù)雜度、功能 依次遞增。關(guān)于它們的使用， man 手冊(cè)和網(wǎng)上有太多教程，這里簡單分析一下 dig 命令的輸出吧：

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

其他

「DNS 放大攻擊」

DNS 放大攻擊屬于 DoS 攻擊的一種，是通過大量流量占滿目標(biāo)機(jī)帶寬， 使得目標(biāo)機(jī)對(duì)正常用戶的請(qǐng)求拒絕連接從而掛掉。

「思路」

正常的流量攻擊，hack 機(jī)向目標(biāo)機(jī)建立大量 request-response,  但這樣存在的問題是需要大量的 hack 機(jī)器。因?yàn)榉?wù)器一般的帶寬遠(yuǎn)大于家用網(wǎng)絡(luò)， 如果我們自己的家用機(jī)用來做 hack 機(jī)器，還沒等目標(biāo)機(jī)的帶寬占滿，我們的帶寬早超載了。

「原理」

DNS 遞歸解析的流程比較特殊， 我們可以通過幾個(gè)字節(jié)的 query 請(qǐng)求，換來幾百甚至幾千字節(jié)的 resolving 應(yīng)答（流量放大）， 并且大部分服務(wù)器不會(huì)對(duì) DNS 服務(wù)器做防御。那么hacker 們只要可以偽裝 DNS query 包的 source IP, 從而讓 DNS 服務(wù)器發(fā)送大量的 response到目標(biāo)機(jī)，就可以實(shí)現(xiàn) DoS 攻擊。

但一般常用的 DNS 服務(wù)器都會(huì)對(duì)攻擊請(qǐng)求做過濾，所以找 DNS 服務(wù)器漏洞也是一個(gè)問題。