# 一、DNS基礎知識：
## 1.DNS簡介:
DNS 域名服務，用於建立 域名與 ip地址的 一對一 對映。DNS 將域名轉換為 IP地址，以便瀏覽器能夠載入 Internet 資源。 類似於一個翻譯系統，將xxx.com 翻譯為 ip地址（如：192.0.2.254），這種轉換髮生在幕後，因此使用者只需記住域名，而不需要記住難記的IP
## 2.DNS資料包：
DNS資料包使用UDP進行封裝，至於為什麼使用UDP進行封裝，可參考 [為什麼DNS使用UDP協議？]( https://draveness.me/whys-the-design-dns-udp-tcp/) 下面是DNS報文格式：  * Transaction ID（16bit）：事務ID，區分DNS應答報文對應哪個請求報文，DNS查詢報文與DNS響應報文的會話ID相同，表示是對這個查詢作出的響應。 * Queries：其中包括查詢的域名，查詢的型別，查詢的類。 查詢的型別，通常是A型別，表示要查的是域名對應的IP地址。第3節會進行詳細介紹。 查詢類：地址型別，通常為網際網路地址，值為1 * Answers：一般在響應包，在請求包為空，主要包括name，type，address等，name表示要查的域名，type表示型別，同queries區域的型別，address 即返回的IP地址。 ​
若想知道詳細報文格式，可參考[DNS報文格式解析（非常詳細）](http://c.biancheng.net/view/6457.html)

## 3.DNS記錄型別： DNS記錄是用於解析的資料，最常見的3種記錄為：NS記錄、A記錄、CNAME記錄。
### NS記錄
如果DNS給你迴應一條NS記錄，就是告訴你，這個傢伙是這個域的權威DNS，有事你去問它。 比如在com的DNS裡，記錄著baidu.com這個域的DNS，長的大概是這個樣子： ```html baidu.com. NS ns1.baidu.com. baidu.com. NS ns2.baidu.com. baidu.com. NS ns3.baidu.com. ``` 這三條記錄，就是說ns1.baidu.com、ns2.baidu.com、ns3.baidu.com(以下簡稱ns1、ns2、ns3)都是baidu.com域的權威DNS，問任意其中一個都可以（一般都是順序問的，如果連不上第一個，就去找第二個）。 `注意，域名後面會比我們平時見到的多一個“.”，這就代表了根，嚴格地說，所有域名後面都應該有這一個“.”的，比如完整的www.baidu.com域名應該是www.baidu.com.，也可以把所有域名都看作有一個.root的字尾，比如www.baidu.com.root，但由於每個域名都有這個字尾，所以乾脆就都省略了。` 當然在com的權威域名伺服器，也記錄ns1，ns2，ns3這幾個的ip地址，會一併返回讓解析器去找這幾個伺服器解析。
### A記錄
A記錄就是最經典的域名和IP的對應，在ns1.baidu.com裡面，記錄著百度公司各產品的域名和IP的對應關係，每一個這樣的記錄，就是一個A記錄，比如下面的3個A記錄（隨意舉的例子，IP都是隨意寫的）。 ``` image.baidu.com A 1.2.3.4 wenku.baidu.com A 5.6.7.8 tieba.baidu.com A 9.10.11.12 ``` 如果有人問ns1.baidu.com：“wenku.baidu.com的IP是多少？”，ns1就會找到對應的A記錄或者CNAME記錄並返回。
### CNAME記錄
這種記錄比較有趣，你問DNS一個域名，它回CNAME記錄，意思是說，你要解析的這個域名，還有另一個別名，你去解析那個好了。 比如，在ns1中，其實並沒有`www.baidu.com`的A記錄，而是一個CNAME記錄： ``` www.baidu.com CNAME www.a.shifen.com ``` 這就是在告訴遞迴解析器，`www.baidu.com`的別名是`www.a.shifen.com`，去解析`www.a.shifen.com`吧
### 其他記錄型別
| 型別 | 描述 | | ---------- | -------------------------------------------- | | A記錄 | 儲存域名的IPv4地址的記錄 | | AAAA記錄 | 儲存域名的IPv6地址的記錄 | | NS 記錄 | 儲存 DNS 條目的權威域名伺服器 | | CNAME 記錄 | 將一個域或子域轉發到另一個域，不提供 IP 地址 | | MX 記錄 | 將郵件定向到電子郵件伺服器 | | TXT 記錄 | 可使管理員在記錄中儲存文字註釋 | | SOA 記錄 | 儲存域的管理資訊 | | SRV 記錄 | 指定用於特定服務的埠 | | PTR 記錄 | 把ip地址轉化為域名 |
## 4.DNS伺服器型別：
### DNS遞迴解析器 也可以當作local DNS，也稱為DNS解析器。是DNS查詢中的第一站，作為客戶端與 DNS 域名伺服器的中間人。從 Web 客戶端收到 DNS 查詢後，遞迴解析器將使用快取的資料進行響應，或者將向根域名伺服器傳送請求，接著向 TLD 域名伺服器傳送另一個請求，然後向權威性域名伺服器傳送最後一個請求。收到來自包含已請求 IP 地址的權威性域名伺服器的響應後，遞迴解析器將向客戶端傳送響應。 大多數 Internet 使用者使用他們 ISP 提供的遞迴解析器，但還有其他可用選擇；例如 Google的8.8.8.8。 ### 根域名伺服器 一共有13個根域名伺服器（並不表示只有13臺計算機，13種類型），解析器查詢的第一站，根域名接收到查詢後，告知相應的頂級域名伺服器（TLD DNS）所在域地址，如.com域。 ### 頂級域名伺服器 例如，.com TLD 域名伺服器包含以“.com”結尾的每個網站的資訊。如果使用者正在搜尋 baidu.com，則在收到來自根域名伺服器的響應後，遞迴解析器將向 .com TLD 域名伺服器傳送查詢，然後將通過針對該域的權威性域名伺服器進行響應。 ### 權威域名伺服器 ​ 遞迴解析的最後一站，查詢IP地址的最後一步。此時根據要查詢的域名，返回相應的IP地址或其他型別記錄。
## 5.DNS解析過程： 
**客戶端在瀏覽器輸入example.com,去進行訪問，需要找到該域名的IP地址。** 1.向DNS 遞迴解析器（DNS Resolver）傳送查詢，優先檢視緩衝區是否存在記錄，若沒有 ，繼續 2。 2.向根域名伺服器發出查詢。 3.根域名伺服器給出.com （TLD）頂級域名伺服器的地址。 4.然後，DNS解析器向 .com TLD Server 發出請求。 5.TLD 伺服器隨後使用該域的域名伺服器 example.com 的 IP 地址進行響應。 6.最後，遞迴解析器將查詢傳送到example.com的權威域名伺服器。 7.權威域名伺服器將example.com 的 IP 地址響應給解析器。 8.然後 DNS 解析器將最初請求的域的 IP 地址響應 Web 瀏覽器，並在自己的快取記憶體，記錄下來，以備下次使用，不用再次查詢。
**DNS 查詢的這 8 個步驟返回 example.com 的 IP 地址後，瀏覽器便能發出對該網頁的請求：** 9.瀏覽器向該 IP 地址發出 HTTP 請求。 10.位於該 IP 的伺服器將網頁返回。
# 二、攻擊原理：
這裡引用，清華大學團隊的原理圖，進行解釋。 
trudy是一個偏離通道的攻擊者（off-path），即不可以進行監聽和篡改 遞迴解析器 到權威域名伺服器 通道上的內容，trudy擁有一定的IP spoof 能力。 - Trudy 通過web瀏覽器訪問 `www.bank.com`，假如此時 resolver 快取中並無此記錄。 - 解析器進行遞迴查詢，向根域名伺服器，頂級域名伺服器，以及權威域名伺服器發出查詢。 - 攻擊者Trudy此時使用 bank.com的權威域名伺服器IP地址，偽造 迴應報文向 解析器傳送。 該回應報文解析的IP地址，指向攻擊者自己的伺服器。 - 解析器收到Trudy假冒的DNS響應報文之後，將 `www.bank.com`對應的假冒 IP =6.6.6.6 寫入快取。 - 待真正的響應報文到達解析器時，為時已晚，此時解析器發現已經有了相應的記錄，會進行丟棄 - 這時 使用者 Alice 想要訪問`www.bank.com`,通過解析器檢視自己的錯誤快取表，會訪問到一個錯誤的IP，得到一個攻擊者偽造一模一樣的錯誤頁面。（此時如果使用者輸入各種賬號密碼，會被竊取。）
**但真正的攻擊卻不是如此簡單，根據上文介紹的DNS協議資料包，IP頭|UDP頭|DNS** 攻擊者偽造的響應資料包，如下：  注意： 這裡的目的埠與事務ID都是未知的，攻擊者如果想要同時爆破這兩個欄位，目的埠兩個位元組，事務ID兩個位元組，一共 $2^{32}$種可能，目前不太可能實現。 DNS權威域名伺服器 響應的源埠 一般是確定的53埠， DNS 解析器客戶端以前也預設用源埠53去查詢，這樣隨機性只靠TxID，很容易進行攻擊 ，$2 ^{16}$,65536種可能。 2008年7月，Dan Kaminsky就利用了這個。因此，為了有效的防禦，DNS解析器採取了源埠隨機化。
為了解決上述問題，在這篇論文中，清華大學安全團隊，提出了一種分治的思想，即先通過ICMP側通道探測開放的埠，後猜測相應事務ID，一共 $2^{17}$ 種可能。 另外，相應的擴大攻擊視窗的時間，可更容易的實現這種進攻。
## 推測源埠
​ 這裡只介紹其中的一個 Private Source Port Scan Method。首先了解一下以下知識： ​ **IP速率限制： 比如IP 速率限制 為 1/s ，即在1秒這段時間內只限1個IP訪問DNS解析器上的埠。** ​ **ICMP速率限制：表示在這段時間內，DNS解析器最多能發出的ICMP響應報文個數。比如：ICMP 速率限制為 50 /20ms ，這裡表示 在20ms內只能返回50個ICMP響應。比如攻擊者以 1000/20ms 的速度進行探測埠，這裡只能返回50個ICMP不可達報文。** ​ **側通道攻擊：大體意思是，攻擊者藉助伺服器進行響應的一些資訊，發動攻擊。** ​ **埠探測：意思是通過向DNS解析器傳送UDP報文，遍歷目的埠，如果埠未開放，則會返回ICMP不可達報文，如果開放，不會收到響應報文** ​ **臨時埠：只對權威域名伺服器開放，攻擊者並不知曉，所以要用到IP欺騙，偽造權威域名伺服器的IP傳送UDP探測報文。**
 在上圖中，假設解析器的ICMP速率限制為 50/20ms, 攻擊者通過偽造權威域名伺服器的IP，向解析器傳送50個探測UDP報文，那麼攻擊者以自己的IP再向解析器傳送一個UDP報文，如果沒收到任何ICMP回覆，說明已達到ICMP速率限制，可進行下一個20ms的探測，不斷迴圈。如果此時收到回覆，說明至少有一個埠是開放的。可通過二分查詢，查詢開放的埠。
**但是 存在IP速率限制怎麼辦？** 假如IP速率限制為1個/秒，即在這一秒內只允許一個IP訪問解析器。在這篇論文中提到，清華大學安全團隊通過觀察原始碼發現，ICMP速率限制 是在IP速率限制之前 進行驗證的。所以，即使最後一個IP只返回一個ICMP響應包，但是ICMP 速率限制的計數器是變化的。 所以與上圖同理，只在這一方面有些許變化。
論文原圖如下：
​  大約可以每秒1000的速度去探測解析器開放的埠。但是仍需很長時間，所以這就需要去相應擴大攻擊視窗。
## 擴大攻擊視窗 攻擊視窗，指DNS解析器向伺服器傳送查詢，到權威域名伺服器響應報文到達解析器的這段時間。 所以擴大攻擊視窗的主要思路，應該集中在阻止響應報文的到達，或延遲響應報文的到達。 通過傳送大量的DNS查詢來淹沒權威域名伺服器,類似於攻擊者偽造解析器，傳送大量DNS query，高於配置限制的速率(伺服器上配置的RRL)，會權威域名伺服器不傳送響應，建立足夠高的丟失率。
## TTL時間 ​ 對於解析器緩衝區而言，可能已經擁有某條記錄，但攻擊者不得不等待這條記錄消失之後，再發動攻擊。TTL即表示這條記錄的生存時間，時間可能為1天或者更久。 **這就很頭疼,有沒有解決辦法？** ​ 有。 ​ 攻擊者可以去問類似1.xxx.com、2.xxx.com、3.xxx.com等等這些大概率就完全不存在的域名，由於DNS解析器並沒有這些域名的快取，就會發起查詢，假設ns1.xxx.com是foo.com的權威DNS，DNS解析器就會去ns1.xxx.com詢問。
**Q：要投毒的是`www.xxx.com`，搞定83.xxx.com有什麼意義啊。** **A：沒錯，我們的目標並不是83.xxx.com，這個攻擊比較精彩的地方是，可以並不是在應答區做手腳，而是在權威區和附加區行騙！** 偽造的響應包，大約是這個樣子： > 問題區：83.xxx.com A > 應答區：（空） > 權威區：xxx.com NS `www.xxx.com` > 附加區：`www.xxx.com` A 6.6.6.6 這個響應的意思是：“我不知道83.xxx.com的A記錄，你去問問`www.xxx.com`吧，它負責xxx.com這個域，對了，他的IP是6.6.6.6”。 而這裡的6.6.6.6，就是攻擊者意欲讓DNS解析器相信的IP地址。





本文參考[DNS Cache Poisoning Attack Reloaded: Revolutions with Side Channels](https://www.cs.ucr.edu/~zhiyunq/pub/ccs20_dns_poisoning.pdf)這篇論文，若想詳細瞭解，可去閱讀！同時，若有不太理解的問題，歡迎在下面評論進行討論！

------ # 參考文件：
[SADDNS官網](https://www.cs.ucr.edu/~zhiyunq/SADDNS.html) [SADDNS explained](https://blog.cloudflare.com/sad-dns-explained/) [DNS伺服器型別](https://www.cloudflare.com/zh-cn/learning/dns/dns-server-types/) [一次出人意料而名留青史的 DNS 投毒攻擊](https://www.mdeditor.tw/pl/pbj3) [IP報文分片](https://blog.cloudflare.com/ip-fragmentation-is-b