DNS協議詳解及報文格式分析

DNS協議詳解及報文格式分析

目錄

• 一. DNS協議理論知識
  • 1.1. 域名結構
  • 1.2. 域名服務器
  • 1.3. 域名解析過程
• 二. DNS協議報文格式
  • 2.1 頭部
  • 2.2 正文
• 三. Wireshark分析DNS協議
  • 3.1 請求報文
  • 3.2 響應報文

解BUG的過程中碰到了DNS相關的內容，折騰網站和域名郵箱時也對DNS做了一些配置，發現對一些細節有點記不清晰了，因此很有必要重新溫習一下這方面的知識。學過網絡的應該記得現代計算機通信的基石是TCP/IP協議，計算機A想要與計算機B進行通信，首先就必須要知道計算機B的IP地址，就像打電話一樣，你給別人打電話首先必須得知道別人的電話號碼吧，電話號碼都不知道還搞個毛。

但是問題來了，讓人們去記憶這又臭又長的IP地址或是電話號碼，無疑是不人道的，當然，這個小問題也並莫有難倒勤勞勇敢的人民羣衆。很快就發明了通訊錄這個東西，用於將人名與電話號碼聯繫起來。

在計算機領域也出現了DNS(Domain Name System)，即域名系統，用於將域名解析成對應的IP地址。本文將介紹DNS協議的基本理論及其報文格式，最後給出了用Wireshark抓取DNS報文的記錄。如果需要了解更爲詳細的內容，請參考 RFC1034 和 RFC1035。

---

一. DNS協議理論知識

1.1. 域名結構

域名系統並不像電話號碼通訊錄那麼簡單，通訊錄主要是單個個體在使用，同一個名字出現在不同個體的通訊錄裏並不會出現問題，但域名是羣體中所有人都在用的，必須要保持唯一性。爲了達到唯一性的目的，因特網在命名的時候採用了層次結構的命名方法。每一個域名（本文只討論英文域名）都是一個標號序列（labels），用字母（A-Z，a-z，大小寫等價）、數字（0-9）和連接符（-）組成，標號序列總長度不能超過255個字符，它由點號分割成一個個的標號（label），每個標號應該在63個字符之內，每個標號都可以看成一個層次的域名。級別最低的域名寫在左邊，級別最高的域名寫在右邊。域名服務主要是基於UDP實現的，服務器的端口號爲53。

比如：本網站的域名 jocent.me，由點號分割成了兩個域名jocent 和 me，其中 me是頂級域名（TLD，Top-Level Domain）， jocent是二級域名（SLD，Second Level Domain）。關於域名的層次結構，請看下面的示意圖。

注意：最開始的域名最後都是帶了點號的，比如 jocent.me 擱以前的話應該是 jocent.me. ，最後面的點號表示根域名服務器，後來發現所有的網址都要加上最後的點，就簡化了寫法，乾脆所有的都不加，但是你在網址後面加上點號也是可以正常解析的。

1.2. 域名服務器

有域名結構還不行，還需要有一個東西去解析域名，手機通訊錄是由通訊錄軟件解析的，域名需要由遍及全世界的域名服務器去解析，域名服務器實際上就是裝有域名系統的主機。由高向低進行層次劃分，可分爲以下幾大類：

• 根域名服務器：    最高層次的域名服務器，也是最重要的域名服務器，本地域名服務器如果解析不了域名就會向根域名服務器求助。全球共有13個不同IP地址的根域名服務器，它們的名稱用一個英文字母命名，從a一直到m。這些服務器由各種組織控制，並由 ICANN（互聯網名稱和數字地址分配公司）授權，由於每分鐘都要解析的名稱數量多得令人難以置信，所以實際上每個根服務器都有鏡像服務器，每個根服務器與它的鏡像服務器共享同一個 IP 地址，中國大陸地區內只有6組根服務器鏡像（F，I（3臺），J，L）。當你對某個根服務器發出請求時，請求會被路由到該根服務器離你最近的鏡像服務器。所有的根域名服務器都知道所有的頂級域名服務器的域名和地址，如果向根服務器發出對 “jocent.me” 的請求，則根服務器是不能在它的記錄文件中找到與 “jocent.me” 匹配的記錄。但是它會找到 “me” 的頂級域名記錄，並把負責 “me” 地址的頂級域名服務器的地址發回給請求者。
• 頂級域名服務器：負責管理在該頂級域名服務器下注冊的二級域名。當根域名服務器告訴查詢者頂級域名服務器地址時，查詢者緊接着就會到頂級域名服務器進行查詢。比如還是查詢"jocent.me"，根域名服務器已經告訴了查詢者“me”頂級域名服務器的地址，“me”頂級域名服務器會找到 “jocent.me”的域名服務器的記錄，域名服務器檢查其區域文件，並發現它有與 “jocent.me” 相關聯的區域文件。在此文件的內部，有該主機的記錄。此記錄說明此主機所在的 IP 地址，並向請求者返回最終答案。
• 權限域名服務器：負責一個區的域名解析工作
• 本地域名服務器：當一個主機發出DNS查詢請求的時候，這個查詢請求首先就是發給本地域名服務器的。

1.3. 域名解析過程

域名解析總體可分爲兩大步驟，第一個步驟是本機向本地域名服務器發出一個DNS請求報文，報文裏攜帶需要查詢的域名；第二個步驟是本地域名服務器向本機迴應一個DNS響應報文，裏面包含域名對應的IP地址。從下面對jocent.me進行域名解析的報文中可明顯看出這兩大步驟。注意：第二大步驟中採用的是迭代查詢，其實是包含了很多小步驟的，詳情見下面的流程分析。

其具體的流程可描述如下：

1. 主機10.74.36.90先向本地域名服務器10.74.1.11進行遞歸查詢
2. 本地域名服務器採用迭代查詢，向一個根域名服務器進行查詢
3. 根域名服務器告訴本地域名服務器，下一次應該查詢的頂級域名服務器 dns.me的IP地址
4. 本地域名服務器向頂級域名服務器 dns.me進行查詢
5. 頂級域名服務器me告訴本地域名服務器，下一步查詢權限服務器dns.jocent.me 的IP地址
6. 本地域名服務器向權限服務器 dns.jocent.me進行查詢
7. 權限服務器 dns.jocent.me告訴本地域名服務器所查詢的主機的IP地址
8. 本地域名服務器最後把查詢結果告訴 10.74.36.90

其中有兩個概念遞歸查詢和迭代查詢，其實在整個描述的過程中已經體現的很明顯，這裏再說明一下：

• 遞歸查詢：本機向本地域名服務器發出一次查詢請求，就靜待最終的結果。如果本地域名服務器無法解析，自己會以DNS客戶機的身份向其它域名服務器查詢，直到得到最終的IP地址告訴本機
• 迭代查詢：本地域名服務器向根域名服務器查詢，根域名服務器告訴它下一步到哪裏去查詢，然後它再去查，每次它都是以客戶機的身份去各個服務器查詢

二. DNS協議報文格式

2.1 頭部

1. 會話標識（2字節）：是DNS報文的ID標識，對於請求報文和其對應的應答報文，這個字段是相同的，通過它可以區分DNS應答報文是哪個請求的響應
2. 標誌（2字節）：
   

   QR（1bit）	查詢/響應標誌，0爲查詢，1爲響應
   opcode（4bit）	0表示標準查詢，1表示反向查詢，2表示服務器狀態請求
   AA（1bit）	表示授權回答
   TC（1bit）	表示可截斷的
   RD（1bit）	表示期望遞歸
   RA（1bit）	表示可用遞歸
   rcode（4bit）	表示返回碼，0表示沒有差錯，3表示名字差錯，2表示服務器錯誤（Server Failure）

3. 數量字段（總共8字節）：Questions、Answer RRs、Authority RRs、Additional RRs 各自表示後面的四個區域的數目。Questions表示查詢問題區域節的數量，Answers表示回答區域的數量，Authoritative namesversers表示授權區域的數量，Additional recoreds表示附加區域的數量

 

2.2 正文

1. Queries區域1.1 查詢名：長度不固定，且不使用填充字節，一般該字段表示的就是需要查詢的域名（如果是反向查詢，則爲IP，反向查詢即由IP地址反查域名），一般的格式如下圖所示。1.2 查詢類型：
   

   類型	助記符	說明
   1	A	由域名獲得IPv4地址
   2	NS	查詢域名服務器
   5	CNAME	查詢規範名稱
   6	SOA	開始授權
   11	WKS	熟知服務
   12	PTR	把IP地址轉換成域名
   13	HINFO	主機信息
   15	MX	郵件交換
   28	AAAA	由域名獲得IPv6地址
   252	AXFR	傳送整個區的請求
   255	ANY	對所有記錄的請求

   這裏給一個域名，可用來模擬DNS的查詢類型，可以選擇不同的類型，比如A，PTR等玩一下， https://www.nslookuptool.com/chs/       
   1.3 查詢類：通常爲1，表明是Internet數據

2. 資源記錄(RR)區域（包括回答區域，授權區域和附加區域）

該區域有三個，但格式都是一樣的。這三個區域分別是：回答區域，授權區域和附加區域

2.1. 域名（2字節或不定長）：它的格式和Queries區域的查詢名字字段是一樣的。有一點不同就是，當報文中域名重複出現的時候，該字段使用2個字節的偏移指針來表示。比如，在資源記錄中，域名通常是查詢問題部分的域名的重複，因此用2字節的指針來表示，具體格式是最前面的兩個高位是 11，用於識別指針。其餘的14位從DNS報文的開始處計數（從0開始），指出該報文中的相應字節數。一個典型的例子，C00C(1100000000001100，12正好是頭部的長度，其正好指向Queries區域的查詢名字字段)。

2.2 查詢類型：表明資源紀錄的類型，見1.2節的查詢類型表格所示 

2.3 查詢類：對於Internet信息，總是IN

2.4 生存時間（TTL）：以秒爲單位，表示的是資源記錄的生命週期，一般用於當地址解析程序取出資源記錄後決定保存及使用緩存數據的時間，它同時也可以表明該資源記錄的穩定程度，極爲穩定的信息會被分配一個很大的值（比如86400，這是一天的秒數）。

2.5. 資源數據：該字段是一個可變長字段，表示按照查詢段的要求返回的相關資源記錄的數據。可以是Address（表明查詢報文想要的迴應是一個IP地址）或者CNAME（表明查詢報文想要的迴應是一個規範主機名）等。

回到頂部

三. Wireshark分析DNS協議

下面給出wireshark抓包的記錄，感興趣的可以根據上面介紹的協議報文格式手動解析一下，相信會有很大收穫。

3.1 請求報文

3.2 響應報文

 

DNS相關的命令小貼士：

• Windows環境下清空DNS緩存的命令是 ipconfig/flushdns 也可以通過重啓DNS client 和 DHCP client 兩項服務清空DNS緩存
• Windows環境下可以用命令 ipconfig /displaydns  來查看DNS緩存的內容
• nslookup 命令可以用來查看域名對應的IP地址，比如 nslookup jocent.me

本文撰寫過程中參考了以下幾篇博文的內容，現列出鏈接如下：

• http://www.iprotocolsec.com/2012/01/13/%E4%BD%BF%E7%94%A8wireshark%E5%AD%A6%E4%B9%A0dns%E5%8D%8F%E8%AE%AE%E5%8F%8Adns%E6%AC%BA%E9%AA%97%E5%8E%9F%E7%90%86/
• http://blog.csdn.net/yipiankongbai/article/details/25031461
• http://blog.chinaunix.net/uid-24875436-id-3088461.html