#main-nav-header { display:none; }

DNSSEC 如何運作

網域名稱系統 (DNS) 就如同網際網路的電話簿：這告訴電腦向哪裡發送資訊，以及從哪裡檢索資訊。可惜的是，這也接受網際網路提供的任何位址，而不會進行任何詢問。

電子郵件伺服器使用 DNS 路由郵件，這意味著它們容易受到 DNS 基礎結構的安全性問題影響。2014 年 9 月，CMU 的研究人員發現，本應透過 Yahoo!、Hotmail 和 Gmail 伺服器發送的電子郵件變成透過流氓郵件伺服器發送。攻擊者利用了網域名稱系統（DNS）中一個已存在數十年之久的漏洞，即接受應答前不會檢查憑據。

這個問題的解決方案是一種名為 DNSSEC 的協議。通過提供身份驗證，這種協議在 DNS 之上增加了一個信任層。在某個 DNS 解析器查找 blog.cloudflare.com 時，.com 名稱伺服器幫助解析器驗證針對 cloudflare 傳回的記錄，而 cloudflare 幫助驗證針對 blog 傳回的記錄。根 DNS 名稱伺服器幫助驗證 .com，而根伺服器發佈的資訊將透過一個徹底的安全性程序 (包括「Root-Signing 儀式」) 進行審核。

委派簽名者記錄

DNSSEC 採用了委派簽名者 (DS) 記錄，以允許將信任從父區域轉移到子區域。區域操作員對包含公用 KSK 的 DNSKEY 記錄進行雜湊處理，並將其提供給父區域以作為 DS 記錄發佈。

每次將解析器引用到子區域時，父區域也會提供 DS 記錄。此 DS 記錄是解析器獲知子區域啟用 DNSSEC 的方式。為了檢查子區域的公共 KSK 的有效性，解析器對其進行雜湊處理並將其與父區域的 DS 記錄進行比較。如果兩者相符，則解析器可以假定公用 KSK 未被篡改，這意味著它可以信任子區域中的所有記錄。這就是在 DNSSEC 中建立信任鏈的方式。

請注意，KSK 的任何變更都需要更改父區域的 DS 記錄。變更 DS 記錄是一個多步驟的過程，如果執行不正確，最終可能會破壞該區域。首先，父項需要新增新的 DS 記錄，然後需要等到原始 DS 記錄的 TTL 過期後將其刪除。這就是為什麼換掉區域簽名金鑰比金鑰簽名金鑰要容易得多。

明確否認存在

如果您向 DNS 詢問不存在的網域 IP 位址，則將傳回一個空答案 - 無法明確答覆「抱歉，您請求的區域不存在」。如果您想對回應進行身份驗證，這就是一個問題，因為沒有可簽名的訊息。DNSSEC 透過新增 NSEC 和 NSEC3 記錄類型來解決此問題。它們都允許對否認存在的答覆進行身份驗證。

NSEC 會傳回「下一個安全」的記錄例如，假設有一個為 api、blog 和 www 定義 AAAA 記錄的名稱伺服器。如果您請求 store 的記錄，則將傳回一個包含 www 的 NSEC 記錄，表示當記錄按字母順序排序時，strore 和 www 之間沒有 AAAA 記錄。這明確地告訴您 store 不存在。並且，由於 NSEC 記錄經過簽名，您可以像驗證任何 RRset 一樣驗證其相應的 RRSIG。

但是，使用這種解決方案，人們無需知道他們要尋找的記錄，就可以流覽區域並收集每條記錄。如果區域管理員希望該區域的內容為私隱內容，則這可能造成潛在的安全性威脅。您可以在 DNSSEC：複雜性和注意事項瞭解有關此問題的更多資訊，並在 DNSSEC Done Right 瞭解 Cloudflare 的獨特解決方案。

信任鏈

現在，在區域內建立信任並將其連接到父區域的方法已經有了，但是我們如何信任 DS 記錄呢？DS 記錄就像其他任何 RRset 一樣簽署，這意味著這在父項中具有相應的 RRSIG。整個驗證過程不斷重複，直到獲得父項的公用 KSK 為止。為了驗證父項的公用 KSK，我們需要轉到父項的 DS 記錄，以此類推，沿著信任鏈上行。

但是，當我們最終到達根 DNS 區域時，又有一個問題：沒有父項 DS 記錄可用於驗證。在這裡，我們可以看到全球網際網路非常人性的一面：

在「根區域簽名儀式」上，來自世界各地的特定幾人以公開且經嚴格審核的方式簽署根 DNSKEY RRset。這次儀式會產生一個 RRSIG 記錄，該記錄可用於驗證根名稱伺服器的公用 KSK 和 ZSK。我們不會由於父項的 DS 記錄而信任公用 KSK，而是因為信任存取私有 KSK 所涉的安全性過程而假定其有效。

在父區域和子區域之間建立信任的能力是 DNSSEC 不可或缺的一部分。如果信任鏈中的任何部分被破壞，我們就不能信任我們所請求的記錄，因為中間人可能會變更記錄並將我們引導到任何 IP 位址。

Summary

Similar to HTTPS, DNSSEC adds a layer of security by enabling authenticated answers on top of an otherwise insecure protocol. Whereas HTTPS encrypts traffic so nobody on the wire can snoop on your Internet activities, DNSSEC merely signs responses so that forgeries are detectable. DNSSEC provides a solution to a real problem without the need to incorporate encryption.

Cloudflare’s goal is to make it as easy as possible to enable DNSSEC. All Cloudflare customers can add DNSSEC to their web properties by flipping a switch to enable DNSSEC and uploading a DS record (which we'll generate automatically) to their registrar.: Learn more about how to get DNSSEC.

We’ve also published an Internet Draft outlining an automated way for registries and registrars to upload DS records on behalf of our customers. This will enable Cloudflare to automatically enable DNSSEC for our entire community. Stay tuned for updates.

深受數百萬網際網路資產的信賴

檢視案例研究