本文轉載自 公眾號：科來

前言

網絡協議是計算機網絡進行數據交換而建立的規則、標準或約定的集合。隨著互聯網的飛速發展，應用層協議越來越豐富，為了更好保障我們的業務，熟悉并掌握常用應用層網絡協議成為每位互聯網大佬必須的知識儲備，也是熟練掌握流量分析技術的基礎。今天我們從流量視角出發，和大家一起聊聊DNS協議。

本期互動問題，歡迎大家評論區一起聊聊：

DNS可以使用TCP作為傳輸協議進行交互嗎？

DNS相關概念

域名系統（Domain Name System，縮寫：DNS）是互聯網的一項服務。它作為將域名和IP地址相互映射的一個分布式數據庫，能夠使人更方便地訪問互聯網。DNS協議是用來將域名轉換為IP地址（也可以將IP地址轉換為相應的域名地址）的應用層協議。

看了概念，大家肯定會有很多疑問，譬如這個分布式數據庫會很龐大，真有主機能存下所有記錄？域名比IP地址更好記憶？域名的IP變化了怎么辦？……答案就是：使用“樹狀名字空間”！舉例如下：

如圖，根服務器只管理根域名，頂級服務器管理頂級域名，以此類推。這樣就不需要一臺服務器維護整個域名到IP的映射表。

用www.colasoft.com.cn舉例說明如下：

解析時，就會先找根服務器，根服務器應該找管理“cn”這個頂級域的頂級域名服務器，再找管理“com”的二級域名服務器。

以此類推，最后找到www.colasoft.com.cn域名到IP的映射。

DNS原理

1. DNS完整查詢過程

一圖勝千言，直接上圖：

當我們在瀏覽器中訪問域名www.colasoft.com.cn，整個域名解析過程是這樣的：

首先嘗試本地解析：

（1） 操作系統會檢查自己本地的hosts文件是否有這個網址映射關系？如果有，就調用這個IP地址映射，直接完成域名解析（本地解析，此時同樣不會產生DNS數據包）；

注：Windows的host文件在C:\Windows\System32\drivers\etc\hosts；Linux在/etc/hosts；

（2） 如果瀏覽器訪問過該域名，并且DNS記錄被瀏覽器進行了緩存，則會根據瀏覽器緩存記錄直接進行訪問（此時不會產生DNS數據包）；

（3） 如果前2步沒有結果，則會真正發出DNS查詢數據包，訪問到本地“DNS解析器緩存”。這里“DNS解析器緩存”是個泛稱（瀏覽器緩存其實也是它的一種，因為不產生數據包，所以單獨列為了一個步驟），比如家用小路由器帶DNS緩存、防火墻帶DNS緩存功能等。

本地解析無結果，則開始向本地DNS服務器發請求包：

（4） 訪問本地DNS服務器（TCP/IP參數中設置的首選DNS服務器）。我們正常在客戶端抓到的DNS數據包，其實就是客戶端和本地服務器交換的DNS數據包（注意，抓包位置不同，看到的數據包是不同的，如果在客戶端進行抓包，是看不到DNS服務器之間交互過程的）。如果要查詢的域名，包含在本地配置區域資源中，則返回解析結果給客戶端，完成域名解析，此解析具有權威性（后文中解釋什么是權威回答）。

（5） 如果要查詢的域名不是本地DNS服務器區域解析，但該服務器緩存了客戶端查詢的網址映射關系，則調用這個IP地址映射返回解析結果，完成域名解析，此解析不具有權威性。

本地DNS服務器無映射結果，則本地DNS服務器開始向前文介紹的根服務器、頂級域名服務器、二級域名服務器等發起迭代查詢（后文解釋遞歸和迭代）：

（6） 如果本地DNS服務器本地區域文件與緩存解析都失效，則根據本地DNS服務器的設置（是否設置轉發器）進行查詢，如果未用轉發模式，本地DNS就把請求發至13臺根DNS（或根的鏡像服務器），根DNS服務器收到請求后會判斷這個域名(.cn)是誰來授權管理，并會返回一個負責該頂級域名服務器的一個IP。本地DNS服務器收到IP信息后，將會聯系負責.cn域的這臺服務器。負責.cn域的頂級域名服務器收到請求后，如果自己無法解析，就會找一個管理com.cn域的下一級DNS服務器地址給本地DNS服務器。當本地DNS服務器收到這個地址后，就會找com.cn域服務器。重復上面的動作進行查詢（迭代過程），直至找到(http://www.colasoft.com.cn)主機的IP映射關系。

（7） 如果用的是轉發模式（上圖中的Q8和A8），此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析，上一級服務器如果不能解析，或找根DNS或把轉請求轉至上上級，以此循環。

注意：不管是不是轉發模式，最終查詢結果都是返回給本地DNS服務器，由本地DNS服務器把結果再交給客戶端。

以上便是DNS解析的全過程，需要再次提醒大家，如果是在客戶端進行抓包分析DNS協議，只會看到客戶端和本地DNS的交互過程：

2. 遞歸查詢和迭代查詢

（1） 迭代查詢

如下圖，本地DNS服務器先問根域名服務器，根域名服務器將頂級域名服務器地址返回給本地DNS服務器；本地DNS服務器再去找頂級域名服務器查詢，頂級域名服務器將對應二級域名服務器地址返回給本地DNS服務器；然后本地DNS服務器去找二級域名服務器查詢，二級域名服務器將最終結果給到本地DNS服務器。由此可見，每一次DNS查詢請求都是由本地DNS服務器發出，這種查詢方式稱之為迭代查詢。如下圖：

（2） 遞歸查詢

和迭代查詢不同，遞歸是本地域名服務將請求傳給根域名服務器，根域名服務器將請求傳遞給頂級域名服務器，頂級域名服務器再將請求傳給二級域名服務器；當二級域名服務器查到結果后，將結果返回給頂級域名服務器，頂級域名服務器將結果交給根域名服務器，根域名服務器將結果最終給到本地域名服務器。如下圖：

從上面兩種機制誰更好呢？從查詢效率和減輕重要服務器負擔為出發點，實際DNS在運行時遵循：客戶端到本地DNS服務器的查詢過程為遞歸查詢；本地DNS服務器到其他DNS服務器的查詢過程過迭代。下圖為客戶端到服務器的查詢包，期望遞歸查詢：

3. DNS資源記錄

DNS服務器就是根據資源記錄來返回DNS應答。以上圖這條資源記錄為例，各字段含義如下：

域名Domain：www.colasoft.com.cn；

生存周期TTL：600，遞歸服務器會緩存該資源記錄的時間，單位：秒；

網絡/協議類型class：IN，DNS在設計之初希望能支持不同的網絡，不同的協議，IN代表internet類，目前DNS系統主要支持的協議是IN；

資源記錄類型type：A，決定和域名關聯的信息種類，A記錄代表IPV4的主機地址；（資源記錄類型在后文流量解碼中詳述）

47.57.8.223：域名關聯的信息數據；

在請求數據包中，會提供要查詢DNS記錄的相關信息：

DNS流量解碼

DNS報文標準格式如下：

下面我們以訪問科來官網為例，在客戶端進行抓包，結果如圖：

1、DNS請求包

上圖中9號包為DNS請求包，詳細解碼如下：

主要字段說明如下：

從數據包中我們得到信息：

這是一個DNS請求包，查詢的問題數為1，域名為：secure.colasoft.com.cn，查詢類型為1（A記錄），互聯網類型為0x1（IN互聯網）。

2、DNS響應包

因為是在客戶端抓的數據包，所以本地DNS向域名服務器迭代查詢的過程是看不到的，只能看到本地DNS發送給客戶端的DNS響應包，前面圖中的10包為響應包：

能看到DNS響應包比請求包內容多了不少，除了“基礎結構部分”，多了“資源記錄部分”。

從資源記錄部分我們能看到，回答可能有多個。這是資源記錄的特殊性句定的，同一個域名的同一類型資源記錄可以同時有多條（默認的應答機制是輪詢），如：

www.google.com. 120 IN A 74.125.128.105

www.google.com. 120 IN A 74.125.128.106

www.google.com. 120 IN A 74.125.128.147

在部分場景中，同一個域名可以存在不同類型的資源記錄：

www.google.com. 120 IN A 74.125.128.105

www.google.com. 120 IN A 74.125.128.106

www.google.com. 120 IN AAAA 240e:e1:8100:28::2:16

www.google.com. 120 IN A AAA 240e:e1:8100:28::2:17

一個域名，多個相同類型的資源記錄的集合稱為資源記錄集（RRset），RRset是DNS傳輸的基本單元，也就是說查詢一個域名對應的某種信息，DNS系統不會返回一條RR，而是返回一個資源記錄集RRset。

3、不同DNS記錄類型的數據包

不同的記錄類型，如下表：

下面解釋常見DNS的記錄類型，并展示對應數據包：

（1） A記錄

最常見的就是A記錄（A record），用于指定主機名（或域名）對應的IPv4地址。就是域名直接到IPv4的映射。

DNS請求數據包：

對應的DNS響應包：

（2） AAAA記錄

AAAA（AAAA record）記錄用于指定主機名（或域名）對應的IPv6地址。

DNS請求數據包：

對應的DNS響應包：

（3） NS記錄

NS（Name Server Record）記錄指明了由哪臺DNS服務器來解析特定域名的記錄。

例如，企業因規模較大采用了分布式網絡架構，擁有多個子域（本文因篇幅問題未進一步講解子域、區的概念，有興趣的讀者可深入了解），并且希望不同的子域由不同的DNS服務器解析，NS記錄就顯得尤為關鍵。通過設置NS記錄，可以確保名字解析請求被正確地分發到指定的DNS服務器上，從而提高解析效率和可靠性。

注意：NS記錄優先于A記錄，也就是說如果一個主機地址既存在NS記錄又存在A記錄，那么優先使用NS記錄，A記錄不生效。

DNS請求數據包：

對應的DNS響應包：

（4） CNAME記錄

CNAME （ Canonical NAME ），通常稱為別名或者規范名，它允許將多個名字映射到同一臺計算機。在多個子域名需要指向同一服務器的場景中非常有用。

例如，如果設置了test.mydomain.com作為www.colasoft.com的CNAME，意味著所有訪問test.mydomain.com的請求都會被路由到www.colasoft.com。CNAME的使用簡化了DNS記錄的管理，特別是在配置負載均衡或有多個服務共享同一服務器時。

注意：CNAME記錄不能與A記錄共存。如果一個域名已有一條A記錄，再添加CNAME記錄會導致沖突；CNAME記錄的目標只能是主機名，而不能是IP地址，這避免了直接依賴特定服務器的IP，增加了配置的靈活性。

DNS請求數據包：

對應的DNS響應包：

（5） MX記錄

MX（Mail Exchanger Record）專門用于郵件交換，定義了郵件服務器的優先級和地址，保證郵件能正確送達。通過設置MX記錄，可以指定哪些服務器負責處理發送到域名郵箱的郵件。

例如，設置mydomain.com的MX記錄指向mailserver.com，意味著所有發往@mydomain.com的郵件將被傳送到mailserver.com進行處理。

DNS請求數據包：

對應的DNS響應數據包：

（6） SOA記錄

SOA（Start of Authority）記錄是DNS（Domain Name System，域名系統）中的一種記錄類型，用于指定域的權威信息。它包含了關于域的管理和配置的基本信息，對于域的運行和管理至關重要。

SOA記錄通常包含以下部分信息：

Primary Name Server：主域名服務器的地址。

Email Address：負責管理該域的技術聯系人的電子郵件地址。

Serial Number：序列號，用于標識 DNS 記錄的最后更新時間。

Refresh Interval：刷新間隔，指輔助域名服務器向主域名服務器請求更新的頻率。

Retry Interval：重試間隔，指輔助域名服務器在未能成功更新后，再次嘗試更新的時間間隔。

Expire Time：過期時間，指輔助域名服務器在未收到更新的情況下，保持記錄有效的時間。

Minimum TTL (Time to Live)：最小 TTL ，指 DNS 解析器緩存記錄的最短時間。

DNS請求數據包：

對應DNS響應包：

（7） PTR記錄

PTR（ Pointer Record ） 指針記錄，代表“IP地址”與“主機名”的對應關系，作用剛好與A記錄相反。某些場景使用PTR記錄來檢驗客戶端的主機名稱是否可信。

DNS請求包：

對應DNS相應包：

（8） TXT記錄

TXT（文本）記錄，一般指為某個主機名或域名設置的說明。

例如，在TXT記錄中填寫SPF（SPF是一種郵件安全策略框架，不在本文講解范圍內）記錄格式數據，進而提升郵件的發送成功率，下面以qq.com為例，看數據包的解碼

DNS請求包：

對應DNS響應包：

4、響應包中的響應狀態碼

如果DNS查詢不成功，找到響應包中的RCODE字段是關鍵：

參考RFC2136，狀態碼有以下幾種：

下面對經常遇見的4種狀態碼作詳細說明：

（1） 狀態碼“0”NOERROR

代表域名正常解析到記錄，說明解析成功。

（2） 狀態碼“2”SERVFAIL

遞歸DNS服務器至權威服務器的網絡不通，或者DNS服務器發生錯誤，則會導致SERVFAIL。

如：客戶端向遞歸服務器發起DNS解析，由于網絡問題，遞歸服務器向權威DNS解析超時，此時遞歸服務器會向向客戶端應答SERVFAIL。

（3） 狀態碼“3”NXDOMAIN

解析某一域名，此域名沒有任何類型的解析記錄。

如：客戶端向DNS服務器解析ww123.colasof.tcom 的錯誤A記錄，服務器應答碼為NXDOMAIN,并附帶test.com 的SOA。

（4）狀態碼“4”REFUSED

名稱服務器出于策略或安全原因拒絕執行指定的操作。

如：客戶向DNS服務器發起www.colasoft.com.的查詢，此時DNS服務器需要對外遞歸查詢，但服務器沒有開啟DNS遞歸功能。這樣DNS就向客戶端相應REFUSED。

DNS常見安全問題及流量分析舉例

DNS協議的開發年限較早，且使用廣泛，不可避免的存在一些安全風險。根據面臨的攻擊類型，大概可以把風險分為4類，如下圖：

這里我們不再一一介紹了，從流量角度選2個分析舉例。

例1：DNS放大攻擊

分析：放大攻擊的原理，主要是利用了DNS請求大小和DNS響應大小的不對等（前面我們在解碼中已經看到，響應會多出RR應答集部分）。攻擊者如果通過精心設計，讓被控的僵尸機（多臺）把請求包的原IP替換為被攻擊者的IP地址，通過向遞歸DNS服務器（多臺）發送很小的請求包（請求類型為ANY），讓被攻擊者收到很大的響應包。這樣，就會在短時間內讓被攻擊者收到超出自身接收能力的數據，造成帶寬阻塞或宕機。如下圖：

如果是同網段內主機發起的攻擊，則可以在請求包中看到請求的類型為ANY；若攻擊者不在我們抓包點所在網絡內，則只會看到大量的響應包。在CSNAS中看到的流量如下：

流量特征：原地址為偽造IP（無法溯源）；接收響應的都是同一臺主機；；短時間內出現流量突發；DNS流量占比極高。

防御辦法：采用DNSSEC技術；引入IDPS設備；提取DNS攻擊流量特征，對包含此特征的流量進行過濾清洗等。

例2：典型的DNS隧道

分析：DNS隱蔽隧道原理大致如下圖（本文不再詳述）

流量特征：會看到大量的DNS請求和響應，他們的頂級域名和二級域名相同，在三級域名中會攜帶通信信息（外人無法看懂內容，需要翻譯）。

在CSNAS中流量顯示如圖：

防御辦法：提取相關流量特征進行告警；封禁攻擊者IP等。

結語

本文從流量側對DNS的概念、原理、解碼及分析舉例等多維度進行了講解，大家通過看數據包可以更直觀的看到DNS的真實工作過程。DNS是一個非常重要的應用層協議，掌握和了解DNS協議對我們運維、安全工作都巨大幫助！希望閱讀本文能讓大家對DNS協議有了更深的認識。后面我們會繼續對其他應用層協議作講解，請讀者們持續關注~

還記得開篇的互動問題嗎？

DNS可以使用TCP作為傳輸協議進行交互嗎？

看了這篇文章，你有什么新的想法？歡迎在評論區留言和我們交流~

- End -