DNSSEC 是一個複雜的話題,更令人困惑的是,IANA 定義的用於對 DNS 記錄進行簽名的幾種標準安全演算法的可用性。演算法 13 是橢圓曲線數位簽名演算法 (ECDSA) 的變體。雖然目前只有不到 0.01% 的域使用,但我們認為 ECDSA 幫助我們消除了廣泛採用 DNSSEC 的最後兩個障礙:區域枚舉和 DDoS 放大。
即時簽名可防止區域枚舉,並且只有在快速生成 ECDSA 簽名時,這才具有計算效率。橢圓曲線產生的密鑰和簽名也比 RSA 對應物小得多,這意味著對 DNS 查詢的回應更小。這大大降低了基於 DNS 的 DDoS 攻擊的放大係數。
雲端版是全球最大的託管 DNS 供應商。我們真正不希望的是將我們的 DNSSEC 伺服器變成分散式拒絕服務 (DDoS) 攻擊的放大媒介。每次從 DNSSEC 伺服器請求記錄時,還會傳回與該記錄關聯的簽章,以及用於驗證該簽章的公開金鑰。這可能是很多資訊。
使 DNSSEC 查詢的回應大小盡可能小是防止潛在攻擊者濫用我們的 DNS 基礎結構的重要要求。橢圓曲線數位簽章演算法 (ECDSA) 金鑰和簽章的尺寸很小,這大大有助於實現這一目標。
使用 ECDSA 實現 128 位元安全性需要 256 位元金鑰,而可比較的 RSA 金鑰需要 3072 位元。這是一個 12 倍的放大因數,僅運用金鑰。您可以在此部落格文章中閱讀關於為什麼密碼編譯金鑰大小不同的更多資訊。
但是,大多數 RSA 金鑰不是 3072 位元,因此 12 倍的放大倍數可能不是最實際的。讓我們來看看 DDoS 放大的最壞情況,這是一個負面回應(NSEC 記錄)。對於雲端版(使用 ECDSA 簽章和 DNSSEC 善意謊言)後面的網域,典型的 DNSSEC 回應為 377 個位元組。將其與不使用 ECDSA 或 DNSSEC 善意謊言的網域的 1075 位元組進行比較。
考慮到事實上所有其他大規模 DNSSEC 實現都依賴於 RSA 簽章,攻擊者利用我們的 DNSSEC 基礎架構作為 DDoS 向量是沒有吸引力的。
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.bsInternet.bs、和 .NZ 註冊機構增添了對演算法 13 的支援。
我們相信,DNSSEC 是現代網路必不可少的技術而且,ECDSA 實現全球採用 DNSSEC 成為可能。希望我們能繼續看到網域名稱註冊商和註冊機構(無論規模)支援演算法 13。
在 5 分鐘內建立網域。保留您的代管提供者。無需更改程式碼。