試想一個問題，我們?nèi)祟惪梢杂卸嗌俜N識別自己的方式？可以通過身份證來識別，可以通過社保卡號來識別，也可以通過駕駛證來識別，盡管有多種識別方式，但在特定的環(huán)境下，某種識別方法會比其他方法更為適合。因特網(wǎng)上的主機和人類一樣，可以使用多種方式進(jìn)行標(biāo)識。互聯(lián)網(wǎng)上主機的一種標(biāo)識方法是使用它的主機名，比如 www.baidu.com、www.google.com 等。這是我們?nèi)祟惲?xí)慣的記憶方式，因特網(wǎng)中的主機卻不會這么記憶，它們喜歡定長的、有層次結(jié)構(gòu)的 IP 地址。

那么路由器如何把 IP 地址解析為我們熟悉的網(wǎng)址呢？這時候就需要 DNS 出現(xiàn)了。

圖 7-1

DNS 的全稱是 Domain Name Systems，它是一個由分層的DNS 服務(wù)器（DNS server）實現(xiàn)的分布式數(shù)據(jù)庫；它還是一個使得主機能夠查詢分布式數(shù)據(jù)庫的應(yīng)用層協(xié)議。DNS 協(xié)議運行在 UDP 協(xié)議上，使用 53 端口。

DNS 基本概述

與 HTTP、FTP 和 SMTP 一樣，DNS 協(xié)議也是一種應(yīng)用層的協(xié)議，DNS 使用客戶-服務(wù)器模式運行在通信的端系統(tǒng)之間，在通信的端系統(tǒng)之間通過 UDP 運輸層協(xié)議來傳送 DNS 報文。

DNS 通常不是一門獨立的協(xié)議，它通常為其他應(yīng)用層協(xié)議所使用，這些協(xié)議包括 HTTP、SMTP 和 FTP，將用戶提供的主機名解析為 IP 地址。

下面根據(jù)一個示例來描述一下 DNS 解析過程：

你在瀏覽器鍵入 www.someschool.edu/index.html 時會發(fā)生什么？為了使用戶主機能夠?qū)⒁粋€ HTTP 請求報文發(fā)送到 Web 服務(wù)器 www.someschool.edu ，會經(jīng)歷如下操作：

同一臺用戶主機上運行著 DNS 應(yīng)用的客戶端。

瀏覽器從上述 URL 中抽取出主機名 www.someschool.edu ，將這臺主機名傳給 DNS 應(yīng)用的客戶端。

DNS 客戶端向 DNS 服務(wù)器發(fā)送一個包含主機名的請求，請求 DNS 服務(wù)器解析這個主機名的 IP 地址。

DNS 客戶端最終會收到一份回答報文，其中包含該目標(biāo)主機的 IP 地址。

一旦瀏覽器收到目標(biāo)主機的 IP 地址后，它就能夠向位于該 IP 地址 80 端口的 HTTP 服務(wù)器進(jìn)程發(fā)起一個 TCP 連接。

除了提供 IP 地址到主機名的轉(zhuǎn)換，DNS 還提供了下面幾種重要的服務(wù)：

主機別名(host aliasing)，有著復(fù)雜主機名的主機能夠擁有一個或多個其他別名，比如說一臺名為 relay1.west-coast.enterprise.com 的主機，同時會擁有 enterprise.com 和 www.enterprise.com 的兩個主機別名，在這種情況下，relay1.west-coast.enterprise.com 也稱為規(guī)范主機名，而主機別名要比規(guī)范主機名更加容易記憶。應(yīng)用程序可以調(diào)用 DNS 來獲得主機別名對應(yīng)的規(guī)范主機名以及主機的 IP地址。

郵件服務(wù)器別名(mail server aliasing)，同樣的，電子郵件的應(yīng)用程序也可以調(diào)用 DNS 對提供的主機名進(jìn)行解析。

負(fù)載分配(load distribution)，DNS 也用于冗余的服務(wù)器之間進(jìn)行負(fù)載分配，這種負(fù)載又叫做內(nèi)部負(fù)載。繁忙的站點例如 cn com 被冗余分布在多臺服務(wù)器上，每臺服務(wù)器運行在不同的端系統(tǒng)，每個都有著不同的 IP 地址。由于這些冗余的 Web 服務(wù)器，一個 IP 地址集合因此與同一個規(guī)范主機名聯(lián)系。DNS 數(shù)據(jù)庫中存儲著這些 IP 地址的集合。由于客戶端每次都會發(fā)起 HTTP 請求，所以 DNS 就會在所有這些冗余的 Web 服務(wù)器之間循環(huán)分配了負(fù)載。

還有一種負(fù)載是全局負(fù)載，全局負(fù)載一般部署在多個機房之間，每個機房都會有自己的 IP 地址，當(dāng)用戶訪問某個域名時，會在這些 IP 之間進(jìn)行輪詢，如果某個數(shù)據(jù)中心掛了，就會將對應(yīng)的 IP 地址刪除，比如某個 DNS 客戶端會輪詢訪問北京和上海的機房，一個掛了會直接使用另外一個，這就是全局負(fù)載的概念。

DNS 工作機制

假設(shè)運行在用戶主機上的某些應(yīng)用程序（如 Web 瀏覽器或郵件閱讀器） 需要將主機名轉(zhuǎn)換為 IP 地址。這些應(yīng)用程序?qū)⒄{(diào)用 DNS 的客戶端，并指明需要被轉(zhuǎn)換的主機名。DSN 客戶端收到 DNS 后，會使用 UDP 通過 53 端口向網(wǎng)絡(luò)上發(fā)送一個 DNS 查詢報文，經(jīng)過一段時間后，DNS 客戶端會收到一個主機名對應(yīng)的 DNS 應(yīng)答報文。因此，從用戶主機的角度來看，DNS 就像是一個黑盒子，其內(nèi)部的操作你無法看到。但是實際上，實現(xiàn) DNS 這個服務(wù)的黑盒子非常復(fù)雜，它由分布于全球的大量 DNS 服務(wù)器以及定義了 DNS 服務(wù)器與查詢主機通信方式的應(yīng)用層協(xié)議組成。

DNS 最早的設(shè)計是只有一臺 DNS 服務(wù)器。這臺服務(wù)器會包含所有的 DNS 映射。這是一種集中式單點設(shè)計，這種設(shè)計并不適用于當(dāng)今的互聯(lián)網(wǎng)，因為互聯(lián)網(wǎng)有著數(shù)量巨大并且持續(xù)增長的主機，這種集中式的設(shè)計會存在以下幾個問題

單點故障(a single point of failure)，單點通常上只有一臺 DNS 服務(wù)器，如果 DNS 服務(wù)器崩潰，那么整個網(wǎng)絡(luò)隨之癱瘓。

通信容量(traaffic volume)，單個 DNS 服務(wù)器不得不處理所有的 DNS 查詢，這種查詢級別可能是上百萬上千萬級。

遠(yuǎn)距離集中式數(shù)據(jù)庫(distant centralized database)，單個 DNS 服務(wù)器不可能靠近所有的用戶，假設(shè)在美國的 DNS 服務(wù)器不可能臨近讓澳大利亞的查詢使用，其中查詢請求勢必會經(jīng)過低速和擁堵的鏈路，造成嚴(yán)重的時延。

維護(hù)(maintenance)，維護(hù)成本巨大，而且還需要頻繁更新。

所以 DNS 不可能集中式設(shè)計，因為集中式設(shè)計完全沒有可擴(kuò)展能力，因此采用分布式設(shè)計，這種設(shè)計的特點如下。

分布式、層次數(shù)據(jù)庫

分布式設(shè)計首先解決的問題就是 DNS 服務(wù)器的擴(kuò)展性問題。因此 DNS 使用了大量的 DNS 服務(wù)器，它們的組織模式一般是層次方式，并且分布在全世界范圍內(nèi)。沒有一臺 DNS 服務(wù)器能夠擁有因特網(wǎng)上所有主機的映射。相反，這些映射分布在所有的 DNS 服務(wù)器上。

大致來說有三種 DNS 服務(wù)器：根 DNS 服務(wù)器、 頂級域(Top-Level Domain, TLD) DNS 服務(wù)器和權(quán)威 DNS 服務(wù)器。這些服務(wù)器的層次模型如下圖所示。

圖 7-2

假設(shè)現(xiàn)在一個 DNS 客戶端想要知道 www.amazon.com 的 IP 地址，那么上面的域名服務(wù)器是如何解析的呢？

首先，客戶端會先根服務(wù)器之一進(jìn)行關(guān)聯(lián)，它將返回頂級域名 com 的 TLD 服務(wù)器的 IP 地址。然后客戶端與這些 TLD 服務(wù)器之一聯(lián)系，它將為 amazon.com 返回權(quán)威服務(wù)器的 IP 地址。最后，該客戶與 amazom.com 權(quán)威服務(wù)器之一聯(lián)系，它為 www.amazom.com 返回其 IP 地址。

DNS 層次結(jié)構(gòu)

我們現(xiàn)在來討論一下上面域名服務(wù)器的層次系統(tǒng)。

根 DNS 服務(wù)器 ，有 400 多個根域名服務(wù)器遍及全世界，這些根域名服務(wù)器由 13 個不同的組織管理。根域名服務(wù)器的清單和組織機構(gòu)可以在 https://root-servers.org/ 中找到，根域名服務(wù)器提供 TLD 服務(wù)器的 IP 地址。

頂級域 DNS 服務(wù)器，對于每個頂級域名比如 com、org、net、edu 和 gov 和所有的國家級域名 uk、fr、ca 和 jp 都有 TLD 服務(wù)器或服務(wù)器集群。所有的頂級域列表參見 https://tld-list.com/ 。TDL 服務(wù)器提供了權(quán)威 DNS 服務(wù)器的 IP 地址。

權(quán)威 DNS 服務(wù)器，在因特網(wǎng)上具有公共可訪問的主機，如 Web 服務(wù)器和郵件服務(wù)器，這些主機的組織機構(gòu)必須提供可供訪問的 DNS 記錄，這些記錄將這些主機的名字映射為 IP 地址。一個組織機構(gòu)的權(quán)威 DNS 服務(wù)器收藏了這些 DNS 記錄。

DNS 查詢步驟

下面我們來描述一下 DNS 的查詢步驟，從 DNS 解析 IP 再到 DNS 報文返回的一系列流程。

注意：通常情況下 DNS 會將查找的信息緩存在瀏覽器或者計算機本地中，如果有相同的請求到來時，就不再會進(jìn)行 DNS 查找，而會直接返回結(jié)果。

通常情況下，DNS 的查找會經(jīng)歷下面這些步驟

用戶在瀏覽器中輸入網(wǎng)址 www.example.com 并點擊回車后，查詢會進(jìn)入網(wǎng)絡(luò)，并且由 DNS 解析器進(jìn)行接收。

DNS 解析器會向根域名發(fā)起查詢請求，要求返回頂級域名的地址。

根 DNS 服務(wù)器會注意到請求地址的前綴并向 DNS 解析器返回 com 的頂級域名服務(wù)器(TLD)的 IP 地址列表。

然后，DNS 解析器會向 TLD 服務(wù)器發(fā)送查詢報文。

TLD 服務(wù)器接收請求后，會根據(jù)域名的地址把權(quán)威 DNS 服務(wù)器的 IP 地址返回給 DNS 解析器。

最后，DNS 解析器將查詢直接發(fā)送到權(quán)威 DNS 服務(wù)器。

權(quán)威 DNS 服務(wù)器將 IP 地址返回給 DNS 解析器。

DNS 解析器將會使用 IP 地址響應(yīng) Web 瀏覽器。

一旦 DNS 查找的步驟返回了 example.com 的 IP 地址，瀏覽器就可以請求網(wǎng)頁了。

整個流程如下圖所示

圖 7-3

DNS 解析器

進(jìn)行 DNS 查詢的主機和軟件叫做 DNS 解析器，用戶所使用的工作站和個人電腦都屬于解析器。一個解析器要至少注冊一個以上域名服務(wù)器的 IP 地址。DNS 解析器是 DNS 查找的第一站，其負(fù)責(zé)與發(fā)出初始請求的客戶端打交道。解析器啟動查詢序列，最終使 URL 轉(zhuǎn)換為必要的 IP 地址。

圖 7-4

DNS 遞歸查詢和 DNS 遞歸解析器不同，該查詢是指向需要解析該查詢的 DNS 解析器發(fā)出請求。DNS 遞歸解析器是一種計算機，其接受遞歸查詢并通過發(fā)出必要的請求來處理響應(yīng)。

DNS 查詢類型

DNS 查找中會出現(xiàn)三種類型的查詢。通過組合使用這些查詢，優(yōu)化的 DNS 解析過程可縮短傳輸距離。在理想情況下，可以使用緩存的記錄數(shù)據(jù)，從而使 DNS 域名服務(wù)器能夠直接使用非遞歸查詢。

遞歸查詢：在遞歸查詢中，DNS 客戶端要求 DNS 服務(wù)器（一般為 DNS 遞歸解析器）將使用所請求的資源記錄響應(yīng)客戶端，或者如果解析器無法找到該記錄，則返回錯誤消息。

圖 7-5

迭代查詢：在迭代查詢中，如果所查詢的 DNS 服務(wù)器與查詢名稱不匹配，則其將返回對較低級別域名空間具有權(quán)威性的 DNS 服務(wù)器的引用。然后，DNS 客戶端將對引用地址進(jìn)行查詢。此過程繼續(xù)使用查詢鏈中的其他 DNS 服務(wù)器，直至發(fā)生錯誤或超時為止。

圖 7-6

非遞歸查詢：當(dāng) DNS 解析器客戶端查詢 DNS 服務(wù)器以獲取其有權(quán)訪問的記錄時通常會進(jìn)行此查詢，因為其對該記錄具有權(quán)威性，或者該記錄存在于其緩存內(nèi)。DNS 服務(wù)器通常會緩存 DNS 記錄，查詢到來后能夠直接返回緩存結(jié)果，以防止更多帶寬消耗和上游服務(wù)器上的負(fù)載。

DNS 緩存

DNS 緩存(DNS caching) 有時也叫做DNS 解析器緩存，它是由操作系統(tǒng)維護(hù)的臨時數(shù)據(jù)庫，它包含有最近的網(wǎng)站和其他 Internet 域的訪問記錄。也就是說， DNS 緩存只是計算機為了滿足快速的響應(yīng)速度而把已加載過的資源緩存起來，再次訪問時可以直接快速引用的一項技術(shù)和手段。那么 DNS 的緩存是如何工作的呢？

DNS 緩存的工作流程

在瀏覽器向外部發(fā)出請求之前，計算機會攔截每個請求并在 DNS 緩存數(shù)據(jù)庫中查找域名，該數(shù)據(jù)庫包含有最近的域名列表，以及 DNS 首次發(fā)出請求時 DNS 為它們計算的地址。

DNS 緩存方式

DNS 數(shù)據(jù)可緩存到各種不同的位置上，每個位置均將存儲 DNS 記錄，它的生存時間由 TTL(DNS 字段) 來決定。

瀏覽器緩存

現(xiàn)如今的 Web 瀏覽器設(shè)計默認(rèn)將 DNS 記錄緩存一段時間。因為越靠近 Web 瀏覽器進(jìn)行 DNS 緩存，為檢查緩存并向 IP 地址發(fā)出請求的次數(shù)就越少。發(fā)出對 DNS 記錄的請求時，瀏覽器緩存是針對所請求的記錄而檢查的第一個位置。

在 chrome 瀏覽器中，你可以使用 chrome://net-internals/#dns 查看 DNS 緩存的記錄。

圖 7-7

操作系統(tǒng)內(nèi)核緩存

在瀏覽器緩存查詢后，會進(jìn)行操作系統(tǒng)級 DNS 解析器的查詢，操作系統(tǒng)級 DNS 解析器是 DNS 查詢離開你的計算機前的第二站，也是本地查詢的最后一個步驟。

DNS 報文

共同實現(xiàn) DNS 分布式數(shù)據(jù)庫的所有 DNS 服務(wù)器存儲了*資源記錄(Resource Record, RR)*，RR 提供了主機名到 IP 地址的映射。每個 DNS 回答報文中會包含一條或多條資源記錄。RR 記錄用于回復(fù)客戶端查詢。

資源記錄是一個包含了下列字段的 4 元組。

(Name,Value,Type,TTL)

RR 會有不同的類型，下面是不同類型的 RR 匯總表。

DNS RR 類型	解釋
A 記錄	IPv4 主機記錄，用于將域名映射到 IPv4 地址
AAAA 記錄	IPv6 主機記錄，用于將域名映射到 IPv6 地址
CNAME 記錄	別名記錄，用于映射 DNS 域名的別名
MX 記錄	郵件交換器，用于將 DNS 域名映射到郵件服務(wù)器
PTR 記錄	指針，用于反向查找（IP地址到域名解析）
SRV 記錄	SRV記錄，用于映射可用服務(wù)。

表 7-1

DNS 有兩種報文，一種是查詢報文，一種是響應(yīng)報文，并且這兩種報文有著相同的格式，下面是 DNS 的報文格式。

圖 7-8

下面我們就來看一下詳細(xì)的報文字段。

報文段首部

報文段首部是 DNS 報文的基礎(chǔ)結(jié)構(gòu)部分，下面我們對報文段首部中的每個字節(jié)進(jìn)行描述。

事務(wù) ID: TransactionID 由客戶端設(shè)置，由服務(wù)器返回。TransactionID 占用 2 個字節(jié)。它是 DNS 的標(biāo)識，對于同一個請求報文和響應(yīng)報文來說，這個字段的值是相同的，以此來區(qū)分客戶端請求和響應(yīng)。

標(biāo)志：標(biāo)志字段占用 2 個字節(jié)。標(biāo)志字段有很多，而且也比較重要，下面我給你列出來了所有的標(biāo)志字段。

圖 7-9

每個字段的含義如下

QR(Response): 1 bit 的 QR 標(biāo)識報文是查詢報文還是響應(yīng)報文，查詢報文時 QR = 0，響應(yīng)報文時 QR = 1。

OpCode: 4 bit 的 OpCode 表示操作碼，這個值通常是 0 ，代表標(biāo)準(zhǔn)的請求和響應(yīng)。OpCode = 4 表示這是一個通知；OpCode = 5 表示這是一個更新請求。而其他值（1-3）是被棄用的。

AA(Authoritative): 1 bit 的 AA 代表授權(quán)應(yīng)答，這個 AA 只在響應(yīng)報文中有效，值為 1 時，表示名稱服務(wù)器是權(quán)威服務(wù)器；值為 0 時，表示不是權(quán)威服務(wù)器。

TC(Truncated): 截斷標(biāo)志位，值為 1 時，表示響應(yīng)已超過 512 字節(jié)并且已經(jīng)被截斷，只返回前 512 個字節(jié)。

RD(Recursion Desired): 這個字段是期望遞歸字段，該字段在查詢中設(shè)置，并在響應(yīng)中返回。該標(biāo)志告訴名稱服務(wù)器必須處理這個查詢，這種方式被稱為一個遞歸查詢。如果該位為 0，且被請求的名稱服務(wù)器沒有一個授權(quán)回答，它將返回一個能解答該查詢的其他名稱服務(wù)器列表。這種方式被稱為迭代查詢。

RA(Recursion Available): 可用遞歸字段，這個字段只出現(xiàn)在響應(yīng)報文中。當(dāng)值為 1 時，表示服務(wù)器支持遞歸查詢。

Z: 保留字段，在所有的請求和應(yīng)答報文中，它的值必須為 0。

AD: 這個字段表示信息是否是已授權(quán)，已授權(quán)就是 true。

CD: 這個字段表示是否禁用安全檢查，禁用檢查就是 true。

rcode（Reply code）：這個字段是返回碼字段，表示響應(yīng)的差錯狀態(tài)。當(dāng)值為 0 時，表示沒有錯誤；當(dāng)值為 1 時，表示報文格式錯誤（Format error），服務(wù)器不能理解請求的報文；當(dāng)值為 2 時，表示域名服務(wù)器失敗（Server failure），因為服務(wù)器的原因?qū)е聸]辦法處理這個請求；當(dāng)值為 3 時，表示名字錯誤（Name Error），只有對授權(quán)域名解析服務(wù)器有意義，指出解析的域名不存在；當(dāng)值為 4 時，表示查詢類型不支持（Not Implemented），即域名服務(wù)器不支持查詢類型；當(dāng)值為 5 時，表示拒絕（Refused），一般是服務(wù)器由于設(shè)置的策略拒絕給出應(yīng)答，如服務(wù)器不希望對某些請求者給出應(yīng)答。

相信讀者跟我一樣，只看這些字段沒什么意思，下面我們就通過抓包的方式，看一下具體的 DNS 報文。

圖 7-10

現(xiàn)在我們可以看一下具體的 DNS 報文，通過 query 可知這是一個請求報文，這個報文的標(biāo)識符是 0xcd28，它的標(biāo)志如下。

QR = 0 實錘了這就是一個請求。

然后是四個字節(jié)的 OpCode，它的值是 0，表示這是一個標(biāo)準(zhǔn)查詢。

因為這是一個查詢請求，所以沒有 AA 字段出現(xiàn)。

然后是截斷標(biāo)志位 Truncated，表示沒有被截斷。

緊隨其后的 RD = 1，表示希望得到遞歸回答。

請求報文中沒有 RA 字段出現(xiàn)。

然后是保留字段 Z。

緊隨其后的 0 表示未經(jīng)身份驗證的數(shù)據(jù)是不可接受的。

沒有 RCODE 字段的值。

然后我們看一下響應(yīng)報文。

圖 7-11

可以看到，標(biāo)志位也是 0xcd28，可以說明這就是上面查詢請求的響應(yīng)。

查詢請求已經(jīng)解釋過的報文我們這里就不再說明了，現(xiàn)在只解釋一下請求報文中沒有的內(nèi)容。

緊隨在 OpCode 后面的 AA 字段已經(jīng)出現(xiàn)了，它的值為 0 ，表示不是權(quán)威 DNS 服務(wù)器的響應(yīng)。

最后是 RCODE 字段的響應(yīng)，值為 0 時，表示沒有錯誤。

查詢區(qū)

查詢區(qū)通常指報文格式中查詢的部分。這部分用來顯示 DNS 查詢請求的問題，包括查詢類型和查詢類。

圖 7-12

這部分中每個字段的含義如下：

查詢名（Query Name）：指定要查詢的域名，有時候也是 IP 地址，用于反向查詢。

查詢類型（Query Type）：DNS 查詢請求的資源類型，通常查詢類型為 A 類型，表示由域名獲取對應(yīng)的 IP 地址。

查詢類（Query Class）：地址類型，通常為互聯(lián)網(wǎng)地址，值為 1 。這個查詢類的值通常是 1、254 和 255，分別表示互聯(lián)網(wǎng)類、沒有此類和所有類。

同樣的，我們再使用 wireshark 查看一下查詢區(qū)域。

圖 7-13

可以看到，這是對 mobile-gtalk.l.google.com 發(fā)起的 DNS 查詢請求，查詢類型是 A（0x0001），那么得到的響應(yīng)類型應(yīng)該也是 A ，A 表示的是 IPv4 類型，如果 Type 是 AAAA，那么就表示的是 IPv6 類型。

圖 7-14

如上圖所示，響應(yīng)類型也是 A。

資源記錄部分

資源記錄部分是 DNS 報文的最后三個字段，包括回答問題區(qū)域、權(quán)威名稱服務(wù)器記錄、附加信息區(qū)域，這三個字段均采用一種稱為資源記錄的格式，如下圖所示。

圖 7-15

資源記錄部分的字段含義如下

Name：DNS 請求的域名。

Type：資源記錄的類型，與查詢部分中的查詢類型是一樣的。

Class：地址類型、與問題中的查詢類值一樣的。

TTL：以秒為單位，表示資源記錄的生命周期。

RDLENGTH（資源數(shù)據(jù)長度）：資源數(shù)據(jù)的長度。

RDATA（資源數(shù)據(jù)）：表示按查詢段要求返回的相關(guān)資源記錄的數(shù)據(jù)。

資源記錄部分只有在 DNS 響應(yīng)包中才會出現(xiàn)。下面我們就來通過響應(yīng)報文看一下具體的字段示例。

圖 7-16

其中，域名的值是 mobile-gtalk.l.google.com ，類型是 A，類是 1，生存時間是 5 秒，數(shù)據(jù)長度是 4 字節(jié)，資源數(shù)據(jù)表示的地址是 63.233.189.188。

CNAME 記錄

CNAME 是 DNS 的一種記錄類型，它的全稱是 Canonical Name Record，這個類型能夠?qū)⒛承?DNS 別名映射到 DNS 命名系統(tǒng)中。

一個很簡單的例子，如下所示

www.cxuanblog.edu IN CNAME www.cxuanblog.com

這是啥意思呢？

這表示的是如果用戶在瀏覽器中輸入的是 www.cxuanblog.edu 這個域名，其實輸入的是 www.cxuanblog.com 這個域名，如果你打算把博客搬家后，你輸入的舊域名其實會直接跳轉(zhuǎn)到新域名的網(wǎng)頁下。

CNAME 還有一種普遍的做法就是把它作為公共域名進(jìn)行訪問。

反向 DNS 查詢

我們上面一直討論的是 DNS -> IP 的這種轉(zhuǎn)換方式，這種方式也是 DNS 的精髓所在。但是如果你認(rèn)真看了圖 7 - 1 的話，你會發(fā)現(xiàn)還存在一種 IP -> DNS 的轉(zhuǎn)換方式，這種反向的轉(zhuǎn)換也被叫做反向 DNS 查詢。他們之間的關(guān)系很像 ARP 和 RARP 。

反向 DNS 查詢向 DNS 服務(wù)器查詢 PTR（Pointer Record）記錄，如果服務(wù)器沒有 PTR 記錄，則無法解析反向查找這個過程。PTR 也是一種 RR 資源記錄，見表 7 - 1。

PTR 記錄會存儲 IP 地址，反向查詢時，PTR 中存儲的 IP 地址會顛倒過來，并附上 .in-addr.arpa 字段，比如如果域的 IP 地址為 192.137.8.22，那么反向查詢時，PTR 記錄就是 22.8.137.192.in-addr.arpa 。

反向 DNS 查詢通常用于電子郵件協(xié)議中，電子郵件服務(wù)器會檢查電子郵箱中的電子郵件消息是否來自真實有效的服務(wù)器，垃圾郵件發(fā)送者經(jīng)常使用被劫持機器的，這些郵件過來后就不會有 PTR 記錄。電子郵件服務(wù)器會拒絕不支持反向查找的服務(wù)器或者不太合法的服務(wù)器郵件。

SOA 記錄

如果是權(quán)威 DNS 服務(wù)器的響應(yīng)的話，會顯示記錄存儲有關(guān)區(qū)域的重要信息，這種信息就是 SOA 記錄。所有的 DNS 區(qū)域都需要一個 SOA 記錄才能符合 IETF 標(biāo)準(zhǔn)。SOA 記錄對于區(qū)域傳輸也很重要。

SOA 記錄除具有 DNS 解析器響應(yīng)的字段外，還具有一些額外的字段，如下

圖 7-17

具體字段含義

PNAME：即 Primary Name Server，這是區(qū)域的主要名稱服務(wù)器的名稱。

RNAME：即 Responsible authority's mailbox，RNAME 代表管理員的電子郵件地址，@ 用 . 來表示，也就是說 admin.example.com 等同于 admin@example.com。

序列號：即 Serial Number ，區(qū)域序列號是該區(qū)域的唯一標(biāo)識符。

刷新間隔：即 Refresh Interval，在請求主服務(wù)器提供 SOA 記錄以查看其是否已更新之前，輔助服務(wù)器應(yīng)等待的時間（以秒為單位）。

重試間隔：即 Retry Interval ，服務(wù)器應(yīng)等待無響應(yīng)的主要名稱服務(wù)器再次請求更新的時間。

過期限制：即 Expire limit ，如果輔助服務(wù)器在這段時間內(nèi)沒有收到主服務(wù)器的響應(yīng)，則應(yīng)停止響應(yīng)對該區(qū)域的查詢。

上面提到了主要名稱服務(wù)器和輔助名稱服務(wù)器，他們之間的關(guān)系如下。

圖 7-18

這塊我們主要解釋了 RR 類型為 A（IPv4） 和 SOA 的記錄，除此之外還有很多類型，這篇文章就不再詳細(xì)介紹了，讀者朋友們可以閱讀 《TCP/IP 卷一 協(xié)議》和 cloudflare 的官網(wǎng) https://www.cloudflare.com/learning/dns/dns-records/ 查閱，值得一提的是，cloudflare 是一個學(xué)習(xí)網(wǎng)絡(luò)協(xié)議非常好的網(wǎng)站。

區(qū)域傳輸和 DNS NOTIFY

區(qū)域傳輸通常指一塊區(qū)域內(nèi) DNS 服務(wù)器中的 RR 資源更新，這樣做的目的是為了保證多臺服務(wù)器保證內(nèi)容同步。如果區(qū)域中一臺服務(wù)器失效了，那么其他服務(wù)器可以臨時頂上，充當(dāng)臨時 DNS 服務(wù)器的角色。區(qū)域傳輸通常在輪詢（polling）后開啟，在輪詢中，從服務(wù)器會周期性的檢查主服務(wù)器，查看區(qū)域是否已經(jīng)更新，區(qū)域傳輸需要開啟。

一旦啟動區(qū)域傳輸，就會存在兩種傳輸方式：

全量傳輸：即傳輸整個區(qū)域的消息，全量傳輸會傳輸整個區(qū)域（使用 AXFR）的消息。

增量傳輸：增量傳輸就是傳輸一部分消息，增量傳輸使用（使用 DNS IXFR）的消息。

但是使用輪詢這種方式有一些弊端，因為從服務(wù)器會定期檢查主服務(wù)器上內(nèi)容是否更新，這是一種資源浪費，因為絕大多數(shù)情況下都是一次無效檢查，所以為了改善這種情況，DNS 設(shè)計了 DNS NOTIFY 機制，DNS NOTIFY 允許修改區(qū)域內(nèi)容后主服務(wù)器通知從服務(wù)器內(nèi)容需要更新，應(yīng)該啟動區(qū)域傳輸。

DNS 網(wǎng)絡(luò)排查工具

DNS 常用的排查工具有兩種，一種是 nslookup，這是一般書籍中推薦使用的排查工具，下面我們先來介紹一下這個工具的使用，一會兒我們再來介紹另外一種工具。

nslookup

nslookup 是一款用來解決 DNS 相關(guān)問題排查的工具。

它主要分為兩種模式，一種是交互模式，一種是非交互模式。交互模式就是一問一答式的，而非交互模式就是一次執(zhí)行的。

比如你要使用交互式，就直接在命令行中輸入 nslookup。

圖 7-19

這樣就會開始一個 nslookup 的命令提示符，然后你再輸入想要查詢的域名即可，如下所示：

圖 7-20

非交互式就是直接輸入 nslookup 你想要查詢的內(nèi)容即可，比如我們還以 baidu 為例子。

圖 7-21

其實查詢出來的內(nèi)容是一樣的，使用方式其實也大相徑庭。

nslookup 一般用于查詢下面這些常見的場景：

nslookup 能夠查詢主機的 IP 地址；

nslookup 能夠查詢 IP 地址的域名；

nslookup 能夠查詢域名的郵件服務(wù)器。

可以通過 nslookup -querytype 查詢域名的郵件服務(wù)器，如下

圖 7-22

會分為兩種查詢結(jié)果，一種是 Non-authoritative answer，這表明我們想查詢的這個網(wǎng)址是從本地 DNS cache 也就是 DNS 緩存中查詢出來的，而不是從本地 DNS 經(jīng)過 DNS 查詢后得到的真實域名。

還有一種就是 Authoritative answers，這種就是本地 DNS 經(jīng)過 DNS 查詢后得到的真實域名。

上圖還顯示了 netease.com 郵件服務(wù)器的一些參數(shù)，origin 表示源地址，mail addr 表示郵件服務(wù)器的地址，serial 表示序列號，refresh 表示刷新間隔，retry 表示重試間隔，expire 表示過期時間， minumum 表示最大長度。

dig

我們的電腦上有多個網(wǎng)絡(luò)連接，每個網(wǎng)絡(luò)連接會有不同的 DNS ，而且 DNS 也分為主 DNS 和備用 DNS，nslookup 會默認(rèn)使用主 DNS 連接，如果你的主 DNS 沒有配置，使用可能會存在下面這種情況。

圖 7-23

與 nslookup 不同的是，dig 也是一款 DNS 網(wǎng)絡(luò)排查工具，它會從你的網(wǎng)絡(luò)連接中選取一塊可用的連接進(jìn)行解析和使用，不過 windows 10 下默認(rèn)不支持 dig 命令工具的使用，mac 倒是支持。

下面是 mac 下的 dig 命令。

圖 7-24

不過，貼心的我給你整理出來了 windows10 下 dig 的安裝和配置使用 （https://www.csdn.net/tags/Mtjacg0sMjU1ODQtYmxvZwO0O0OO0O0O.html）

安裝完成后，就可以在 windows 10 下使用 dig 了。

圖 7-25

下面我們就來介紹一下 dig 這款工具都用哪些用法以及各個參數(shù)的含義，我們以 dig baidu.com 來進(jìn)行說明

圖 7-26

如上圖所示，最上面的

; <<>> DiG 9.16.23 <<>> www.baidu.com 表示 dig 版本和要查詢的域信息。

;; global options: +cmd 表示全局選項，dig 可以查詢多個域信息，這里顯示應(yīng)用于所有查詢的選項，默認(rèn)是 +cmd。

;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63799 ?這行表示頭信息，其中操作碼 QUERY 表示查詢，IQUERY 表示反查詢，STATUS 表示監(jiān)測狀態(tài)等。

NOERROR 表示這個請求已正常解決，id 是一個隨機數(shù)字，它用于將請求和響應(yīng)綁定在一起。

;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 這一行都是一些標(biāo)志位，其中

qr = query , rd = recursion desired ，ra = recursion avaliable 這里其實 DNS 和我們玩了一個文字游戲，因為 rd 翻譯過來就是需要遞歸，這個沒什么好說的，默認(rèn)就是使用遞歸查詢；而 ra 翻譯過來是遞歸可用，這個需要思考下，遞歸可用我是用還是不用呢？當(dāng)然你可以用也可以不用，如果你不使用遞歸的話，那么 DNS 查詢方式就是迭代查詢。

QUERY 表示查詢數(shù)量，ANSWER 表示結(jié)果數(shù)量

AUTHORITY 表示來自權(quán)威域名服務(wù)器的結(jié)果數(shù)量，為 0 說明是從本地 DNS 中返回的，因為沒有權(quán)威服務(wù)器的返回信息。

ADDITIONAL 表示附加信息，當(dāng)其值大于 1 時才會看到額外信息。

下面是問題區(qū)域

;; QUESTION SECTION:;www.baidu.com. IN A

依次是正在查詢的域名，IN 我們上面提到了它表示互聯(lián)網(wǎng)查詢，A 表示域名映射到 IPv4 地址。

下面是答案部分

;; ANSWER SECTION:www.baidu.com. 183 IN CNAME www.a.shifen.com.www.a.shifen.com. 57 IN A 220.181.38.150www.a.shifen.com. 57 IN A 220.181.38.149

中間的數(shù)字表示 TTL ，即可以緩存記錄的時間間隔。

最后是統(tǒng)計部分，這塊沒什么好說的了。

除此之外，dig 還有一些其他查詢方式。

-x 進(jìn)行反向 DNS 查詢

我們知道，DNS 可以把域名轉(zhuǎn)換為 IP ，同時也可以把 IP 轉(zhuǎn)換成對應(yīng)的域名，其中 -x 就是進(jìn)行反向 DNS 查詢，如下所示：

圖 7-27

可以看到 QUESTION SECTION 和 ANSWER SECTION 中都是 PTR，這表示反向 DNS 查詢，后面的域名顯示了這是一個 google 的 DNS。反向 DNS 查詢中，IP 地址要加上 in-addr.arpa。

同樣的，我們還可以在查詢的時候加上 in-addr.arpa，其結(jié)果是一樣的。

圖 7-28

我們通常喜歡使用 -x，因為這會減少輸入的工作量。

+noall +answer

這告訴 dig 只打印 DNS 響應(yīng)中的ANSWER部分內(nèi)容，如下所示

圖 7-29

+short

dig +short 就像是 dig +noall +answer 的閹割版，它只顯示很少的內(nèi)容。

圖 7-30

+trace

dig +trace 能夠模仿 DNS 解析器在查找域名時的做法 ，即它會從根服務(wù)器開始查詢，一直到權(quán)威 DNS 服務(wù)器。相當(dāng)于鏈路追蹤的一個作用。

圖 7-31

除了我們上面介紹的 nslookup 和 dig 之外，還有其他 DNS 檢測工具，比如 dog 、drill ，都是很好用的 DNS 網(wǎng)絡(luò)排查工具，大家可以查閱相關(guān)資料進(jìn)行使用，這里我就不再進(jìn)行詳細(xì)的介紹了。

DNS 安全

幾乎所有的網(wǎng)絡(luò)請求都會經(jīng)過 DNS 查詢，而且 DNS 和許多其他的 Internet 協(xié)議一樣，系統(tǒng)設(shè)計時并未考慮到安全性，并且存在一些設(shè)計限制，這為 DNS 攻擊創(chuàng)造了機會。

DNS 攻擊主要有下面這幾種方式：

第一種是 Dos 攻擊，這種攻擊的主要形式是使重要的 DNS 服務(wù)器比如 TLD 服務(wù)器或者根域名服務(wù)器過載，從而無法響應(yīng)權(quán)威服務(wù)器的請求，使 DNS 查詢不起作用。

第二種攻擊形式是 DNS 欺騙，通過改變 DNS 資源內(nèi)容，比如偽裝一個官方的 DNS 服務(wù)器，回復(fù)假的資源記錄，從而導(dǎo)致主機在嘗試與另一臺機器連接時，連接至錯誤的 IP 地址。

第三種攻擊形式是 DNS 隧道，這種攻擊使用其他網(wǎng)絡(luò)協(xié)議通過 DNS 查詢和響應(yīng)建立隧道。攻擊者可以使用 SSH、TCP 或者 HTTP 將惡意軟件或者被盜信息傳遞到 DNS 查詢中，這種方式使防火墻無法檢測到，從而形成 DNS 攻擊。

第四種攻擊形式是 DNS 劫持，在 DNS 劫持中，攻擊者將查詢重定向到其他域名服務(wù)器。這可以通過惡意軟件或未經(jīng)授權(quán)的 DNS 服務(wù)器修改來完成。盡管結(jié)果類似于 DNS 欺騙，但這是完全不同的攻擊，因為它的目標(biāo)是名稱服務(wù)器上網(wǎng)站的 DNS 記錄，而不是解析程序的緩存。

第五章攻擊形式是 DDoS 攻擊，也叫做分布式拒絕服務(wù)帶寬洪泛攻擊，這種攻擊形式相當(dāng)于是 Dos 攻擊的升級版

那么該如何防御 DNS 攻擊呢？

防御 DNS 威脅的最廣為人知的方法之一就是采用 DNSSEC 協(xié)議。

DNSSEC

DNSSEC 又叫做 DNS 安全擴(kuò)展，DNSSEC 通過對數(shù)據(jù)進(jìn)行數(shù)字簽名來保護(hù)其有效性，從而防止受到攻擊。它是由 IETF 提供的一系列 DNS 安全認(rèn)證的機制。DNSSEC 不會對數(shù)據(jù)進(jìn)行加密，它只會驗證你所訪問的站點地址是否有效。

DNS 防火墻

有一些攻擊是針對服務(wù)器進(jìn)行的，這就需要 DNS 防火墻的登場了，DNS 防火墻是一種可以為 DNS 服務(wù)器提供許多安全和性能服務(wù)的工具。DNS 防火墻位于用戶的 DNS 解析器和他們嘗試訪問的網(wǎng)站或服務(wù)的權(quán)威名稱服務(wù)器之間。防火墻提供限速訪問，以關(guān)閉試圖淹沒服務(wù)器的攻擊者。如果服務(wù)器確實由于攻擊或任何其他原因而導(dǎo)致停機，則 DNS 防火墻可以通過提供來自緩存的 DNS 響應(yīng)來使操作員的站點或服務(wù)正常運行。

除了上述兩種防御手段外，本身 DNS 區(qū)域的運營商就會采取進(jìn)一步措施保護(hù) DNS 服務(wù)器，比如配置 DNS 基礎(chǔ)架構(gòu)，來防止 DDoS 攻擊。

總結(jié)

這篇文章我用較多的字?jǐn)?shù)為你介紹了 DNS 的基本概述，DNS 的工作機制，DNS 的查詢方式，DNS 的緩存機制，我們還通過 WireShark 抓包帶你認(rèn)識了一下 DNS 的報文，最后我為你介紹了 DNS 的攻擊手段和防御方式。

這是一篇入門 DNS 較全的文章，花了我一周多的時間來寫這篇文章，這篇文章了解清楚后，基本上 DNS 的大部分問題你應(yīng)該都能夠回答，面試我估計也穩(wěn)了。

審核編輯 ：李倩