技術文章 » 這篇 DNS ，寫的挺水的。

這篇 DNS ，寫的挺水的。

2022-05-27 12:01:13

試想一個問題，我們人類可以有多少種識別自己的方式？可以通過身份證來識別，可以通過社保卡號來識別，也可以通過駕駛證來識別，儘管有多種識別方式，但在特定的環境下，某種識別方法會比其他方法更為適合。因特網上的主機和人類一樣，可以使用多種方式進行標識。網際網路上主機的一種標識方法是使用它的主機名，比如 www.baidu.com、www.google.com 等。這是我們人類習慣的記憶方式，因特網中的主機卻不會這麼記憶，它們喜歡定長的、有層次結構的 IP 地址。

那麼路由器如何把 IP 地址解析為我們熟悉的網址呢？這時候就需要 DNS 出現了。

圖 7-1

DNS 的全稱是 Domain Name Systems，它是一個由分層的DNS 伺服器（DNS server）實現的分散式資料庫；它還是一個使得主機能夠查詢分散式資料庫的應用層協定。DNS 協定執行在 UDP 協定上，使用 53 埠。

DNS 基本概述

與 HTTP、FTP 和 SMTP 一樣，DNS 協定也是一種應用層的協定，DNS 使用客戶-伺服器模式執行在通訊的端系統之間，在通訊的端系統之間通過 UDP 運輸層協定來傳送 DNS 報文。

DNS 通常不是一門獨立的協定，它通常為其他應用層協定所使用，這些協定包括 HTTP、SMTP 和 FTP，將使用者提供的主機名解析為 IP 地址。

下面根據一個範例來描述一下 DNS 解析過程：

你在瀏覽器鍵入 www.someschool.edu/index.html 時會發生什麼？為了使使用者主機能夠將一個 HTTP 請求報文傳送到 Web 伺服器 www.someschool.edu ，會經歷如下操作：

  • 同一臺使用者主機上執行著 DNS 應用的使用者端。
  • 瀏覽器從上述 URL 中抽取出主機名 www.someschool.edu ，將這臺主機名傳給 DNS 應用的使用者端。
  • DNS 使用者端向 DNS 伺服器傳送一個包含主機名的請求，請求 DNS 伺服器解析這個主機名的 IP 地址。
  • DNS 使用者端最終會收到一份回答報文，其中包含該目標主機的 IP 地址。
  • 一旦瀏覽器收到目標主機的 IP 地址後，它就能夠向位於該 IP 地址 80 埠的 HTTP 伺服器程序發起一個 TCP 連線。

除了提供 IP 地址到主機名的轉換，DNS 還提供了下面幾種重要的服務：

  • 主機別名(host aliasing)，有著複雜主機名的主機能夠擁有一個或多個其他別名，比如說一臺名為 relay1.west-coast.enterprise.com 的主機，同時會擁有 enterprise.com 和 www.enterprise.com 的兩個主機別名，在這種情況下，relay1.west-coast.enterprise.com 也稱為規範主機名，而主機別名要比規範主機名更加容易記憶。應用程式可以呼叫 DNS 來獲得主機別名對應的規範主機名以及主機的 IP地址。

  • 郵件伺服器別名(mail server aliasing)，同樣的，電子郵件的應用程式也可以呼叫 DNS 對提供的主機名進行解析。

  • 負載分配(load distribution)，DNS 也用於冗餘的伺服器之間進行負載分配，這種負載又叫做內部負載。繁忙的站點例如 cn com 被冗餘分佈在多臺伺服器上，每臺伺服器執行在不同的端系統，每個都有著不同的 IP 地址。由於這些冗餘的 Web 伺服器，一個 IP 地址集合因此與同一個規範主機名聯絡。DNS 資料庫中儲存著這些 IP 地址的集合。由於使用者端每次都會發起 HTTP 請求，所以 DNS 就會在所有這些冗餘的 Web 伺服器之間迴圈分配了負載。

    還有一種負載是全域性負載，全域性負載一般部署在多個機房之間，每個機房都會有自己的 IP 地址，當用戶存取某個域名時，會在這些 IP 之間進行輪詢，如果某個資料中心掛了，就會將對應的 IP 地址刪除，比如某個 DNS 使用者端會輪詢存取北京和上海的機房，一個掛了會直接使用另外一個，這就是全域性負載的概念。

DNS 工作機制

假設執行在使用者主機上的某些應用程式（如 Web 瀏覽器或郵件閱讀器） 需要將主機名轉換為 IP 地址。這些應用程式將呼叫 DNS 的使用者端，並指明需要被轉換的主機名。DSN 使用者端收到 DNS 後，會使用 UDP 通過 53 埠向網路上傳送一個 DNS 查詢報文，經過一段時間後，DNS 使用者端會收到一個主機名對應的 DNS 應答報文。因此，從使用者主機的角度來看，DNS 就像是一個黑盒子，其內部的操作你無法看到。但是實際上，實現 DNS 這個服務的黑盒子非常複雜，它由分佈於全球的大量 DNS 伺服器以及定義了 DNS 伺服器與查詢主機通訊方式的應用層協定組成。

DNS 最早的設計是隻有一臺 DNS 伺服器。這臺伺服器會包含所有的 DNS 對映。這是一種集中式單點設計，這種設計並不適用於當今的網際網路，因為網際網路有著數量巨大並且持續增長的主機，這種集中式的設計會存在以下幾個問題

  • 單點故障(a single point of failure)，單點通常上只有一臺 DNS 伺服器，如果 DNS 伺服器崩潰，那麼整個網路隨之癱瘓。
  • 通訊容量(traaffic volume)，單個 DNS 伺服器不得不處理所有的 DNS 查詢，這種查詢級別可能是上百萬上千萬級。
  • 遠距離集中式資料庫(distant centralized database)，單個 DNS 伺服器不可能靠近所有的使用者，假設在美國的 DNS 伺服器不可能臨近讓澳大利亞的查詢使用，其中查詢請求勢必會經過低速和擁堵的鏈路，造成嚴重的時延。
  • 維護(maintenance)，維護成本巨大，而且還需要頻繁更新。

所以 DNS 不可能集中式設計，因為集中式設計完全沒有可延伸能力，因此採用分散式設計，這種設計的特點如下。

分散式、層次資料庫

分散式設計首先解決的問題就是 DNS 伺服器的擴充套件性問題。因此 DNS 使用了大量的 DNS 伺服器，它們的組織模式一般是層次方式，並且分佈在全世界範圍內。沒有一臺 DNS 伺服器能夠擁有因特網上所有主機的對映。相反，這些對映分佈在所有的 DNS 伺服器上。

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

圖 7-2

假設現在一個 DNS 使用者端想要知道 www.amazon.com 的 IP 地址，那麼上面的域名伺服器是如何解析的呢？

首先，使用者端會先根伺服器之一進行關聯，它將返回頂級域名 com 的 TLD 伺服器的 IP 地址。然後使用者端與這些 TLD 伺服器之一聯絡，它將為 amazon.com 返回權威伺服器的 IP 地址。最後，該客戶與 amazom.com 權威伺服器之一聯絡，它為 www.amazom.com 返回其 IP 地址。

DNS 層次結構

我們現在來討論一下上面域名伺服器的層次系統。

  • 根 DNS 伺服器 ，有 400 多個根域名伺服器遍及全世界，這些根域名伺服器由 13 個不同的組織管理。根域名伺服器的清單和組織機構可以在 https://root-servers.org/ 中找到，根域名伺服器提供 TLD 伺服器的 IP 地址。
  • 頂級域 DNS 伺服器，對於每個頂級域名比如 com、org、net、edu 和 gov 和所有的國家級域名 uk、fr、ca 和 jp 都有 TLD 伺服器或伺服器叢集。所有的頂級域列表參見 https://tld-list.com/ 。TDL 伺服器提供了權威 DNS 伺服器的 IP 地址。
  • 權威 DNS 伺服器，在因特網上具有公共可存取的主機，如 Web 伺服器和郵件伺服器，這些主機的組織機構必須提供可供存取的 DNS 記錄，這些記錄將這些主機的名字對映為 IP 地址。一個組織機構的權威 DNS 伺服器收藏了這些 DNS 記錄。

DNS 查詢步驟

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

注意：通常情況下 DNS 會將查詢的資訊快取在瀏覽器或者計算機本地中，如果有相同的請求到來時，就不再會進行 DNS 查詢，而會直接返回結果。

通常情況下，DNS 的查詢會經歷下面這些步驟

  1. 使用者在瀏覽器中輸入網址 www.example.com 並點選回車後，查詢會進入網路，並且由 DNS 解析器進行接收。

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

  3. 根 DNS 伺服器會注意到請求地址的字首並向 DNS 解析器返回 com 的頂級域名伺服器(TLD)的 IP 地址列表。

  4. 然後，DNS 解析器會向 TLD 伺服器傳送查詢報文。

  5. TLD 伺服器接收請求後，會根據域名的地址把權威 DNS 伺服器的 IP 地址返回給 DNS 解析器。

  6. 最後，DNS 解析器將查詢直接傳送到權威 DNS 伺服器。

  7. 權威 DNS 伺服器將 IP 地址返回給 DNS 解析器。

  8. DNS 解析器將會使用 IP 地址響應 Web 瀏覽器。

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

整個流程如下圖所示

圖 7-3

DNS 解析器

進行 DNS 查詢的主機和軟體叫做 DNS 解析器，使用者所使用的工作站和個人電腦都屬於解析器。一個解析器要至少註冊一個以上域名伺服器的 IP 地址。DNS 解析器是 DNS 查詢的第一站，其負責與發出初始請求的使用者端打交道。解析器啟動查詢序列，最終使 URL 轉換為必要的 IP 地址。

圖 7-4

DNS 遞迴查詢和 DNS 遞迴解析器不同，該查詢是指向需要解析該查詢的 DNS 解析器發出請求。DNS 遞迴解析器是一種計算機，其接受遞迴查詢並通過發出必要的請求來處理響應。

DNS 查詢型別

DNS 查詢中會出現三種型別的查詢。通過組合使用這些查詢，優化的 DNS 解析過程可縮短傳輸距離。在理想情況下，可以使用快取的記錄資料，從而使 DNS 域名伺服器能夠直接使用非遞迴查詢。

  1. 遞迴查詢：在遞迴查詢中，DNS 使用者端要求 DNS 伺服器（一般為 DNS 遞迴解析器）將使用所請求的資源記錄響應使用者端，或者如果解析器無法找到該記錄，則返回錯誤訊息。

    圖 7-5

  2. 迭代查詢：在迭代查詢中，如果所查詢的 DNS 伺服器與查詢名稱不匹配，則其將返回對較低階別域名空間具有權威性的 DNS 伺服器的參照。然後，DNS 使用者端將對參照地址進行查詢。此過程繼續使用查詢鏈中的其他 DNS 伺服器，直至發生錯誤或超時為止。

    圖 7-6

  3. 非遞迴查詢：當 DNS 解析器使用者端查詢 DNS 伺服器以獲取其有權存取的記錄時通常會進行此查詢，因為其對該記錄具有權威性，或者該記錄存在於其快取內。DNS 伺服器通常會快取 DNS 記錄，查詢到來後能夠直接返回快取結果，以防止更多頻寬消耗和上游伺服器上的負載。

DNS 快取

DNS 快取(DNS caching) 有時也叫做DNS 解析器快取，它是由作業系統維護的臨時資料庫，它包含有最近的網站和其他 Internet 域的存取記錄。也就是說， DNS 快取只是計算機為了滿足快速的響應速度而把已載入過的資源快取起來，再次存取時可以直接快速參照的一項技術和手段。那麼 DNS 的快取是如何工作的呢？

DNS 快取的工作流程

在瀏覽器向外部發出請求之前，計算機會攔截每個請求並在 DNS 快取資料庫中查詢域名，該資料庫包含有最近的域名列表，以及 DNS 首次發出請求時 DNS 為它們計算的地址。

DNS 快取方式

DNS 資料可快取到各種不同的位置上，每個位置均將儲存 DNS 記錄，它的生存時間由 TTL(DNS 欄位) 來決定。

瀏覽器快取

現如今的 Web 瀏覽器設計預設將 DNS 記錄快取一段時間。因為越靠近 Web 瀏覽器進行 DNS 快取，為檢查快取並向 IP 地址發出請求的次數就越少。發出對 DNS 記錄的請求時，瀏覽器快取是針對所請求的記錄而檢查的第一個位置。

在 chrome 瀏覽器中，你可以使用 chrome://net-internals/#dns 檢視 DNS 快取的記錄。

圖 7-7

作業系統核心快取

在瀏覽器快取查詢後，會進行作業系統級 DNS 解析器的查詢，作業系統級 DNS 解析器是 DNS 查詢離開你的計算機前的第二站，也是本地查詢的最後一個步驟。

DNS 報文

共同實現 DNS 分散式資料庫的所有 DNS 伺服器儲存了資源記錄(Resource Record, RR)，RR 提供了主機名到 IP 地址的對映。每個 DNS 回答報文中會包含一條或多條資源記錄。RR 記錄用於回覆使用者端查詢。

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

(Name, Value, Type, TTL)

RR 會有不同的型別，下面是不同型別的 RR 彙總表。

DNS RR 型別 解釋
A 記錄 IPv4 主機記錄，用於將域名對映到 IPv4 地址
AAAA 記錄 IPv6 主機記錄，用於將域名對映到 IPv6 地址
CNAME 記錄 別名記錄，用於對映 DNS 域名的別名
MX 記錄 郵件交換器，用於將 DNS 域名對映到郵件伺服器
PTR 記錄 指標，用於反向查詢（IP地址到域名解析）
SRV 記錄 SRV記錄，用於對映可用服務。
表 7-1

DNS 有兩種報文，一種是查詢報文，一種是響應報文，並且這兩種報文有著相同的格式，下面是 DNS 的報文格式。

圖 7-8

下面我們就來看一下詳細的報文欄位。

報文段首部

報文段首部是 DNS 報文的基礎結構部分，下面我們對報文段首部中的每個位元組進行描述。

  • 事務 ID: TransactionID 由使用者端設定，由伺服器返回。TransactionID 佔用 2 個位元組。它是 DNS 的標識，對於同一個請求報文和響應報文來說，這個欄位的值是相同的，以此來區分使用者端請求和響應。
  • 標誌：標誌欄位佔用 2 個位元組。標誌欄位有很多，而且也比較重要，下面我給你列出來了所有的標誌欄位。

圖 7-9

每個欄位的含義如下

  • QR(Response): 1 bit 的 QR 標識報文是查詢報文還是響應報文，查詢報文時 QR = 0，響應報文時 QR = 1。
  • OpCode: 4 bit 的 OpCode 表示操作碼，這個值通常是 0 ，代表標準的請求和響應。OpCode = 4 表示這是一個通知；OpCode = 5 表示這是一個更新請求。而其他值（1-3）是被棄用的。
  • AA(Authoritative): 1 bit 的 AA 代表授權應答，這個 AA 只在響應報文中有效，值為 1 時，表示名稱伺服器是權威伺服器；值為 0 時，表示不是權威伺服器。
  • TC(Truncated): 截斷標誌位，值為 1 時，表示響應已超過 512 位元組並且已經被截斷，只返回前 512 個位元組。
  • RD(Recursion Desired): 這個欄位是期望遞迴欄位，該欄位在查詢中設定，並在響應中返回。該標誌告訴名稱伺服器必須處理這個查詢，這種方式被稱為一個遞迴查詢。如果該位為 0，且被請求的名稱伺服器沒有一個授權回答，它將返回一個能解答該查詢的其他名稱伺服器列表。這種方式被稱為迭代查詢。
  • RA(Recursion Available): 可用遞迴欄位，這個欄位只出現在響應報文中。當值為 1 時，表示伺服器支援遞迴查詢。
  • Z: 保留欄位，在所有的請求和應答報文中，它的值必須為 0。
  • AD: 這個欄位表示資訊是否是已授權，已授權就是 true。
  • CD: 這個欄位表示是否禁用安全檢查，禁用檢查就是 true。
  • rcode（Reply code）：這個欄位是返回碼欄位，表示響應的差錯狀態。當值為 0 時，表示沒有錯誤；當值為 1 時，表示報文格式錯誤（Format error），伺服器不能理解請求的報文；當值為 2 時，表示域名伺服器失敗（Server failure），因為伺服器的原因導致沒辦法處理這個請求；當值為 3 時，表示名字錯誤（Name Error），只有對授權域名解析伺服器有意義，指出解析的域名不存在；當值為 4 時，表示查詢型別不支援（Not Implemented），即域名伺服器不支援查詢型別；當值為 5 時，表示拒絕（Refused），一般是伺服器由於設定的策略拒絕給出應答，如伺服器不希望對某些請求者給出應答。

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

圖 7-10

現在我們可以看一下具體的 DNS 報文，通過 query 可知這是一個請求報文，這個報文的識別符號是 0xcd28，它的標誌如下。

  • QR = 0 實錘了這就是一個請求。
  • 然後是四個位元組的 OpCode，它的值是 0，表示這是一個標準查詢。
  • 因為這是一個查詢請求，所以沒有 AA 欄位出現。
  • 然後是截斷標誌位 Truncated，表示沒有被截斷。
  • 緊隨其後的 RD = 1，表示希望得到遞迴回答。
  • 請求報文中沒有 RA 欄位出現。
  • 然後是保留欄位 Z。
  • 緊隨其後的 0 表示未經身份驗證的資料是不可接受的。
  • 沒有 RCODE 欄位的值。

然後我們看一下響應報文。

圖 7-11

可以看到，標誌位也是 0xcd28，可以說明這就是上面查詢請求的響應。

查詢請求已經解釋過的報文我們這裡就不再說明了，現在只解釋一下請求報文中沒有的內容。

  • 緊隨在 OpCode 後面的 AA 欄位已經出現了，它的值為 0 ，表示不是權威 DNS 伺服器的響應。
  • 最後是 RCODE 欄位的響應，值為 0 時，表示沒有錯誤。

查詢區

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

圖 7-12

這部分中每個欄位的含義如下：

  • 查詢名（Query Name）：指定要查詢的域名，有時候也是 IP 地址，用於反向查詢。
  • 查詢型別（Query Type）：DNS 查詢請求的資源型別，通常查詢型別為 A 型別，表示由域名獲取對應的 IP 地址。
  • 查詢類（Query Class）：地址型別，通常為網際網路地址，值為 1 。這個查詢類的值通常是 1、254 和 255，分別表示網際網路類、沒有此類和所有類。

同樣的，我們再使用 wireshark 檢視一下查詢區域。

圖 7-13

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

圖 7-14

如上圖所示，響應型別也是 A。

資源記錄部分

資源記錄部分是 DNS 報文的最後三個欄位，包括回答問題區域、權威名稱伺服器記錄、附加資訊區域，這三個欄位均採用一種稱為資源記錄的格式，如下圖所示。

圖 7-15

資源記錄部分的欄位含義如下

  • Name：DNS 請求的域名。
  • Type：資源記錄的型別，與查詢部分中的查詢型別是一樣的。
  • Class：地址型別、與問題中的查詢類值一樣的。
  • TTL：以秒為單位，表示資源記錄的生命週期。
  • RDLENGTH（資源資料長度）：資源資料的長度。
  • RDATA（資源資料）：表示按查詢段要求返回的相關資源記錄的資料。

資源記錄部分只有在 DNS 響應包中才會出現。下面我們就來通過響應報文看一下具體的欄位範例。

圖 7-16

其中，域名的值是 mobile-gtalk.l.google.com ，型別是 A，類是 1，生存時間是 5 秒，資料長度是 4 位元組，資源資料表示的地址是 63.233.189.188。

CNAME 記錄

CNAME 是 DNS 的一種記錄型別，它的全稱是 Canonical Name Record，這個型別能夠將某些 DNS 別名對映到 DNS 命名系統中。

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

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

這是啥意思呢？

這表示的是如果使用者在瀏覽器中輸入的使 www.cxuanblog.edu 這個域名，其實輸入的是 www.cxuanblog.com 這個域名，如果你打算把部落格搬家後，你輸入的舊域名其實會直接跳轉到新域名的網頁下。

CNAME 還有一種普遍的做法就是把它作為公共域名進行存取。

反向 DNS 查詢

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

反向 DNS 查詢向 DNS 伺服器查詢 PTR（Pointer Record）記錄，如果伺服器沒有 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 查詢通常用於電子郵件協定中，電子郵件伺服器會檢查電子郵箱中的電子郵件訊息是否來自真實有效的伺服器，垃圾郵件傳送者經常使用被劫持機器的，這些郵件過來後就不會有 PTR 記錄。電子郵件伺服器會拒絕不支援反向查詢的伺服器或者不太合法的伺服器郵件。

SOA 記錄

如果是權威 DNS 伺服器的響應的話，會顯示記錄儲存有關區域的重要資訊，這種資訊就是 SOA 記錄。所有的 DNS 區域都需要一個 SOA 記錄才能符合 IETF 標準。 SOA 記錄對於區域傳輸也很重要。

SOA 記錄除具有 DNS 解析器響應的欄位外，還具有一些額外的欄位，如下

圖 7-17

具體欄位含義

  • PNAME：即 Primary Name Server，這是區域的主要名稱伺服器的名稱。
  • RNAME：即 Responsible authority's mailbox，RNAME 代表管理員的電子郵件地址，@ 用 . 來表示，也就是說 admin.example.com 等同於 [email protected]。
  • 序列號： 即 Serial Number ，區域序列號是該區域的唯一識別符號。
  • 重新整理間隔：即 Refresh Interval，在請求主伺服器提供 SOA 記錄以檢視其是否已更新之前，輔助伺服器應等待的時間（以秒為單位）。
  • 重試間隔：即 Retry Interval ，伺服器應等待無響應的主要名稱伺服器再次請求更新的時間。
  • 過期限制：即 Expire limit ，如果輔助伺服器在這段時間內沒有收到主伺服器的響應，則應停止響應對該區域的查詢。

上面提到了主要名稱伺服器和輔助名稱伺服器，他們之間的關係如下。

圖 7-18

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

區域傳輸和 DNS NOTIFY

區域傳輸通常指一塊區域內 DNS 伺服器中的 RR 資源更新，這樣做的目的是為了保證多臺伺服器保證內容同步。如果區域中一臺伺服器失效了，那麼其他伺服器可以臨時頂上，充當臨時 DNS 伺服器的角色。區域傳輸通常在輪詢（polling）後開啟，在輪詢中，從伺服器會週期性的檢查主伺服器，檢視區域是否已經更新，區域傳輸需要開啟。

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

  1. 全量傳輸：即傳輸整個區域的訊息，全量傳輸會傳輸整個區域（使用 AXFR）的訊息。
  2. 增量傳輸：增量傳輸就是傳輸一部分訊息，增量傳輸使用（使用 DNS IXFR）的訊息。

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

DNS 網路排查工具

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

nslookup

nslookup 是一款用來解決 DNS 相關問題排查的工具。

它主要分為兩種模式，一種是互動模式，一種是非互動模式。互動模式就是一問一答式的，而非互動模式就是一次執行的。

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

圖 7-19

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

圖 7-20

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

圖 7-21

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

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

  1. nslookup 能夠查詢主機的 IP 地址；
  2. nslookup 能夠查詢 IP 地址的域名；
  3. nslookup 能夠查詢域名的郵件伺服器。

可以通過 nslookup -querytype 查詢域名的郵件伺服器，如下

圖 7-22

會分為兩種查詢結果，一種是 Non-authoritative answer，這表明我們想查詢的這個網址是從本地 DNS cache 也就是 DNS 快取中查詢出來的，而不是從本地 DNS 經過 DNS 查詢後得到的真實域名。

還有一種就是 Authoritative answers，這種就是本地 DNS 經過 DNS 查詢後得到的真實域名。

上圖還顯示了 netease.com 郵件伺服器的一些引數，origin 表示源地址，mail addr 表示郵件伺服器的地址，serial 表示序列號，refresh 表示重新整理間隔，retry 表示重試間隔，expire 表示過期時間， minumum 表示最大長度。

dig

我們的電腦上有多個網路連線，每個網路連線會有不同的 DNS ，而且 DNS 也分為主 DNS 和備用 DNS，nslookup 會預設使用主 DNS 連線，如果你的主 DNS 沒有設定，使用可能會存在下面這種情況。

圖 7-23

與 nslookup 不同的使，dig 也是一款 DNS 網路排查工具，它會從你的網路連線中選取一塊可用的連線進行解析和使用，不過 windows 10 下預設不支援 dig 命令工具的使用，mac 倒是支援。

下面是 mac 下的 dig 命令。

圖 7-24

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

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

圖 7-25

下面我們就來介紹一下 dig 這款工具都用哪些用法以及各個引數的含義，我們以 dig baidu.com 來進行說明

圖 7-26

如上圖所示，最上面的

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

;; global options: +cmd 表示全域性選項，dig 可以查詢多個域資訊，這裡顯示應用於所有查詢的選項，預設是 +cmd。

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63799 這行表示頭資訊，其中操作碼 QUERY 表示查詢，IQUERY 表示反查詢，STATUS 表示監測狀態等。

NOERROR 表示這個請求已正常解決，id 是一個亂數字，它用於將請求和響應繫結在一起。

;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 這一行都是一些標誌位，其中

  • qr = query , rd = recursion desired ，ra = recursion avaliable 這裡其實 DNS 和我們玩了一個文字遊戲，因為 rd 翻譯過來就是需要遞迴，這個沒什麼好說的，預設就是使用遞迴查詢；而 ra 翻譯過來是遞迴可用，這個需要思考下，遞迴可用我是用還是不用呢？當然你可以用也可以不用，如果你不使用遞迴的話，那麼 DNS 查詢方式就是迭代查詢。
  • QUERY 表示查詢數量，ANSWER 表示結果數量
  • AUTHORITY 表示來自權威域名伺服器的結果數量，為 0 說明是從本地 DNS 中返回的，因為沒有權威伺服器的返回資訊。
  • ADDITIONAL 表示附加資訊，當其值大於 1 時才會看到額外資訊。

下面是問題區域

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

依次是正在查詢的域名，IN 我們上面提到了它表示網際網路查詢，A 表示域名對映到 IPv4 地址。

下面是答案部分

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

中間的數位表示 TTL ，即可以快取記錄的時間間隔。

最後是統計部分，這塊沒什麼好說的了。

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

-x 進行反向 DNS 查詢

我們知道，DNS 可以把域名轉換為 IP ，同時也可以把 IP 轉換成對應的域名，其中 -x 就是進行反向 DNS 查詢，如下所示：

圖 7-27

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

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

圖 7-28

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

+noall +answer

這告訴 dig 只列印 DNS 響應中的ANSWER部分內容，如下所示

圖 7-29

+short

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

圖 7-30

+trace

dig +trace 能夠模仿 DNS 解析器在查詢域名時的做法 ，即它會從根伺服器開始查詢，一直到權威 DNS 伺服器。相當於鏈路追蹤的一個作用。

圖 7-31

除了我們上面介紹的 nslookup 和 dig 之外，還有其他 DNS 檢測工具，比如 dog 、drill ，都是很好用的 DNS 網路排查工具，大家可以查閱相關資料進行使用，這裡我就不再進行詳細的介紹了。

DNS 安全

幾乎所有的網路請求都會經過 DNS 查詢，而且 DNS 和許多其他的 Internet 協定一樣，系統設計時並未考慮到安全性，並且存在一些設計限制，這為 DNS 攻擊創造了機會。

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

  • 第一種是 Dos 攻擊，這種攻擊的主要形式是使重要的 DNS 伺服器比如 TLD 伺服器或者根域名伺服器過載，從而無法響應權威伺服器的請求，使 DNS 查詢不起作用。
  • 第二種攻擊形式是 DNS 欺騙，通過改變 DNS 資源內容，比如偽裝一個官方的 DNS 伺服器，回覆假的資源記錄，從而導致主機在嘗試與另一臺機器連線時，連線至錯誤的 IP 地址。
  • 第三種攻擊形式是 DNS 隧道，這種攻擊使用其他網路協定通過 DNS 查詢和響應建立隧道。攻擊者可以使用 SSH、TCP 或者 HTTP 將惡意軟體或者被盜資訊傳遞到 DNS 查詢中，這種方式使防火牆無法檢測到，從而形成 DNS 攻擊。
  • 第四種攻擊形式是 DNS 劫持，在 DNS 劫持中，攻擊者將查詢重定向到其他域名伺服器。這可以通過惡意軟體或未經授權的 DNS 伺服器修改來完成。儘管結果類似於 DNS 欺騙，但這是完全不同的攻擊，因為它的目標是名稱伺服器上網站的 DNS 記錄，而不是解析程式的快取。
  • 第五章攻擊形式是 DDoS 攻擊，也叫做分散式拒絕服務頻寬洪泛攻擊，這種攻擊形式相當於是 Dos 攻擊的升級版

那麼該如何防禦 DNS 攻擊呢？

防禦 DNS 威脅的最廣為人知的方法之一就是採用 DNSSEC 協定。

DNSSEC

DNSSEC 又叫做 DNS 安全擴充套件，DNSSEC 通過對資料進行數位簽章來保護其有效性，從而防止受到攻擊。它是由 IETF 提供的一系列 DNS 安全認證的機制。DNSSEC 不會對資料進行加密，它只會驗證你所存取的站點地址是否有效。

DNS 防火牆

有一些攻擊是針對伺服器進行的，這就需要 DNS 防火牆的登場了，DNS 防火牆是一種可以為 DNS 伺服器提供許多安全和效能服務的工具。DNS 防火牆位於使用者的 DNS 解析器和他們嘗試存取的網站或服務的權威名稱伺服器之間。防火牆提供限速存取，以關閉試圖淹沒伺服器的攻擊者。如果伺服器確實由於攻擊或任何其他原因而導致停機，則 DNS 防火牆可以通過提供來自快取的 DNS 響應來使操作員的站點或服務正常執行。

除了上述兩種防禦手段外，本身 DNS 區域的運營商就會採取進步一措施保護 DNS 伺服器，比如設定 DNS 基礎架構，來防止 DDoS 攻擊。

總結

這篇文章我用較多的字數為你介紹了 DNS 的基本概述，DNS 的工作機制，DNS 的查詢方式，DNS 的快取機制，我們還通過 WireShark 抓包帶你認識了一下 DNS 的報文，最後我為你介紹了 DNS 的攻擊手段和防禦方式。

這是一篇入門 DNS 較全的文章，花了我一週多的時間來寫這篇文章，這篇文章瞭解清楚後，基本上 DNS 的大部分問題你應該都能夠回答，面試我估計也穩了。

原文連結：DNS，給你安排明白了！

我自己有個公眾號：程式設計師cxuan，微信搜即可，歡迎大家捧場。