一：前言
域名系統（DNS）是最重要的互聯網協議之一，因爲它是總所周知的黏合劑，把域名轉換爲IP地址。當我們想要和一臺網絡設備通信卻不知道它的IP地址，可以使用它的域名來進行訪問。
DNS服務器存儲了一個有着IP地址和DNS名字映射資源記錄的數據庫，並將其和客戶端以及其他DNS服務器共享
由於DNS服務器的結構很複雜，因此我們只關注於通常類型的DNS流量
二：DNS數據包結構
事務ID、標誌、問題計數、回答資源記錄數、權威名稱服務器計數、附加資源記錄數，這6個字段是DNS的報文首部，共12個字節
整個DNS格式主要分爲3部分內容，級基礎結構部分、問題部分、資源記錄部分
基礎結構中的標誌字段又分爲若干個字段，如下圖
事務ID（Transaction ID）：用來對應DNS查詢和響應的過程
QR（Query / Response）：指明數據包是DNS查詢還是DNS響應
操作碼（Opcode）：用來定義消息中請求的類型
權威應答（Authoritative Answer，AA）：如果數據包設定了這個值，說明該響應是由域名內權威域名服務器發出的
截斷（Truncation，TC）：指明這個響應由於太長，無法裝入數據包被極端
期望遞歸（Recursion desired，RD）：如果在請求中設定了這個值，說明DNS客戶端在目標域名服務器下不含有所請求信息的情況下，要求進行遞歸
可用遞歸（Recursion Avaliable，RA）：如果響應中設定了這個值，則說明域名服務器支持遞歸查詢
保留（Z）：在RFC1035的規定被設爲全0，但有時會被用來作爲RCode域的擴展
響應碼（Response Code）：在DNS響應中用來指明錯誤
問題計數（Question Count）：在問題區段中的條目數
回答計數（Answer Count）：在回答區段中的條目數
域名服務器計數（Name Server Count）：在權威區段的域名資源記錄數
額外記錄計數（Additional Records Count）：在額外信息區段中的其他資源記錄數
問題區段（Question section）：大小可變、包含要被髮送到DNS服務器的一條或多條的信息查詢部分
回答區段（Answer section）：大小可變、包含用來回答查詢的一條或多條資源記錄
權威區段（Authority section）：大小可變、包含指向權威域名服務器的資源記錄，用以繼續解析過程
額外信息區段（Additional Information section）：大小可變、包含於查詢有關的額外信息，但對於回答查詢這並不是絕對必要的資源記錄
三：一次簡單的DNS查詢過程
DNS以查詢/響應的模式工作。當一個客戶端想要將一個DNS解析成IP地址時，它會向DNS服務器發送一個查詢，然後服務器在響應中提供所請求的信息，在比較簡單的情況下，這個過程包含兩個數據包
第一個數據包是由192.168.0.114的客戶端通過DNS的標準端口53發向205.152.37.23的服務器進行DNS查詢
其中DNS協議也是基於UDP協議的，在數據包的DNS區段，開頭的一些較小域都被Wireshark合併成了一個標誌區段（Flags section ） 。這是一個典型的請求：沒有截斷並且期望遞歸查詢。在展開查詢時，裏面也有僅有一個問題，查詢名字爲Wireshark.org的主機類型（A）互聯網（IN）地址：哪個IP地址對應着Wireshark.org域
第二個數據包響應了這個請求，該包有着唯一的標識碼，包含着對於原始查詢的正確響應
標誌區段可以確保這是一個響應並且允許必要的遞歸。這個數據包僅包含一個問題和一個資源記錄，因爲它將原問題和回答連接了起來。展開回答區段 就可以看到對於查詢的回答：Wireshark.org 的地址是128.121.50.122。有了這個信息之後，客戶端就可以開始構建IP數據包，與Wireshark.org通信了
四：DNS問題類型
DNS查詢和響應中所使用的類型域，指明瞭這個查詢或者響應的資源記錄類型
| 值 | 類型 | 描述 |
|---|---|---|
| 1 | A | IPv4主機地址 |
| 2 | NS | 權威域名服務器 |
| 5 | CNAME | 規範別名 |
| 16 | MX | 郵件交換 |
| 16 | TXT | 文本字符串 |
| 28 | AAAA | IPv6主機地址 |
| 251 | IXFR | 增量區域傳送 |
| 252 | AXFR | 完整區域傳送 |
五：DNS遞歸
由於互聯網的DNS結構是層級的，因此爲了能夠回答客戶端提交的查詢，DNS服務器必須能夠彼此通信。我們內部DNS服務器知道本地局域網服務器的名字和IP地址的映射
當DNS服務器需要查找一個IP地址時，它會代表發出請求的客戶端向另一個DNS服務器查詢。實際上，這個DNS服務器與客戶端的行爲相同，這個過程叫做遞歸查詢
上圖的數據包是從DNS客戶端 172.16.0.8 發往DNS服務器 172.16.0.102 的初始查詢
第一個數據包時用以查找DNS名稱爲 www.nostarch.com 的A 類型記錄的標準查詢，如上圖
第二個數據包是我們所希望的看到的對於初始數據包的響應，如下圖
這個數據包的事務ID和我們的查詢一致，也沒有列出錯誤，所以就得到了 www.nostarch.com所對應的A類型資源記錄
如果我們想要知道查詢是否被遞歸應答，唯一的方法就是當進行遞歸查詢時監聽DNS服務器的流量
上圖中的第一個數據包和上一次捕獲文件中的初始查詢相同。這時，DNS服務器接到了這個查詢，在其本地數據包檢查後，發現它並不知道關於DNS域名（nostarch.com）所對應IP地址的這個問題的答案。由於這個數據包發送時設置了 期望遞歸 ，因此在第二個數據包中，這個DNS服務器爲了的得到答案向其他DNS服務器詢問這個問題
在第二個數據包中，位於 172.16.0.102 的DNS服務器向 4.2.2.1 （其所設定的要轉發上行請求的服務器）發送了一個新的查詢，如下圖
這個數據包被 4.2.2.1 接收之後，本地DNS服務器就接到了響應，如下圖
接到了這個響應之後，本地的DNS服務器就可以將這個信息傳遞給 DNS客戶端，如下圖
雖然該例只展示了一層的遞歸，但對於一個DNS請求來說，遞歸查詢可能會發生很多次。這裏我們收到了來自DNS服務器 4.2.2.1 的回答，但那個服務器可能爲了尋找答案也向其他服務器進行了遞歸查詢。一個簡單的遞歸查詢在其得到最終響應之前可能遍歷了全世界，DNS遞歸查詢的過程如下圖
六：DNS區域傳送
DNS區域是一個DNS服務所授權管理的名字空間（或是一組DNS名稱）。例如，masaike的這個網站可能由一個DNS服務器masaike.com負責，這樣，無論是masaike內部或者外部的設備，如果希望將masaike.com解析成IP地址，都需要和這個區域的權威，也就是這個DNS服務器聯繫。如果masaike發展壯大了，它可能會增加一個DNS服務器，專門用來處理其名字空間的email部分，比如mail.masaike.com，那麼這個服務器，就成爲這個郵件子區域的權威，如果必要的話，還可以爲子域名添加更多的DNS服務器，如下圖所示
區域傳送指的是通常出於冗餘備份的的需要，在兩臺設備之間傳送區域數據。例如，在擁有多個DNS服務器的組織中，管理員通常都會配置一臺備用的DNS服務器，用來維護一份主服務器DNS信息的副本，以防止主DNS服務器不可用。主要存在兩種區域傳送
完整區域傳送（AXFR）：這個類型的傳送將整個區域在設備間進行傳送
增量區域傳送（IXFR）：這類型的傳送僅傳送區域信息的一部分
上圖描述了有一個主機 172.16.16.164 和 172.16.16.139之間進行完整區域傳送的例子
雖然DNS基於UDP協議，但它在比如區域傳送的一些任務中也會使用TCP協議，因爲TCP對於規模數據的傳輸更加可靠。上圖的前三個數據包是TCP的三次握手
第四個數據包開始在 172.16.16.164 和 172.16.16.139進行實際的區域傳送。這個數據包並不包含任何DNS信息。由於區域傳送請求的數據包中的數據由多個數據包所發送，因此這個數據包被標記爲重組裝PDU的 TCP分片。數據包 4 和 6 包含了數據包的數據。數據包5是對於數據包4被成功接收的確認。這些數據包以這種方式顯示出來是因爲Wireshark處於可讀性的考慮，將TCP數據包如此解析並呈現。可以將數據包6作爲完整的區域傳送請求，如下圖
區域傳送請求是典型的查詢，但它請求的是AXFR類型而不是單一記錄類型，這意味着它希望從服務器接收全部DNS區域。 服務器在數據包7中回覆了區域記錄，如下圖
區域傳送包含了相當多的數據，並且這還是一個很簡答的例子。在區域完成之後，捕獲文件以TCP連接的終止過程作爲結束
區域傳送的數據如果錄入他人之手可能會很危險，例如：通過枚舉一個DNS服務器，可以繪出整個網絡的結構