來自特拉維夫大學和荷茲利亞跨學科中心（以色列）的一組研究人員 新的攻擊方式 (），允許您使用任何 DNS 解析器作為流量放大器，提供高達 1621 倍的資料包數量放大率（對於發送到解析器的每個請求，您可以實現將 1621 個請求發送到受害者的伺服器）流量高達163倍。
該問題與協定的特殊性有關，影響所有支援遞歸查詢處理的 DNS 伺服器，包括 （CVE-2020-8616）， （CVE-2020-12667）， （CVE-2020-10995）， и (CVE-2020-12662)，以及 Google、Cloudflare、Amazon、Quad9、ICANN 等公司的公共 DNS 服務。該修復是與 DNS 伺服器開發人員協調進行的，他們同時發布了更新以修復其產品中的漏洞。版本中實施的攻擊防護
, , , .
該攻擊基於攻擊者使用引用大量以前未見過的虛構 NS 記錄的請求，將名稱確定委託給這些記錄，但沒有在回應中指定帶有有關 NS 伺服器 IP 位址資訊的黏合記錄。例如，攻擊者透過控制負責attacker.com 網域的DNS 伺服器發送查詢來解析名稱sd1.attacker.com。為了回應解析器對攻擊者 DNS 伺服器的請求，將發出回應，透過在回應中指示 NS 記錄而不詳細說明 IP NS 伺服器，將 sd1.attacker.com 位址的確定委託給受害者的 DNS 伺服器。由於之前沒有遇到過上述 NS 伺服器，並且未指定其 IP 位址，因此解析器嘗試透過向受害者的服務於目標網域 (victim.com) 的 DNS 伺服器發送查詢來確定 NS 伺服器的 IP 位址。
問題在於，攻擊者可以使用大量不重複的 NS 伺服器來回應，其中包含不存在的虛構受害者子網域（fake-1.victim.com、fake-2.victim.com、... fake-1000。受害者.com）。解析器將嘗試向受害者的 DNS 伺服器發送請求，但會收到未找到網域的回應，之後它將嘗試確定清單中的下一個 NS 伺服器，依此類推，直到嘗試了所有攻擊者列出的NS記錄。因此，對於一個攻擊者的請求，解析器將發送大量請求來確定 NS 主機。由於 NS 伺服器名稱是隨機產生的，並且引用不存在的子網域，因此不會從快取中檢索它們，並且攻擊者的每個請求都會導致向服務受害者網域的 DNS 伺服器發出一系列請求。
研究人員研究了公共 DNS 解析器對此問題的脆弱程度，並確定當向 CloudFlare 解析器（1.1.1.1）發送查詢時，封包數量（PAF，封包放大係數）可能增加 48 倍，Google (8.8.8.8 .30) - 37.235.1.174 次，FreeDNS (50) - 208.67.222.222 次，OpenDNS (32) - XNUMX 次。觀察到更明顯的指標
Level3 (209.244.0.3) - 273 次，Quad9 (9.9.9.9) - 415 次
SafeDNS (195.46.39.39) - 274 次，Verisign (64.6.64.6) - 202 次，
Ultra (156.154.71.1) - 405 次，Comodo Secure (8.26.56.26) - 435 次，DNS.Watch (84.200.69.80) - 486 次，Norton ConnectSafe (199.85.126.10) - 569。對於基於BIND 9.12.3的伺服器，由於請求的並行化，增益等級可以達到1000。在Knot Resolver 5.1.0中，增益等級大約是幾十倍（24-48），因為確定NS 名稱按順序執行，並取決於一個請求允許的名稱解析步驟數的內部限制。
有兩種主要的防禦策略。對於具有 DNSSEC 的系統 使用 防止 DNS 快取繞過，因為請求是使用隨機名稱發送的。此方法的本質是透過 DNSSEC 使用範圍檢查，在不聯繫權威 DNS 伺服器的情況下產生否定回應。一種更簡單的方法是限制處理單一委託請求時可以定義的名稱數量，但這種方法可能會導致某些現有配置出現問題，因為協定中沒有定義限制。
來源： opennet.ru