安全性優勢

簡介：DNS 安全性威脅和緩解措施

由於網域名稱系統的開放式設計，加上使用者資料圖表通訊協定 (UDP) 的使用情形，DNS 容易受到各種形式的攻擊。公開或「開放式」的 DNS 解析器尤其會有風險，因為這類程式庫不會將連入封包限制在一組允許的來源 IP 位址。我們最常受到兩種常見的攻擊類型：

  • 假冒 DNS 的假冒攻擊攻擊。 各類 DNS 假冒和偽造偽造利用方式，企圖將使用者從正當網站重新導向至惡意網站。其中包括所謂的「Kaminsky 攻擊」，讓攻擊者能主導整個 DNS 可用區的權威性攻擊。
  • 阻斷服務 (DoS) 攻擊。攻擊者可能會對解析器本身進行 DDoS 攻擊，或入侵其他系統來啟動 DoS 攻擊。利用 DNS 伺服器利用大型 DNS 記錄/回應大小對其他系統進行 DoS 攻擊的攻擊，也就是所謂的「放大攻擊」。

下文將詳細說明每個攻擊類型。

快取中毒攻擊

DNS 假冒攻擊有多種版本，可能會導致快取毒害發生，但一般情況如下：

  1. 攻擊者會發出目標 DNS 解析器，並要求某個伺服器知道伺服器並非官方伺服器，且很可能位於伺服器快取中。
  2. 解析器會向其他名稱伺服器發出要求 (其攻擊者也能預測 IP 位址)。
  3. 與此同時，攻擊者會冒用受委任名稱伺服器產生的偽造回應來攻擊受害者伺服器。回應中包含了將要求網域解析為攻擊者控制的 IP 位址的記錄。這些記錄可能包含已解析名稱的答案記錄，或進一步委派權限給攻擊者擁有的名稱伺服器，以便控管整個可用區。
  4. 如果其中一個偽造回應與解析器' 的要求相符 (例如透過查詢名稱、類型、ID 和解析器來源通訊埠)，且在收到正向的名稱伺服器回應之前收到，則解析器會接受偽造的回應，並快取此回應，並捨棄真實的回應。
  5. 針對快取網域或可用區的未來查詢，系統會透過快取提供的 DNS 解析進行回應。如果攻擊者已根據偽造的回應指定存留時間極長，則偽造的記錄會盡可能留存在快取中，而不會重新整理。

如需 Kaminsky 攻擊的很好介紹，請參閱 Kaminsky DNS 安全漏洞指南。

DoS 和擴大攻擊

DNS 解析器受到一般的 DoS 威脅，容易危害任何網路系統。不過，放大攻擊尤其重要，因為 DNS 解析器是針對攻擊者利用各種解析器的攻擊目標？支援 EDNS0 (DNS 的擴充功能機制) 的解析器特別容易傳回，因為傳回的傳回封包大小較大。

在放大情境中，攻擊狀況如下：

  1. 攻擊者會使用偽造的來源 IP 位址傳送受害者的 DNS 伺服器查詢。查詢可能會來自使用相同偽造 IP 位址的單一系統或網路系統。 這些查詢適用於攻擊者知道的記錄，會導致回應數量大幅增加，最多是原始十倍的1，也就是原始查詢的大小 (因此稱之為「放大」攻擊)。
  2. 受害伺服器會將大型回應傳送至在偽造要求中傳送的來源 IP 位址，並超載系統並導致 DoS 狀況。

因應措施

DNS 安全漏洞的標準系統解決方案為 DNSSEC。不過，在全面實作之前，開放式 DNS 解析器必須採取獨立措施來緩解已知威脅。已提出許多技巧；請參閱 IETF RFC 5452：提高 DNS 對各種偽造答案的應變措施，瞭解大多數做法的總覽。 在 Google 公用 DNS 中，我們實作了下列做法：

  • 根據程式碼溢位保護程式碼，特別是剖析及序列化 DNS 訊息的程式碼。
  • 過度佈建機器資源，可防止解析器本身直接受到 DoS 攻擊。由於 IP 位址是攻擊者可能難以應付的 IP 位址，因此不建議您根據 IP 位址或子網路封鎖查詢；處理這類攻擊的唯一方法就是吸收負載。
  • 針對回應封包和名稱伺服器可信度實作基本的有效性檢查，以防範簡單的快取毒害。這些是所有符合標準的快取解析器應該執行的標準機制和完整性檢查。
  • 新增熵以要求訊息，以降低較複雜的假冒/快取中毒攻擊的可能性 (如 Kaminsky 攻擊)。市面上建議加入寬鬆的技巧。以下概略說明這些技術的優勢、限制和挑戰，並討論我們在 Google 公用 DNS 中實作這些技術的好處。
  • 移除重複的查詢，以消除「生日」攻擊的機會。
  • 頻率限制要求：以避免 DoS 和擴大攻擊。
  • 使用最大頻寬監控用戶端 IP，並達到最高的回應與要求大小比例。

DNSSEC

網域名稱安全性擴充功能 (DNSSEC) 標準已在數個 IETF RFC 中指定：4033、4034、4035 和 5155。

透過驗證從名稱伺服器收到的回應真實性，實作 DNSSEC 計數器快取毒害攻擊的解析器。 每個 DNS 可用區都有一組私密/公開金鑰組。系統會針對每個 DNS 記錄產生不重複的數位簽章，並使用私密金鑰進行加密。接著，相應的公開金鑰會由屬於父項區域的信任鏈結進行驗證。符合 DNSSEC 的解析器會拒絕不含正確簽名的回應。DNSSEC 可有效防止回應遭到竄改，因為在實務上，簽名在不存取私密金鑰的情況下幾乎不可能建立。

自 2013 年 1 月起，Google 公用 DNS 全面支援 DNSSEC。我們接受並轉寄 DNSSEC 格式的訊息，並驗證回應是否正確。 我們強烈建議其他解析者採取相同的做法。

我們也會按照 IETF RFC 8198：DNSSEC 已驗證快取的積極使用一節中的規定，快取 NSEC 回應。這樣可將 NXDOMAIN 查詢縮減為實作 DNSSEC 的名稱伺服器，並使用 NSEC 做為排除答案。

用戶端加密傳輸

Google 公用 DNS 支援加密傳輸通訊協定、透過 HTTPS 的 DNS 和透過傳輸層安全標準 (TLS) 執行 DNS。這些通訊協定可防範竄改、假冒和假冒行為，大幅提升用戶端與 Google 公用 DNS 之間的隱私權與安全性。能與 DNSSEC 相輔相成，提供端對端驗證的 DNS 查詢。

實作基本有效性檢查

某些 DNS 快取損毀可能是由於無意間存在，且不一定是要求和回應之間不一致的情況 (例如，可能是名稱伺服器設定錯誤、DNS 軟體發生錯誤等)。DNS 解析器應至少應執行檢查作業，以驗證名稱伺服器的可信度和關聯性。我們建議同時導入 (包括) 下列所有防禦機制：

  • 請勿在傳出要求中設定遞迴位元，並一律遵循委派鏈。停用遞迴位元即可確保解析器在「疊代」模式下運作，以便在委派鏈中明確查詢每個名稱伺服器，而不是讓其他名稱伺服器代您執行查詢。
  • 拒絕可疑的回覆訊息。 請參閱下文，進一步瞭解我們認定為「可疑」的內容。
  • 請勿根據先前要求中的黏附紀錄，將 A 記錄傳回用戶端。舉例來說，如果您收到 ns1.example.com 的用戶端查詢，則應重新解析位址，而不是根據從 .com TLD 名稱伺服器傳回的快取黏附紀錄傳送 A 記錄。

拒絕不符合必要條件的回應

Google 公用 DNS 會忽略下列所有內容：

  • 無法剖析或格式錯誤的回覆。
  • 金鑰欄位與要求中對應的欄位不符的回應。包括查詢 ID、來源 IP、來源通訊埠、目的地 IP 或查詢名稱。如需 DNS 假冒行為的完整說明，請參閱 RFC 5452 第 3 節。
  • 與要求無關的記錄。
  • 回答我們無法重新建立 CNAME 鏈結的記錄。
  • 答案名稱伺服器中的記錄 (在答案、主管機關或其他章節中) 無法使用。判定名稱伺服器是否位於特定網域的委派鏈中，即被視為「可信」。Google 公用 DNS 會快取委派鏈資訊，我們會依據快取資訊驗證每個傳入回應，以判斷回應名稱伺服器和回應特定要求是否可信。

為要求新增熵

在解析器確實執行基本語意檢查後，攻擊者必須在正當的名稱伺服器之前，透過回應來回應受害者解析器、回應 UDP 通訊埠 (要求)、IP 位址 (回應) 和原始要求的查詢名稱。

可惜的是，這個難度並不高的原因是，專屬的唯一識別欄位 (查詢 ID) 僅 16 位元 (亦即有 1/65,536 的機率正確)。其他欄位也會受到限制，因此不重複組合總數相對較低。如要計算相關組合的計算結果，請參閱 RFC 5452 第 7 節。

因此，挑戰是盡可能在 DNS 訊息的標準格式中為要求封包加入過多資訊，這樣攻擊者才能更輕易地在商機視窗中比對有效的欄位組合。我們建議您實作，並實作下列各節所述的所有技巧。

我們在 2022 年 7 月的 DNS OARC 38 會議中提供了更新過的技術評論。這份簡報也提供了名稱伺服器運算子的建議。

隨機來源通訊埠

進行基本步驟時，切勿允許傳出要求封包使用預設的 UDP 通訊埠 53，或是使用可預測的演算法指派多個通訊埠 (例如簡易遞增)。在系統中盡可能允許從 1024 到 65535 之間的通訊埠範圍，並使用可靠的隨機號碼產生器來指派通訊埠。舉例來說，Google 公用 DNS 會使用約 15 位元的金鑰，大約允許 32,000 個不同的通訊埠編號。

請注意，如果您的伺服器是部署在防火牆、負載平衡器或其他執行網路位址轉譯 (NAT) 的後方，這些裝置可能會使傳出封包的通訊埠去隨機化。請務必將網路位址轉譯 (NAT) 裝置設為停用通訊埠去隨機化功能。

隨機選擇名稱伺服器

部分解析器在將要求傳送至根、TLD 或其他名稱伺服器時，請根據最短距離 (延遲時間) 選取名稱伺服器 IP 位址。建議您隨機分配目的地 IP 位址，為傳出要求新增熵。 在 Google 公用 DNS 中，我們只為每個可用區的設定名稱伺服器隨機挑選名稱伺服器，有利於快速且穩定的名稱伺服器。

如果您擔心延遲時間，可以使用「往返時間 (RTT) 頻帶」，其中隨機分組低於低於特定延遲時間門檻的位址 (例如 30 毫秒、300 毫秒等)。

DNS Cookie

RFC 7873 定義了在 DNS 訊息中加入 64 位元 Cookie 的 EDNS0 選項。 支援 DNS Cookie 的用戶端會在要求中納入一個隨機 64 位元 Cookie，以及 (選擇性) 伺服器 Cookie。如果支援伺服器在要求中發現有效的 Cookie 選項，則在回應中反映用戶端 Cookie 和正確的伺服器 Cookie。接著，支援用戶端驗證回應中的用戶端 Cookie，藉此驗證回應是否來自預期的伺服器。

如果名稱伺服器不支援 DNS Cookie，可以使用以下兩個選項新增熵。

在查詢名稱中隨機判定大小寫

DNS 標準規定名稱伺服器必須區分大小寫。舉例來說，example.com 和 EXAMPLE.COM 名稱應解析為相同的 IP 位址2。此外，只有少數幾個名稱伺服器回應回應中的名稱，因為這會保留原始的情況。

因此，為要求新增熵的另一種方法，就是隨機查詢查詢的網域名稱中字母的大小寫。這項技巧又稱為「0x20」，這是因為位元 0x20 是用於設定 US-ASCII 字母的情況。這個問題是先在 IETF 網際網路草稿中在 DNS 標籤中使用 Bit 0x20 來改善交易身分，使用這項技術時，名稱伺服器回應不僅必須符合查詢名稱，以及名稱字串中每個字母的大小寫相符，例如 wWw.eXaMpLe.CoM 或 WwW.ExamPLe.COm。這對頂層和根網域的查詢可能會增加或完全沒有資訊，但這對於大部分主機名稱來說都有效。

導入這項技術時，我們發現一個重大挑戰是，部分名稱伺服器未遵循預期的回應行為：

  • 部分名稱伺服器會以完全區分大小寫的方式回應：無論要求是否區分大小寫，這些伺服器都會傳回相同的結果，但回應與要求中的姓名完全相符。
  • 其他名稱伺服器會以完整的區分大小寫 (違反 DNS 標準) 回應：它們會根據要求採用不同的方式處理相同名稱，亦即完全無法回覆，或是傳回與要求中名稱完全相符的 NXDOMAIN 錯誤。
  • 部分名稱伺服器正常運作，但 arpa 可用區中的 PTR 查詢除外。

對這兩種名稱伺服器來說，修改查詢名稱的案件會導致不合適的結果：針對第一個群組，系統可能無法區分偽造的回應。如果是第二組名稱伺服器，回應 (如果有的話) 可能會完全不正確。

目前這個問題的解決方法是只針對名稱伺服器使用案例隨機化功能，因為我們知道，伺服器都能正確套用標準。並根據分析記錄，為每個子網域列出適當的例外狀況子網域。如果來自這些伺服器的回應不包含正確的大小寫，我們就會拒絕該回應。 啟用的名稱伺服器會處理超過 70% 的傳出流量。

在查詢名稱前面加上 Nonce 標籤

如果解析器無法直接解析快取中的名稱，或是無法直接查詢權威的名稱伺服器，則必須遵循根或 TLD 名稱伺服器的參照。在多數情況下，傳送至根或 TLD 名稱伺服器的要求會轉而參照其他名稱伺服器，而不是嘗試將名稱解析為 IP 位址。因此在要求中，建議將隨機標籤附加至查詢名稱，這樣能夠提高該要求的資訊，同時避免解析不存在的名稱。也就是說，如果要求參照前置字串為 Nonce 標籤 (例如 entriih-f10r3.www.google.com) 的參照名稱伺服器，則應與 www.google.com 的要求傳回相同的結果。

在實際運作中，雖然這類要求不到 3% 的傳出要求，但假設正常流量 (因為大部分查詢可以直接從快取或單一查詢獲得回應)，但這些要求其實是攻擊者嘗試強制解析器發出的要求類型。因此，這項技術可以有效保護 Kaminsky 樣式的漏洞。

如要導入這項技術，只需將 Nonce 標籤用於保證參照參照連結網址的要求，也就是在「答案」部分不包含記錄的記錄即可。不過，在嘗試定義這類要求時，我們遇到了幾個挑戰：

  • 某些國家/地區代碼的 TLD (ccTLD) 名稱伺服器實際上是其他第二層 TLD (2LD) 的授權。雖然 2LD 會採用兩個標籤，但 2LD 的運作方式就像 TLD 一樣，因此通常是由 ccTLD 名稱伺服器處理。舉例來說，.uk 名稱伺服器也同樣是 mod.uk 和 nic.uk 區域的權威性，因此，這些可用區中都包含的主機名稱，例如 www.nic.uk、www.mod.uk 等。 換句話說，如果向 ccTLD 名稱伺服器發出這類解析要求，系統不會造成參照連結網址，但在具公信力的答案中附加了 Nonce 標籤，會導致無法解析名稱。
  • 一般通用 TLD (gTLD) 名稱伺服器會傳回名稱伺服器的非權威回應。也就是說，有些名稱伺服器主機名稱會存在於 gTLD 可用區，而不是在網域的區域中。gTLD 會傳回這些主機名稱的非權威性答案，並使用資料庫中出現的所有黏附紀錄，而不會傳回參照連結網址。例如，名稱伺服器 ns3.indexonlineserver.com 位於 .COM gTLD 區域，而不是 indexonlineserver.com 可用區。我們向 n3.indexonlineserver.com 的 gTLD 伺服器發出要求時，我們收到了其 IP 位址，而不是參照連結網址。不過，如果我們加上 Nonce 標籤，就會取得 indexonlineserver.com 的參照連結網址，但系統無法解析主機名稱。因此，如果名稱伺服器需要 gTLD 伺服器解析，我們無法加上 Nonce 標籤。
  • 可用區和主機名稱的主機名稱會隨著時間而改變。 如果委任鏈結發生變更，可能會導致原本可解析的 Nonce 前置主機名稱變成無法解析。

為解決這些難題，我們已為我們無法附加 Nonce 標籤的主機名稱設定例外狀況。根據我們的伺服器記錄，這些 TLD 名稱伺服器必須傳回非參照連結網址回應的主機名稱。我們會持續審查例外狀況清單，確保政策在一段時間內仍有效。

移除重複的查詢

DNS 解析器容易受到「生日發動攻擊」的呼叫，所以會呼叫數學攻擊「數學生假」模式，生日攻擊不會因為受害者損壞了偽造的回應，還涉及初始查詢，這取決於解析器在一個解析器上發出多次要求。傳送的外送要求數量越多，攻擊者就符合其中一個要求，會與偽造的回應相符：攻擊者只需要使用 300 個執行中的要求，就能在收到偽造回應時獲得 50% 的成功率，以及 700 個要求接近 100% 的成功要求。

為防範這個攻擊策略，請務必捨棄傳出佇列中所有重複的查詢。例如，Google 公用 DNS 一律不允許針對多個查詢名稱、查詢類型和目的地 IP 位址提出的多個待處理要求。

頻率限制查詢

防範阻斷服務攻擊會對開放式遞迴 DNS 解析器造成幾個特殊的挑戰：

  • 開放式遞迴解析器是吸引擴充攻擊的理想目標。這類伺服器屬於高容量、高穩定性的伺服器，並且可能會比一般權威名稱伺服器產生更大的回應，特別是在攻擊者可將快取插入大型回應時。開放式 API 服務的所有開發人員都會不負責，防止自己的伺服器用於在其他系統上發動攻擊。
  • 擴大攻擊可能並不容易偵測。攻擊者可以透過數千個公開的解析器啟動攻擊，因此每個解析器只會看到一小部分查詢量的一小部分，也無法擷取明確的入侵信號。
  • 您必須封鎖惡意流量，而不會幹擾 DNS 服務的使用者，以免造成服務中斷。DNS 是必要的網路服務，因此不能選擇關閉伺服器來切斷攻擊，也無法拒絕服務在任何指定用戶端 IP 時間過長。解析器必須能夠在開始時快速封鎖攻擊，並在攻擊結束時立即恢復完全運作的服務。

防範 DoS 攻擊的最佳做法是採取頻率限製或「節流」機制。Google 公用 DNS 實作了兩種頻率控制：

  • 控管傳送至其他名稱伺服器的傳出要求頻率。為保護其他 DNS 名稱伺服器，以防止解析器伺服器發動的 DoS 攻擊，Google 公用 DNS 會針對每個名稱伺服器處理每個服務叢集的傳出要求強制執行 QPS 限制。

  • 控制傳送傳出回應給用戶端的速率。為防止任何其他系統遭到攻擊，以及透過解析器伺服器啟動的傳統分散式 DoS (機器人網路) 攻擊，Google 公用 DNS 會針對用戶端查詢執行兩種頻率限制：

    • 為防範傳統以磁碟區為基礎的攻擊，每個伺服器都會套用每個用戶端 IP QPS 和平均頻寬限制。
    • 為防止放大攻擊 (利用小型查詢進行大型回應)，每個伺服器會強制執行每個用戶端 IP 的最大平均放大係數。 平均放大係數是可回應回應的大小比例，由我們的伺服器記錄中觀察到的歷來流量模式決定。

    如果來自單一來源 IP 位址的 DNS 查詢超過每秒查詢數上限，系統就會捨棄額外的查詢。如果從一個來源 IP 位址透過 UDP 發出的 DNS 查詢超過平均頻寬或放大上限(偶爾傳遞大型回應)，系統可能會捨棄查詢，或只會傳送小型回應。小型回應可以是錯誤回應，或設有截斷位元的空白回應 (這樣大多數合法查詢都會透過 TCP 重試並成功)。並非所有系統或程式都會透過 TCP 重試，且用戶端的防火牆可能會封鎖透過 TCP 執行 DNS 的訊息，因此某些應用程式在截斷時可能無法正確運作。儘管如此，在大多數情況下，截斷也允許符合 RFC 規範的用戶端正常運作。

  1. 如需範例，請參閱 DNS 放大攻擊論文。 ↩

  2. RFC 1034，第 3.5 節顯示：↩

    請注意，雖然網域名稱可以使用大小寫字母，但大小寫不區分大小寫。也就是說，具有相同名稱但不同情況的兩個名稱，應視為相同。