DNSSEC 的複雜性與注意事項

DNS 被分割為較小的部分，稱為區域。區域通常從網域名稱開始，並包含與子網域相關的所有記錄。每個區域由單個管理員管理。例如，cloudflare.com 是一個包含 cloudflare.com 及其子網域（例如 www.cloudflare.com, api.cloudflare.com）之所有 DNS 記錄的區域。

DNS 中沒有子網域的目錄服務，因此，如果您想知道是否存在 api.cloudflare.com，則必須詢問 DNS 伺服器，並且 DNS 伺服器最終將詢問 cloudflare.com 是否存在 api.cloudflare.com。但使用 DNSSEC 不會出現這樣的情況。在某些情況下，啟用 DNSSEC 可能會暴露原本被遮掩的區域內容。並非所有人都注重子網域的機密性，區域內容可能已經很容易被猜到，因為大多數網站都有一個「www」子網域；但是，子網域有時用作登入入口網站或網站擁有者希望保持私有的其他服務。網站擁有者可能不想顯示「secretbackdoor.example.com」存在，以便保護該網站免受攻擊者的攻擊。

DNSSEC 可以公開子網域的原因與區域的簽署方式有關。縱觀以往，DNSSEC 用於簽署靜態區域。靜態區域是給定網域的完整記錄集。使用中心位置的金鑰簽署金鑰 (KSK) 和區域簽署金鑰 (ZSK) 建立 DNSSEC 簽章記錄，並將其傳送至要發布的權威伺服器。這組記錄允許權威伺服器回答其提出的任何問題，包括有關不存在的子網域的問題。

在標準 DNS 中，當子網域不存在時，伺服器會返回未簽署的 NXDOMAIN（不存在的網域）回應，而 DNSSEC 與之不同，它會保證每個答案均已簽署。使用一種稱為 NextSECure (NSEC) 記錄的特殊記錄可做到這一點，將其用作不存在的證明即可。NSEC 記錄可用於表示：「子網域 X 和子網域 Y 之間沒有子網域」。透過填補區域中每個網域之間的間隙，NSEC 提供了一種用靜態記錄回答任何查詢的方法。NSEC 記錄還列出了每個名稱中存在的資源記錄類型。

對於靜態簽署區域，根據定義，有固定數量的記錄。由於每個 NSEC 記錄都指向下一個記錄，這就產生了一個有限的 NSEC 記錄「環」，涵蓋所有子網域。任何人都可以透過追蹤一個 NSEC 記錄到下一個 NSEC 記錄來「瀏覽」一個區域，直到他們知道所有子網域。此方法可用於顯示該區域中的所有名稱---可能公開內部資訊。

假設有一個名為 example.com 且啟用了 DNSSEC 的區域，其子網域為 public.example.com 和 secret.example.com。新增 NSEC 記錄將顯示存在所有子網域。

要求 example.com 的 NSEC 記錄提供以下內容：

example.com.NSEC public.example.com.A NS SOA TXT AAAA RRSIG NSEC DNSKEY

要求 public.example.com 提供以下 NSEC 記錄：

public.example.com.NSEC secret.example.com. A TXT AAAA RRSIG NSEC

要求 secret.example.com 提供以下 NSEC 記錄：

secret.example.com. NSEC example.com. A TXT AAAA RRSIG NSEC

第一個針對區域 top/apex，並表示名稱「example.com」存在，下一個名稱是「public.example.com」。public.example.com 記錄表示下一個名稱是「secret.example.com」，顯示存在私有子網域。「secret.example.com」表示下一個記錄是「example.com」，完成子網域鏈。因此，只需幾個查詢，任何人都可以知道該區域中的完整記錄集。

從技術上講，DNS 記錄不應該是秘密內容，但在實踐中，它們有時被認為是機密資訊。在一段時間內，子網域已被用於保持某些內容（例如公司登入頁面）的私有性，而突然顯示區域檔案的內容可能會出乎意外和不受歡迎。

在 DNSSEC 之前，發現區域中名稱內容的唯一方法是查詢名稱，或嘗試從某個權威伺服器執行區域傳輸。區域傳輸 (AXFR) 經常被阻止。引入 NSEC 的替代項 NSEC3 來解決區域列舉問題，但即使是 NSC3 也可以用來顯示存在子網域。

.ch 下的大多數網域使用 NSEC3

NSEC3 記錄類似於 NSEC 記錄，但是，NSEC3 提供的不是沒有答案的網域名稱的簽署間隙，而是網域名稱雜湊的簽署間隙。這是為了防止區域列舉。因此，包含「example.com」和「www.example.com」之區域的 NSEC3 鏈可能是（為清楚起見，每個 NSEC3 記錄位於 3 行上）：

231SPNAMH63428R68U7BV359PFPJI2FC.example.com. NSEC3 1 0 3 ABCDEF
NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM
A NS SOA TXT AAAA RRSIG DNSKEY NSEC3PARAM

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM.example.com.NSEC3 1 0 3 ABCDEF
231SPNAMH63428R68U7BV359PFPJI2FC
A TXT AAAA RRSIG

其中

231SPNAMH63428R68U7BV359PFPJI2FC

example.com

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM

www.example.com

NSEC3 記錄的第一行包含區域經過雜湊處理后的「名稱」，雜湊輪數和雜湊中使用的 salt 是第一行「3 ABCDEF」上的最後兩個參數。「1 0」代表摘要演算法（1 表示 SHA-1），以及區域是否使用選擇退出（0 表示否）。第二行是「區域中的下一個雜湊名稱」，第三行列出了名稱處的類型。您可以看到第一個 NSEC3 記錄上的「下一個名稱」與第二個 NSEC3 記錄上的名稱相符，並且該記錄上的「下一個名稱」完成該鏈。

對於 NSEC 列舉，可以透過開始猜測網域中可能的名稱來建立網域的完整清單。如果該區域有大約 100 個網域名稱，則列舉整個區域大約需要 100 個要求。若使用 NSEC3，則在您要求不存在的記錄時，將返回已簽署的 NSEC3 記錄，其中下一個區域按雜湊字母順序排列。檢查下一個查詢名稱候選項是否適合其中一個已知間隙，可讓任何人在大約 100 個查詢中發現完整鏈。有許多工具可以為您執行此計算，包括 nmap 的外掛程式

藉助與區域中所有有效名稱對應的雜湊值，可以使用字典攻擊來找出真實名稱。簡短名稱很容易被猜到，透過使用字典，可以將較長的名稱顯示為存在，而無需用猜測對權威名稱伺服器進行泛洪攻擊。使用 HashCat 之類的工具可以輕鬆在軟體中做到這一點，比特幣的普及大大降低了雜湊特定硬體的價格。建置用於計算加密雜湊的裝置家庭工業正在蓬勃發展。特斯拉密碼破解程式（下圖）只是這些現成裝置的一個例子。

特斯拉破解程式

由於雜湊很便宜，因此在按設計使用 NSC3 時，區域隱私權僅略有改善；名稱獲得的保護程度與其不可猜測性成正比。

簡而言之，NSEC 就像揭示純文字密碼，而 NSEC3 就像揭示 Unix 樣式的密碼檔案。這兩種技術都不是很安全。使用 NSEC3 後，子網域只能在難以猜測的情況下才能處於私有狀態。

此漏洞可以透過 RFC 4470 和 4471（https://tools.ietf.org/html/rfc4470與 https://tools.ietf.org/html/rfc4471）中引入的稱為「DNSSEC 善意謊言」的技術來緩解；這是由 Dan Kaminsky 為演示目的而實施。當要求傳入不存在的網域時，不是提供下一個真實網域的 NSEC3 記錄，而是按字母順序顯示下一個雜湊的 NSEC3 記錄。這不會破壞 NSEC3 保證，即在 NSEC3 回應和問題之間不存在其雜湊符合字典序的網域。

如果可以即時計算簽章以回應問題，則只能實作 NSEC3 或 NSEC 的「善意謊言」。傳統上，用於 DNS 解析的靜態區域記錄為離線建立，所有具有簽章的記錄均儲存在區域檔案中。然後，即時 DNS 伺服器讀取此檔案，允許它回答有關該區域的問題。

Cloudflare 的 DNSSEC 實作利用 ECDSA 高效的簽章產生來動態簽署 DNSSEC 記錄。

DNSSEC 旨在以各種模式運行，每種模式都提供不同的安全性、效能和便利性權衡。即時簽署解決了區域內容暴露問題，但交換條件是安全性較低的金鑰管理。

最常見的 DNSSEC 模式是靜態區域的離線簽署。這允許將私密金鑰保存在未連接到網路的機器上，藉此高度保護簽署系統免受外部威脅。當 DNS 資訊不經常變更時，此操作模型非常有效。

另一種常見的操作模式是集中式線上簽署。如果在存取受限、專用 DNS 簽署系統中簽署資料，則允許 DNS 資料變更並快速發布。某些營運者在其主要 DNS 伺服器上執行 DNS 簽署。就像離線簽署靜態區域一樣，此模式遵循中央簽署模型，即單個（或重複的）中央簽署者執行所有簽署，並且資料從其傳播到實際的權威 DNS 伺服器。

一種更激進的模式是允許實際的權威 DNS 伺服器在需要時動態簽署資料，這允許使用許多新功能，包括在產生答案的位置簽署的地理相關資訊。缺點是，現在金鑰產製原料位於許多可直接存取網際網路的不同機器上。在邊緣執行即時簽署會帶來金鑰分發等新問題，並對節點提出額外的計算要求。

最近，發現了一個名為 Heartbleed 的錯誤，該錯誤在伺服器應用程式中打開了一個主要的安全漏洞。錯誤原因在於 OpenSSL 中的編碼錯誤，其造成了遠端記憶體暴露漏洞。此錯誤允許遠端攻擊者從面向網際網路的伺服器中擷取加密金鑰。在 DNSSEC 即時簽署等活動過程中使用金鑰時，遠端記憶體暴露錯誤只是對私密金鑰安全的眾多威脅之一。機器暴露在網際網路上的次數越多，攻擊媒介就越多。離線簽署機器暴露於此類威脅的窗口要小得多。

確保金鑰安全的一種方法是使用硬體支援的解決方案，如硬體安全模組 (HSM)。這種方法的主要缺點是成本 – HSM 非常昂貴（而且速度很慢）。這是執行 DNS 伺服器時最棘手的問題之一，因為這些伺服器分布在各個地理位置上，以便接近其客戶。在每個伺服器位置執行 HSM 不僅成本高昂，而且還可能出現法律問題。

另一種防止遠端洩漏金鑰的解決方案是將加密作業卸載到系統的受信任元件中。這就是一個可以卸載加密之自訂 DNS 伺服器可以派上用場的地方。

DNSSEC 的金鑰管理類似於 TLS 的金鑰管理，且具有類似的挑戰。今年早些時候，我們推出了無密鑰 SSL ，以幫助提高 TLS 的金鑰安全性。我們正在考慮擴充無密鑰 SSL，以便為 DNSSEC 即時簽署提供遠端金鑰伺服器的優勢。

執行權威 DNS 伺服器的營運商經常擔心他們的伺服器將被用作惡意分散式阻斷服務 (DDoS) 攻擊的管道。這源於 DNS 使用 UDP（一種無狀態通訊協定）的事實。

在 TCP 中，每個連線均以三向握手開始。這可確保在開始連線之前，雙方的 IP 位址均為已知且正確無誤。在 UDP 中，沒有此類握手：訊息只是直接傳送至具有未經驗證的「來源」IP 位址的 IP。如果攻擊者可以製作一個 UDP 封包，向伺服器表示「嗨，來自 IP X」，則伺服器通常會透過向 X 傳送 UDP 封包來回應。選擇 X 作為受害者的 IP 位址而不是傳送者的 IP 位址被稱為 UDP「詐騙」。透過詐騙受害者，攻擊者可以使回應 UDP 要求的伺服器用「反射」的流量對受害者進行泛洪攻擊。這既適用於權威伺服器，也適用於開放式遞迴解析程式。

DNSSEC 也透過 UDP 運作，DNS 查詢的答案可能很長，包含多個 DNSKEY 和 RRSIG 記錄。對攻擊者來說，這是一個吸引力十足的目標，讓他們能夠「放大」反射攻擊。如果將少量詐騙性 UDP DNSSEC 要求傳送到名稱伺服器，則受害者將收到大量反射流量。有時，這足以使受害者的伺服器不堪重負，並導致拒絕服務。

從根伺服器要求不存在的 TLD 將返回大約 100 位元組的答案，同一問題的簽署答案約為 650 位元組或放大因數為 6.5。根使用 1,024 位元 RSA 金鑰進行簽署，並將 NSEC 用於否定答案。若要透過使用 1,024 位元金鑰簽署的 NSEC3 要求 TLD 中不存在的網域，則將產生大約 10 的放大因數。還有其他查詢可以產生更高的放大因數，最有效的是「ANY」查詢。

與許多服務一樣，DNS 也可以透過 TCP 運作。有一個「截斷」標誌可以傳送回解析程式，表示需要 TCP。這將解決 DNS 反射問題，但代價是 DNS 要求速度較慢。此解決方案目前不實用，因為 16% 的解析程式不遵守 TCP 截斷標誌，4% 的解析程式不嘗試第二台伺服器。

另一種減小回應規模的選項是使用橢圓曲線數位簽章演算法 (ECDSA) 金鑰，而不是傳統的 RSA 金鑰。ECDSA 金鑰比同等強度的 RSA 金鑰小得多，並且其產生的簽章更小 ，使 DNSSEC 回應規模更小，從而降低了放大因數。Google 公用 DNS 在 2014 年末增加了對 ECDSA 的支援，從那時起其他幾個 DNS 也開始 紛紛效仿。

對 TCP 和 ECDSA 的支援仍然落後於一般的 DNSSEC 支援，因此可以改用傳統的反濫用方法。這包括回應速率限制 (RRL) 及其他啟發式方法。

為了防止反射攻擊，Cloudflare 正在研究一種多管齊下的方法。首先，使用我們目前在 DNS 伺服器中所用的攻擊識別啟發式方法及反濫用技術，其次降低 DNSSEC 回應的放大因數。降低最大放大因數的方法包括：僅透過 TCP 回覆「ANY」要求，盡可能使用較小的 ECDSA 金鑰，以及降低金鑰變換的頻率。

Cloudflare 意識到 DNSSEC 在區域隱私權、金鑰管理及反射/放大風險方面具有複雜性。透過明智的工程決策及適當的操作控制，可以防止 DNSSEC 帶來的危險。