自去年開始，DDOS 攻擊已經上升到了一個新的高度，其標志性攻擊是針對國際反垃圾郵件聯盟和 cloudflare 的大規模 DDOS 攻擊，流量一度達到120G，當然后面的 DDOS 遠遠超過了120G，不過這一次攻擊確實是歷史性的。

我們現在回過頭去看這些攻擊已經清楚他們的攻擊來源是 DNS/NTP 等反射攻擊導致的，但是為什么 DNS和NTP 等服務具有如此厲害的能力呢?攻擊者是如何做到制造出如此巨大的流量的呢?DNS 這個在我們日常網絡使用的時候再平常不過的服務是如何被利用來變成大規模攻擊的呢?

我們現在先提前給出最終答案，然后再進行解釋：

1、DNS 使用了簡單的 UDP 報文進行客戶端和服務端之間的通訊;

2、DNS 是純天然的流量放大器，通過極小的請求返回很大的回應數據包;

3、互聯網上充斥了大量的開放 DNS 解析器，它們可以接受任何客戶端的請求而不會拒絕;

4、網絡的濫用導致很多地方可以發出偽造源 IP 地址的數據包。

這四個方面的問題最終結合到了一起，形成了現在的 DNS 系統的格局，也使 DNS 系統成為了 DDOS 攻擊的重要問題來源。一次正常的 DNS 請求可能發出的流量只有64bytes，但是它收到的回應可能遠遠超過這個數，在某些特定場合下，這個流量被放大的比率可以輕輕松松超過50倍。按照這個 比率計算，如果通過一個僵尸網絡來同時發送 DNS 請求的話，那么生成G/s的流量是十分輕松的，如果是使用了 DNSSEC 的話，流量還將更大。

現在的問題在于，實質上這些流量和其他流量一樣都是看似正常的流量，所以簡單的過濾機制對此將不起作用，我們需要尋求更深層次的解決方案來解決這個長期困擾互聯網的問題。

在這個問題的討論上，其中一個講到如果大家在實施網絡的時候都按照 BCP38 來實施的話，可以阻止虛假 IP 地址發送 DNS 請求，從而阻止了利用 DNS 進行反射放大的攻擊。當然這個話題已經久到比 BCP38 本身還要早，BCP38 作為一個文檔已經存在了13年之久，但令人不爽的是這仍然未能改變在過去的13年里層出不窮的源 IP 偽造攻擊，所以在未來數個月甚至若干年內我們也不要對此報太大期望。

另外一個討論是說解析器應該實施應答頻率限制(response rate limiting，RRL)，默默地將超過閾值的重復請求丟棄掉，這個對于權威 DNS 來說確實相當的有效率，但是對于遞歸解析器群來說效果就差很多，因為攻擊一旦散步到各個遞歸服務器，那么分攤下去之后能夠檢測到的頻率就可能達不到檢測閾 值。盡管如此，權威 DNS 服務器實施 RRL 仍然是很好的選擇。

另外一個討論是說，關閉掉這些開放遞歸查詢服務器，open resolver project(http://openresolverproject.org)這個項目就是準備干這個事情的，讓開放查詢服務器的維護者自行檢查配 置，把有問題的查詢器關閉掉，和 BCP38 的被接收程度差不多，也不要太指望這個途徑能有太大作用。部分原因是因為大量的遞歸服務器都疏于管理。

DNS 服務器接收小包請求產生打包回應的這一行為已經成為了 DNS 的固有屬性，特別針對 DNSSEC 而言更是如此，我們既想要對 DNS 解析結果有安全保障，又想要速度快，那么必然會選擇 UDP 協議，結合上無處不在的遞歸 DNS 查詢服務器，這就導致了回應包的變大，最終導致了這一平臺成為了大流量攻擊的神器。

如果我們想要徹底解決掉利用 DNS 進行大規模攻擊的難題，留給我們發揮的空間已經很小很小了。然而仍然還存在一個關于 DNS 是否使用 UDP 的看法在延續。

在原版 RFC1123 中允許了 UDP 和 TCP 兩種方式作為 DNS 服務的協議，與此有關的一段是這么描述的：

“在不久的將來新的 DNS 記錄類型會超過512bytes的限制已經非常明顯，據此基于 TCP 的 DNS 是需要的，所以遞歸解析器和權威服務器需要支持 TCP 方式提供服務作為當下使用 UDP 方式的后備方案，今后必將用到 TCP 方式。”

(為什么是512bytes呢?這個限制是來自于ipv4 主機需求定義(RFC1122)，所有支持ipv4的系統都必須能夠接收至少576bytes，20bytes的IP header，8bytes的 UDP header和40bytes的ip options，這就決定的單個 UDP 包的大小最大就512bytes)

現如今 IPv4 中生成更大的包已經成為可能，理論最大可以達到65535bytes，UDP包大小可達65507bytes，但是如此大的包在傳輸過程中是會被分片的， 在這種情況下，典型的防火墻規則能夠對其后的包進行阻斷，可能導致其無法到達客戶端，這是由于很多防火墻是基于 UDP 和 TCP 端口地址的。因這些被分片的包本身并不包含 UDP 或 TCP 頭部，這使得防火墻陷入了窘境，到底是允許呢還是允許呢?這種情境下防火墻可能最終妥協繼而使得部分攻擊得逞?；蛘呤莵G棄掉所有的分片?考慮到這兩方面的 因素，傳統 DNS 的做法是限制 UDP 回應包大小為512bytes，且當包大小超過512bytes的時候總是啟用 TCP 作為備用措施。

然而，客戶端或許并不知道 DNS 回應包的大小會超過512bytes，所以為了通知客戶端使用 TCP 來接收整個 DNS 響應， DNS 解析器會發送給客戶一個設置了"truncated"位的回應。

我們一直在這個途徑上堅持了很多年， DNS 在大多數情況下使用 UDP 進行通訊，只有在極少情況下才會啟用 TCP 通信。這種做法在后來我們考慮為 DNS 解析添加安全證書機制的時候就顯得不是那么爽了，隨著 DNSSEC 的加入已經很少有響應包可以做到不超過512bytes了，由 UDP 轉換為客戶端通過 TCP 重發的機制勢必會導致解析的延遲。

就像 RFC5966 中寫的那樣：

由于 DNS 的核心原型已定， DNS 擴展機制也被提出(EDNS0 RFC2671),這套機制可以用來表明客戶端可以接收大小超過512bytes的包，一個 EDNS0 兼容的客戶端向兼容服務端發送的包可以是由客戶端 buffer size 大小指定的包大小而無需分片。

EDNS0 允許基于 UDP 的回應包擁有更大的大小，這時 TCP 已經被當作武功秘籍而為被廣為流傳了，僅僅被用來做域傳送，如果不想啟用域傳送的話，似乎 TCP 就完全不起任何作用了。

在 RFC1123 中有關主機的必要條件是這么描述的：

DNS 解析器和第歸服務器必須支持 UDP，可以支持 TCP 來發送查詢請求。

但是基于 TCP 的 DNS 不光是可以支持較大的 DNS 響應，如果我們重新審視一下大規模 DNS 反射攻擊的先決條件，普遍的 UDP 大包響應，以及缺乏實施的 BCP38，使得攻擊者可以通過源 IP 偽造的手段對目標進行攻擊。

TCP 不會出現此問題，如果攻擊者通過偽造源 IP 來發起 TCP 請求的話，目標 IP 頂多只會收到一個很小的包，(40bytes)，只包含了 SYN 和 ACK 標記，目標系統由于沒有已經建立了狀態的連接，這個包將會被丟棄掉，根據本地配置的不同，目標 IP 可能會發送一個 TCP RESET 包給另一端來表明 state 的不確立，或者僅僅是默默的丟棄掉，這樣 DNS 攻擊的流量放大作用就沒有效的解決掉。

如果說 DNS 系統已經使得整個互聯網面臨了如此巨大的問題的話，那么是否我們就應該停止使用EDNS0所支持的較大的 UDP 回應包，繼而使用 TCP 來傳輸較大的請求?

我們再來看一下 RFC5966：

多數 DNS 服務運營商已經支持 TCP 且默認的軟件配置也是支持 TCP 的，此文檔的主要受眾是那些。。。

這個地方我們需要看到的問題是，我們如何能夠量化 DNS 支持 TCP 請求和回應的覆蓋度?這里只的“多數”到底是多少?

通過測驗發現，大部分的 DNS 系統對 TCP 類型的報文是可以響應的，也就是說，利用 TCP 來回復大包以組織 DNS 使用 UDP 發送大包這一做法是切實可行的，不支持 TCP 的那部分 DNS 系統要么是由于主備DNS的配置導致其請求第一個服務器不通進而請求下一個服務器，要么是一些其他的問題，也就是說，在處理TCP有問題的DNS服務器里 也只是有部分是真實存在問題的。

如果你是DNS系統管理員的話，我們建議:

1、盡量不要維護一些很小的開放DNS解析服務，這些事情是網絡運營商該干的;

2 、權威DNS一定要對請求頻率加以限制，如果是使用 bind 的話可以利用 bind 自帶的 RRL 個功能進行頻率限制，如果是 PDNS 的話可以通過防火墻規則來限制;

3、對 DNS 系統進行全面的檢查，對 DNS 系統進行配置檢查，以防止出現一些低級錯誤等。只有通過多方面的努力，才能將 DDOS 攻擊影響逐步小化。來源：http://blog.51web.net/7，轉載請注明出處，謝謝!