DNSSEC 是一個複雜的話題，更令人困惑的是，IANA 定義的用於對 DNS 記錄進行簽名的幾種標準安全演算法的可用性。Algorithm 13 是橢圓曲線數位簽名演算法 (ECDSA) 的變體。雖然目前只有不到 0.01% 的域使用，但我們認為 ECDSA 幫助我們消除了廣泛採用 DNSSEC 的最後兩個障礙：區域枚舉和 DDoS 放大。
閱讀本文後，您將能夠：
複製文章連結
DNSSEC 是一個複雜的話題，更令人困惑的是，IANA 定義的用於對 DNS 記錄進行簽名的幾種標準安全演算法的可用性。Algorithm 13 是橢圓曲線數位簽名演算法 (ECDSA) 的變體。雖然目前只有不到 0.01% 的域使用，但我們認為 ECDSA 幫助我們消除了廣泛採用 DNSSEC 的最後兩個障礙：區域枚舉和 DDoS 放大。
即時簽名可防止區域枚舉，並且只有在快速生成 ECDSA 簽名時，這才具有計算效率。橢圓曲線產生的密鑰和簽名也比 RSA 對應物小得多，這意味著對 DNS 查詢的回應更小。這大大降低了基於 DNS 的 DDoS 攻擊的放大係數。
DNSSEC 透過 NSEC 和 NSEC3 記錄引入對否認存在的答覆進行身份驗證。但是，正如我們在 DNSSEC 複雜性和注意事項中所討論，NSEC 和 NSEC3 都允許攻擊者在區域中行走。解決方案是稱為「DNSSEC 善意謊言」（在 RFC 4470 和 4471 中描述）的聰明技術，但只能在對 DNSSEC 記錄進行動態簽署情況中實施。
RSA 最廣泛的簽署演算法是 DNSSEC，部分原因是這是通訊協定定義的唯一必需演算法。不幸的是，使用 RSA 進行即時簽署的成本高得令人望而卻步。
ECDSA 獲得的效能是顯著的。與可比較的 RSA 簽章相比，產生 ECDSA 簽章的計運算成本減少 10 倍。這使得即時簽署（和 DNSSEC 善意謊言）可行，即使大規模也是如此。
在我們的 DNSSEC 測試期間（已簽署的網域少於 1,000 個），Cloudflare 已經每秒回答數以萬計的 DNSSEC 查詢。每天有超過 10 億次查詢，我們動態簽署所有必要的 RRSIG 記錄。簽署比 RSA 快 10 倍的演算法在載入到我們的 DNSSEC 伺服器上時會產生巨大改變。
當我們開始與 ECDSA 合作時，我們在 Go 中使用的 OpenSSL 實施。考慮到我們正在做的所有簽署，最佳化簽章產生是首要重點。因此，我們重寫 ECDSA 實施是低階組合語言，現在比 Go 中的快 20 倍以上。該程式碼已開放原始碼，將進入 Go 1.7，使整用個加密社群都可以利用我們的最佳化。瞭解更多
Cloudflare 是全球最大的受管理 DNS 提供者。我們真正不希望的是將我們的 DNSSEC 伺服器變成分散式拒絕服務 (DDoS) 攻擊的放大媒介。每次從 DNSSEC 伺服器請求記錄時，還會傳回與該記錄關聯的簽章，以及用於驗證該簽章的公開金鑰。這可能是很多資訊。
使 DNSSEC 查詢的回應大小盡可能小是防止潛在攻擊者濫用我們的 DNS 基礎架構的重要要求。橢圓曲線數位簽章演算法 (ECDSA) 金鑰和簽章的尺寸很小，這大大有助於實現這一目標。
使用 ECDSA 實現 128 位元安全性需要 256 位元金鑰，而可比較的 RSA 金鑰需要 3072 位元。這是一個 12 倍的放大因數，僅運用金鑰。您可以閱讀這篇部落格文章，深入瞭解為什麼密碼編譯金鑰有不同大小。
但是，大多數 RSA 金鑰不是 3072 位元，因此 12 倍的放大倍數可能不是最實際的。讓我們來看看 DDoS 放大的最壞情況，這是一個負面回應（NSEC 記錄）。對於 Cloudflare（使用 ECDSA 簽章和 DNSSEC 善意謊言）後面的網域，典型的 DNSSEC 回應為 377 個位元組。將其與不使用 ECDSA 或 DNSSEC 善意謊言的網域的 1075 位元組進行比較。
考慮到事實上所有其他大規模 DNSSEC 實現都依賴於 RSA 簽章，攻擊者利用我們的 DNSSEC 基礎架構作為 DDoS 向量是沒有吸引力的。
ECDSA 解決了 DNSSEC 中的主要問題，但全球 DNSSEC 社群幾乎沒有利用 ECDSA。我們簡要介紹了 ECDSA 在根 DNS 區域和 Alexa 的前 100 萬個網站中的採用情況。
首先，我們檢查了根 DNS 區域，看看頂層網域名使用的是哪種 DNSSEC 演算法。下表顯示了根區域檔案中的 DS 記錄指定的安全演算法：
curl -s http://www.internic.net/domain/root.zone | awk '$4 == "DS" { print $6}' | sort -n | uniq -c
我們對 Alexa 的前 100 萬個網站進行了類似的分析，為我們提供了一個總體全球網際網路流量截面：
| 演算法 | 已簽署的 DS 記錄數 |
|---|---|
| 1 (RSA/MD5) | 1 |
| 3 (DSA/SHA1) | 10 |
| 5 (RSA/SHA-1) | 3322 |
| 7 (RSASHA1-NSEC3-SHA1) | 5083 |
| 8 (RSA/SHA-256) | 7003 |
| 10 (RSA/SHA-512) | 201 |
| 13 (使用 SHA-256 的 ECDSA Curve P-256) | 23 |
最引人注目的啟示是，在 1,000,000 個網站中，只有 15,643 個網站以任何處理能力啟用了 DNSSEC。在這 1.5% 中，只有 23 個區域使用 Algorithm 13 進行簽署。而且，這些 Algorithm 13 區域中有一半以上受到 Cloudflare 網路保護。這意指在 Cloudflare 之外，在 Alexa 的前 100 萬個網站中只有不到十幾個區域使用 ECDSA。這支援了 Roland van Rijswijk-Deij 等人的研究結果，即 .com、.net 和 .org 中 99.99% 的簽名網域都使用 RSA。
那麼，為什麼 Algorithm 13 的使用率如此之低，特別是考慮到它解決了 DNSSEC 中的如此重大問題的事實？好吧，RSA 是從通訊協定的一開始就與 DNSSEC 一起引入的。ECDSA 是一種新的加密演算法、解析程式、網域名稱註冊商和註冊機構仍在迎頭趕上。
ECDSA 並非沒有權衡取捨。根據 Roland van Rijswijk-Deij 等人的研究，只有 80% 的解析程式支援 ECDSA 驗證。這個數字還在成長，但這意指，如果我們立即把整個 DNSSEC 網際網路切換到 ECDSA 上，則每天有數百萬網際網路使用者的 DNSSEC 驗證將失敗並回復為傳回未經驗證的 DNS 記錄。
此外，雖然 ECDSA 簽章的建立速度比 RSA 快，簽章驗證實際上要慢得多。Roland van Rijswijk-Deij 等人表明，即使 ECDSA 經最佳化，我們為開放 SSL 做出貢獻，ECDSA 仍然比 1024 位元 RSA（這是用於區域簽署金鑰的最常見演算法）慢 6.6 倍。這是一個嚴重的問題，因為 DNS 解析程式過載可能會減慢整個網際網路的速度。
所有這些關於 Algorithm 13 的討論，有一個非常重要的注意事項：只有 1.5% 的 Web 內容支援任何處理能力的 DNSSEC。並非所有網域名稱註冊商都支援 DNSSEC，而增添支援也絕非易事。他們需要允許使用者上傳 DS 記錄，而這些記錄又需要由網域名稱註冊商上傳到註冊機構。我們正在努力使這成為一個自動化過程，如今，網域名稱註冊商甚至不需要上傳 DS 記錄，但仍然需要註冊機構的介入。
好消息是，我們正朝著正確的方向發展。在過去的 12 個月，DNSSEC 總體上已經看到了相當數量的成長。而且，在我們的公共 DNSSEC 測試版與通用版 DNSSEC 公告之間的三週內，Hover、OVH、Metaname、Internet.bs 和 .NZ 註冊機構增添了對 Algorithm 13 的支援。
我們相信，DNSSEC 是現代 Web 必不可少的技術而且，ECDSA 實現全球採用 DNSSEC 成為可能。希望我們能繼續看到網域名稱註冊商和註冊機構（無論規模）支援 Algorithm 13。