實驗目的
①,掌握DNS域名解析過程
②,熟悉DNS報文格式
實驗原理
使用ping訪問域名地址,利用wireshark網絡抓包工具,抓包分析DNS域名解析協議過程
DNS域名解析原理
域名解析過程
域名到IP地址的解析過程的要點如下:當某一個應用進程需要把主機名解析為IP地址時,該應用進程就調用解析程序(resolver),並成為DNS的一個客戶,把待解析的域名放在DNS請求報文中,以UDP用戶數據報方式發給本地域名服務器(使用UDP是為了減少開銷)。本地域名服務器在查找域名后,把對應的IP地址放在回答報文中返回。應用進程獲得目的主機的IP地址后即可進行通信。
若本地域名服務器不能回答該請求,則此域名服務器就暫時成為DNS中的另一個客戶,並向其他域名服務器發出查詢請求。這種過程直至找到能夠回答該請求的域名服務器為止。
DNS客戶端服務按以下順序查詢DNS服務器
-
DNS客戶端服務將名稱查詢發送到首選適配器的DNS服務器列表上的第一個DNS服務器,並等待一秒鍾以進行響應。
-
如果DNS客戶端服務在一秒鍾內未收到第一台DNS服務器的響應,則會將名稱查詢發送到仍在考慮中的所有適配器上的第一台DNS服務器,並等待兩秒鍾以進行響應。
-
如果DNS客戶端服務在兩秒鍾內未收到任何DNS服務器的響應,則DNS客戶端服務會將查詢發送到仍在考慮中的所有適配器上的所有DNS服務器,並等待另外兩秒鍾以響應。
-
如果DNS客戶端服務仍然沒有收到來自任何DNS服務器的響應,它將名稱查詢發送到仍在考慮中的所有適配器上的所有DNS服務器,並等待四秒鍾以進行響應。
-
如果DNS客戶端服務未從任何DNS服務器接收到響應,則DNS客戶端會將查詢發送到仍在考慮中的所有適配器上的所有DNS服務器,並等待八秒鍾以獲取響應。
如果DNS客戶端服務收到肯定的響應,它將停止查詢名稱,將響應添加到緩存中並將響應返回給客戶端。
如果DNS客戶端服務在8秒鍾內未收到任何服務器的響應,則DNS客戶端服務將超時。另外,如果尚未從指定適配器上的任何DNS服務器接收到響應,則在接下來的30秒內,DNS客戶端服務將以超時響應發往該適配器上服務器的所有查詢,並且不查詢這些服務器。
如果DNS客戶端服務在任何時候都收到來自服務器的否定響應,則它將在搜索過程中將該適配器上的每個服務器都排除在考慮范圍之外。例如,如果在步驟2中,備用適配器A上的第一台服務器給出了否定響應,則DNS客戶端服務將不會將查詢發送到備用適配器A列表上的任何其他服務器。
DNS客戶端服務跟蹤哪些服務器更快速地回答名稱查詢,並根據服務器對名稱查詢的回復速度將服務器在列表中上移或下移。
准備工作
查看本機 IP
ipconfig
查看電腦配置的本地域名服務器地址
ipconfig /all
查看“必應”網站域名對應的 IP 地址
nslookup www.biying.com
DNS報文格式
整個DNS報文格式主要分為 3 部分內容,即基礎結構部分、問題部分、資源記錄部分。(對報文格式的具體分析,請查看下面抓包數據分析)
准備工作完成
至此,我們已經知道以下幾點內容
①,本機IP地址(IP6地址 fe80::3995:c67c:ccbd:3ba4,IP4地址 192.168.1.6)
②,本地域名服務器地址(IP6地址 fe80::1,IP4地址 114.114.114,8.8.8.8)
③,“必應”網站域名所對應的IP地址(202.89.233.100,202.89.233.101)
注:以上准備工作中所獲得的數據,在抓包數據中會涉及到,請明確知悉其含義
抓包操作
抓包流程
①,使用wireshark抓取網絡請求包,啟用開始捕獲
②,訪問www.biying.com網址(使用ping命令模擬訪問域名)
③,查看抓包數據(記得保存抓包數據,便於后續分析)
抓包數據分析
可以看到,訪問www.biying.com網址 ,產生了四條數據(將抓包報文使用了DNS過濾后的結果),兩次DNS請求(請求與響應配對存在);
第一次DNS請求查詢 www.biying.com 域名對應的IP4地址(A代表IP4);
第二次DNS請求查詢 www.biying.com 域名對應的IP6地址(AAAA代表IP6);
因為兩次查詢協議過程相同,故以第一次查詢內容來作為數據分析。
分析第一次查詢過程抓包數據
DNS請求報文數據如下
報文分析:
可以看到,網絡傳輸層使用 UDP 協議,端口號為 53
DNS報文基礎結構部分
每個字段含義如下。
- 事務 ID(Transaction ID):DNS 報文的 ID 標識。對於請求報文和其對應的應答報文,該字段的值是相同的。通過它可以區分 DNS 應答報文是對哪個請求進行響應的。
- 標志(Flags):DNS 報文中的標志字段。
- 問題計數(Questions):DNS 查詢請求的數目。
- 回答資源記錄數(Answers RRs):DNS 響應的數目。
- 權威名稱服務器計數(Authority RRs):權威名稱服務器的數目。
- 附加資源記錄數(Additional RRs):額外的記錄數目(權威名稱服務器對應 IP 地址的數目)。
其中Flags字段中每個字段的含義如下:
- QR(Response):查詢請求/響應的標志信息。查詢請求時,值為 0;響應時,值為 1。
- Opcode:操作碼。其中,0 表示標准查詢;1 表示反向查詢;2 表示服務器狀態請求。
- AA(Authoritative):授權應答,該字段在響應報文中有效。值為 1 時,表示名稱服務器是權威服務器;值為 0 時,表示不是權威服務器。
- TC(Truncated):表示是否被截斷。值為 1 時,表示響應已超過 512 字節並已被截斷,只返回前 512 個字節。
- RD(Recursion Desired):期望遞歸。該字段能在一個查詢中設置,並在響應中返回。該標志告訴名稱服務器必須處理這個查詢,這種方式被稱為一個遞歸查詢。如果該位為 0,且被請求的名稱服務器沒有一個授權回答,它將返回一個能解答該查詢的其他名稱服務器列表。這種方式被稱為迭代查詢。
- RA(Recursion Available):可用遞歸。該字段只出現在響應報文中。當值為 1 時,表示服務器支持遞歸查詢。
- Z:保留字段,在所有的請求和應答報文中,它的值必須為 0。
- rcode(Reply code):返回碼字段,表示響應的差錯狀態。
- 當值為 0 時,表示沒有錯誤;
- 當值為 1 時,表示報文格式錯誤(Format error),服務器不能理解請求的報文;
- 當值為 2 時,表示域名服務器失敗(Server failure),因為服務器的原因導致沒辦法處理這個請求;
- 當值為 3 時,表示名字錯誤(Name Error),只有對授權域名解析服務器有意義,指出解析的域名不存在;
- 當值為 4 時,表示查詢類型不支持(Not Implemented),即域名服務器不支持查詢類型;
- 當值為 5 時,表示拒絕(Refused),一般是服務器由於設置的策略拒絕給出應答,如服務器不希望對某些請求者給出應答,,或者服務器不希望進行某些操作(比如區域傳送zone transfer);
- 6-15 保留值,暫時未使用。
DNS報文問題查詢部分
每個字段含義如下:
- 查詢名(Name):一般為要查詢的域名,有時也會是 IP 地址,用於反向查詢。
- 查詢類型(Type):DNS 查詢請求的資源類型。通常查詢類型為 A 類型,表示由域名獲取對應的 IP4 地址。(更多類型如 AAAA,CANME,SOA,PTR,NS 等)
- 查詢類(Class):地址類型,通常為互聯網地址,值為 1。
那么,對於上面報文內容,翻譯過后的意思就是,“該報文為標准查詢(Opcode=0)請求(QR=1)報文,向本地域名服務器( IP 報文中目的地址為本地域名服務器地址,在上面准備工作中已經知道了)請求查詢,發起請求內容為 ‘獲取www.biying.com (Name=www.baidu.com)所對應的IP4地址(Type=A)’,期待本地域名服務器遞歸查詢(RD=1)請求”
DNS響應報文數據如下
報文分析:
對比請求報文發現,響應報文“基礎結構部分”和請求報文結構對應相同,並返回字段說明服務器支持遞歸查詢(RA=1),服務器響應記錄的名稱服務器為非權威服務器(AA=0),產生了4條響應記錄(Answers RRs = 4),響應報文中多了answers字段且有4條數據
響應報文中,Queries字段完全和請求報文相同,answers字段為DNS資源記錄部分的內容。
DNS資源記錄
每個字段含義如下:
- Name:DNS 請求的域名。
- Type:資源記錄的類型,與問題部分中的查詢類型值是一樣的。
- Class:地址類型,與問題部分中的查詢類值是一樣的。
- Time to live:生存時間,以秒為單位,表示資源記錄的生命周期,一般用於當地址解析程序取出資源記錄后決定保存及使用緩存數據的時間。它同時也可以表明該資源記錄的穩定程度,穩定的信息會被分配一個很大的值。
- Data length:資源數據的長度。
- 資源數據:表示按查詢段要求返回的相關資源記錄的數據。(如 Address :IP地址,CNAME:服務器別名 ,等)
那么,answers字段內容,翻譯過來意思就是(從第一條開始按順序翻譯),
①,'www.biying.com'域名的別名有'www-biying-com.cn.a-0001.a-msedge.net';
②,'www-biying-com.cn.a-0001.a-msedge.net'域名的別名為'china.bing123.com';
③,'china.bing123.com'域名對應的IP4地址有'202.89.233.101';
④,'china.bing123.com'域名對應的IP4地址有'202.89.233.100';
通過以上報文結果數據分析,獲取到的數據結果和我們准備工作所獲取的結果是一致的。
實驗過程遇到的問題
問題一,為什么會同時查詢域名對應的IP4地址和IP6地址;
問題二,實驗過程中會出現同時向兩個域名服務器查詢同一內容(見截圖,對8.8.8.8域名服務器重新查詢了請求);
原因:因為主服務器沒有正常響應,導致DNS客戶端像備用服務器重新發起啦請求。
查閱資料知曉本機域名服務器配置區分首選域名服務器和備用域名服務器,當首選服務器不能響應時候,就會由備用域名服務器響應。(我電腦配置了兩個)
這個只是原理,那么從報文數據如何體現主服務器不能工作響應了呢?
起初我一直想着通過DNS的響應來查找返回錯誤信息,此路不通。后來查看報文發現啦ICMP協議的報文,ICMP協議的主要功能,[1]給送信者的錯誤通知;[2]送信者的信息查詢。最后通過查找DNS請求對應的ICMP報文(通過事務ID關聯報文),發現響應報文確實返回了“目標主機不可到達,目標端口不可到達”,報文截圖如下
通過對比報文事務ID(截圖中事務ID為0xda90),發現以下三條報文是相互關聯的
(注:如果IPv4不能將數據報傳送到目標主機,則路由器上的或目標主機上的ICMP會向主機發送一條“無法到達目標”。因為是由目標主機發出的ICMP報文,所以IP報文中的src地址所代表的DNS域名服務器地址,其實也就是我們DNS通信的目標網絡地址)
通過上面截圖分析,可以看到,ICMP報文返回信息說首選域名服務器(114.114.114.114)不可達,從而本機向備用域名服務器重新發起了請求。
問題三,出現多個相同事務ID的DNS請求
原因,由於網絡卡頓,一定時間內DNS響應沒有應答的話,DNS客戶端就會嘗試重新發起請求。
圖中標框的請求,我們可以發現,這四個請求的內容是一樣的,事務ID也是一樣的,但是transaction ID 是用來用來唯一標識DNS報文的,現在卻出現了四個相同事務ID的請求。
通過分析請求,響應報文發現,出現如下報文內容,
請求
響應
'[Expert Info (Warning/Protocol): DNS query retransmission. Original request in frame 3]' ,意思是說DNS查詢重傳,原始請求在編號3的幀里面(即截圖中第一個請求)
'[Expert Info (Warning/Protocol): DNS response retransmission. Original response in frame 45]',意思是說DNS響應重傳,原始響應在編號45的幀里面
由於網絡不穩定導致重傳(在抓包過程中,明顯感覺到網絡卡頓,偶爾還會出現丟包現象)
實驗不足
本實驗對於DNS緩存(瀏覽器緩存 --> 系統緩存 --> 路由器緩存 --> ISP緩存)問題未涉及分析實驗
對於DNS請求轉發過程(轉發過程在在域名服務器上,而不在本機上進行轉發)未涉及分析驗證(推薦看阮老師博客文章-DNS原理入門)
實驗總結
附錄
參考鏈接
DNS報文格式解析http://c.biancheng.net/view/6457.html
https://blog.csdn.net/itermeng/article/details/77833356
https://blog.51cto.com/13444271/2125344
DNS Processes and Interactions
感謝ypxka技術指導和建議❤️