對DNS域名系統的抓包分析
一、實驗目的
通過網路抓包試驗，深刻理解TCP/IP協議簇中DNS域名系統的使用方式與報文具體格式與含義，加強對DNS的理解與應用。
二、相關原理
2.1、DNS的定義
DNS是域名系統(DomainNameSystem)的縮寫，它是由解析器和域名伺服器組成的。域名伺服器是指保存有該網路中所有主機的域名和對應IP地址，並具有將域名轉換為IP地址功能的伺服器。其中域名必須對應一個IP地址，而IP地址不一定有域名。
域名系統採用類似目錄樹的等級結構。域名伺服器為客戶機/伺服器模式中的伺服器方，它主要有兩種形式：主伺服器和轉發伺服器。將域名映射為IP地址的過程就稱為「域名解析」。在Internet上域名與IP地址之間是一對一（或者多對一）的，域名雖然便於人們記憶，但機器之間只能互相認識IP地址，它們之間的轉換工作稱為域名解析，域名解析需要由專門的域名解析伺服器來完成，DNS就是進行域名解析的伺服器。DNS命名用於Internet等TCP/IP網路中，通過用戶友好的名稱查找計算機和服務。
當用戶在應用程序中輸入DNS名稱時，DNS服務可以將此名稱解析為與之相關的其他信息，如IP地址。因為，你在上網時輸入的網址，是通過域名解析系統解析找到了相對應的IP地址，這樣才能上網。其實，域名的最終指向是IP。
2.2、DNS的構成
在IPV4中IP是由32位二進位數組成的，將這32位二進位數分成4組每組8個二進位數，將這8個二進位數轉化成十進位數，就是我們看到的IP地址，其範圍是在～255之間。因為，8個二進位數轉化為十進位數的最大範圍就是～255。現在已開始試運行、將來必將代替IPv4的IPV6 中，將以128 位二進位數表示一個IP地址。
2.3、DNS 的查詢
DNS查詢可以有兩種解釋，一種是指客戶端查詢指定DNS伺服器上的資源記錄（如 A 記錄），另一種是指查詢FQDN名的解析過程。
一、查詢 DNS伺服器上的資源記錄
您可以在Windows 平台下，使用命令行工具，輸入nslookup ，返回的結果包括域名對應的IP 地址（ A 記錄）、別名（ CNAME記錄）等。除了以上方法外，還可以通過一些DNS查詢站點如國外的國內的查詢域名的DNS信息。
二、 FQDN名的解析過程查詢
若想跟蹤一個FQDN名的解析過程，在LinuxShell下輸入 digwww+trace ， 返回的結果包括從跟域開始的遞歸或迭代過程，一直到權威域名伺服器。
2.4、DNS 的報文格式
DNS 報文的首部：
DNS 報文首部的後面是可變部分，包括四個小部分。
問題部分由一組問題記錄組成。
DNS報文的其餘三個部分是回答部分、授權部分和附加信息部分，附加信息包含回答部分和授權部分返回的資源所要求的附加信息（如 IP 地址）。這三部分均由一組資源記錄組成，而且僅在應答報文中出現。一條資源記錄描述一個域名。
三、結合具體抓包實例進行的分析
3.1、協議數據包窗口
從包到達的時間，順序以及源和目的IP 地址可知，這是一對DNS請求與應答報 文。下圖為1號包與2號包中 DNS段的報文分析注釋，由此可證明，包1為DNS 請求報文，包2為包1的應答報文，請求與應答報文的到達間隔時間為0.000349s ，它們的標識欄位都為0x001，用於相互匹配。
因為 DNS請求報文的目的是請求DNSServer的IP地址，故包1的源IP地址為本機 IP ，目的IP 地址為 DNS伺服器的IP，包 2與包1 相反。
3.2、協議樹窗口
DNS請求報文：
DNS應答報文：
可以看出，DNS請求報文與應答報文鏈路層的MAC地址相反，請求報文中的源物理地址為本機的物理地址，這與IP地址相對應。此外，DNS請求報文與應答報文傳輸層中UDP的源埠與目的埠相反，其中請求報文UDP的源埠為客戶機動態申請的本地埠，目的埠為DNS所固有的53號周知埠。這兩點都體現了DNS請求報文與應答報文間的請求-應答關係。DNS請求報文與應答報文協議樹窗口顯示的協議層次與網路協議的層次對應相同，如下表：
3.3、物理層節點
DNS請求報文
DNS應答報文
以上兩張圖分別給出了DNS請求報文與應答報文的時間參數、包號、長度與協議層次，在此不一一細說。但是，我們可以很清楚的看出，DNS請求報文的長度為72位元組，而應答報文的長度為123 位元組，比請求報文長得多。這是由於在DNS應答報文中，具有請求報文所沒有的回答部分、授權部分與附加部分，在下面的應答報文分析中會具體說明。
3.4、數據鏈路層節點
DNS請求報文：
DNS應答報文：
由上圖可以更明顯的看出，DNS請求與應答報文的源與目的MAC地址的相反現象。此外，DNS請求與應答報文乙太網協議中的類型均為IP，即在 DNS協議層次中網 絡層協議為IP，這體現了DNS作為TCP/IP 協議簇中協議的特點。
3.5、IP節點
DNS請求報文：
DNS應答報文：
DNS請求與應答報文IP 層相同點：
版本號： IPv4
首部長度： 20 位元組，沒有其他選項
服務類型：最低優先順序的一般服務 片偏移： 0，無分片
協議標識： UDP（0x11H）
DNS請求與應答報文IP 層不同點： 數據報長度：上文已有分析。
標識不同，因為請求與應答為兩個不同的報文，信源機給予的用於區分分片的標識不同。
生存時間不同，請求報文為64，應答報文為60。
校驗和不同， DNS請求與應答報文IP 層首部不同，故校驗和不同。源與目的IP 地址不同，原因在前面的分析中已經說明。
3.6、UDP 節點
DNS請求報文：
DNS應答報文：
DNS請求與應答報文的源與目的埠相反，原因在前面的分析中已經說明。
請求報文UDP長度為 53 位元組，應答報文UDP長度為 89 位元組。
3.7、DNS節點
3.7.1DNS 請求報文首部：
標識欄位： 0x0001，用於匹配請求與響應
標誌欄位： 0x0100H
QR： 0，為請求報文
OpCode：0000（0），標準查詢（正向解析）
AA： 0，此欄位只在伺服器的響應中有效，在上圖中不顯示
TC： 0，報文沒有被截斷
RD： 1，請求伺服器進行遞歸解析
RA： 0，此欄位只在伺服器的響應中有效，在上圖中不顯示3
比特保留位： 000
rCode： 0000，沒有錯誤問題記錄數： 1
回答記錄數： 0（DNS請求報文此欄位為0）
授權記錄數： 0（DNS請求報文此欄位為0）
附加信息記錄數：0（ DNS請求報文此欄位為0）
問題部分：
詢問類型： PTR，數值為 1，反向解析。
詢問類： IN，數值為 1，表示網際網路協議。
3.7.2、DNS 應答報文
首部：
標識欄位： 0x0001，用於匹配請求與響應，此處與DNS請求報文相匹配。
標誌欄位： 0x8180H
QR： 1，為應答報文
OpCode：0000（0），標準查詢（正向解析） （與請求報文相同）
AA： 0，回答的伺服器是該域的授權伺服器
TC： 0，報文沒有被截斷
RD： 1，請求伺服器進行遞歸解析（與請求報文相同）
RA： 1，伺服器支持遞歸解析（回應RD）
3 比特保留位： 000 rCode： 0000，沒有錯誤
問題記錄數： 1
回答記錄數： 1
授權記錄數： 1 附加信息記錄數：0 問題部分：
與請求報文相同，即作為DNS請求報文的回答，DNS應答報文的問題部分就是請 求報文的問題部分的拷貝。
回答部分：
類型： PTR，數值為1，指針記錄， IP 到域名的解析。 類： IN，數值為1，表示網際網路協議。
生存時間： 1day
資源數據長度：10 位元組
資源數據： dnscache（DNS緩存伺服器）
授權部分：
四、體會與小結
經過本次對DNS 域名系統的抓包實驗的分析，我們加深了對DNS域名系統的理解和掌握。首先從DNS 的含義上，DNS是由解析器和域名伺服器組成的，其中，域名伺服器是指保存有該網路中所有主機的域名和對應IP地址，並具有將域名轉換為IP 地址功能的伺服器。 它主要有主伺服器和轉發伺服器兩種形式。在理解了DNS 的含義後，我又對其具體構成進行了深入的掌握和理解。本次實驗，也讓我對 DNS 的理解達到了理論與實際相結合的程度。另外，我們也通過 實驗初步掌握了軟體Wireshark 的使用，也讓我們感受到了親自動手進行實驗的樂趣 .
報班考證請掃我
TAG:SPOTO思博網路 |