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

解決方案

產品

定價

資源

合作夥伴

為何選擇 Cloudflare

註冊

遭到攻擊？

支援

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 簡介

DNSSEC 對現有 DNS 記錄新增加密簽章，藉此保護網域名稱系統的安全。這些數位簽章與 A、AAAA、MX、CNAME 等常見記錄類型一起儲存在 DNS 名稱伺服器中。透過檢查其相關簽名，您可以驗證所請求的 DNS 記錄是否來自其權威名稱伺服器，並且在途中沒有被變更，不是在中間人攻擊中注入的虛假記錄。

為了促進簽章驗證，DNSSEC 新增了一些新的 DNS 記錄類型：

RRSIG - 包含加密簽章
DNSKEY - 包含公共簽名金鑰
DS - 包含 DNSKEY 記錄的雜湊
NSEC 和 NSEC3 - 用於明確否認 DNS 記錄的存在
CDNSKEY 和 CDS - 用於請求對父區域中的 DS 記錄進行更新的子區域。

RRSIG、DNSKEY 和 DS 記錄之間的互動，以及它們如何在 DNS 之上新增信任層，就是我們在本文中要討論的內容。

RRset

使用 DNSSEC 保護某個區域的第一步，是將所有相同類型的記錄分組到一個資源記錄集 (RRset) 中。例如，如果您的區域中有三個具有相同標籤 (如label.example.com)，的 AAAA 記錄，它們將全部捆綁到一個 AAAA RRset 中。

實際上，是整個 RRset 獲得數位簽章，而不是單獨的 DNS 記錄獲得。當然，這也意味著您必須從具有相同標籤的區域中請求並驗證所有 AAAA 記錄，而不是僅驗證其中一個。

區域簽名金鑰

DNSSEC 中的每個區域都有一個區域簽名金鑰配對 (ZSK)：金鑰的專用部分對區域中的每個 RRset 進行數位簽章，而公共部分則驗證簽名。為了啟用 DNSSEC，區域操作員使用專用 ZSK 為每個 RRset 建立數位簽章，並將其作為 RRSIG 記錄儲存在名稱伺服器中。這就像是說：「這些是我的 DNS 記錄，它們來自我的伺服器，看起來應該像這樣。」

但是，除非 DNS 解析器擁有驗證簽名的方法，否則這些 RRSIG 記錄起不到作用。區域操作員還需要將公用 ZSK 新增到 DNSKEY 記錄中的名稱伺服器，方能使其可用。

當 DNSSEC 解析器請求特定的記錄類型 (例如 AAAA) 時，名稱伺服器還會傳回相應的 RRSIG。然後，解析器可以從名稱伺服器中提取包含公用 ZSK 的 DNSKEY 記錄。RRset、RRSIG 和公用 ZSK 將一同用於驗證回應。

如果我們信任 DNSKEY 記錄中的區域簽名金鑰，則可以信任該區域中的所有記錄。但是，如果區域簽名金鑰被洩露怎麼辦？我們需要一種方法來驗證公用 ZSK。

金鑰簽名金鑰

除了區域簽名金鑰之外，DNSSEC 名稱伺服器還具有金鑰簽名金鑰 (KSK)。KSK 驗證 DNSKEY 記錄的方式與上一節中描述的、我們的 ZSK 保護其餘 RRset 的方式完全相同：這簽署公用 ZSK (儲存在 DNSKEY 記錄中)，從而為 DNSKEY 建立 RRSIG。

就像公用 ZSK 一樣，名稱伺服器將公用 KSK 發佈在另一個 DNSKEY 記錄中，而這就給我們提供了上面顯示的 DNSKEY RRset。公用 KSK 和公用 ZSK 均由私有 KSK 簽名。然後，解析器就可以使用公用 KSK 來驗證公用 ZSK。

現在，解析器的驗證如下所示：

請求所需的 RRset，系統還將傳回相應的 RRSIG 記錄。
請求包含公用 ZSK 和公用 KSK 的 DNSKEY 記錄，系統還將傳回 DNSKEY RRset 的 RRSIG。
用公用 ZSK 驗證所請求 RRset 的 RRSIG。
用公用 KSK 驗證 DNSKEY RRset 的 RRSIG。

當然，DNSKEY RRset 和相應的 RRSIG 記錄可以快取，以防 DNS 名稱伺服器被不必要的請求不斷轟炸。

為什麼我們使用單獨的區域簽名金鑰和金鑰簽名金鑰？如我們將在下一節中討論的那樣，要替換掉舊的或受損的 KSK 很難。另一方面，變更 ZSK 就容易得多。這使我們可以使用較小的 ZSK，而不會損害伺服器的安全性，因此最大程度地減少了每次回應時伺服器必須發送的資料量。

現在，我們在區域內建立了信任關係，但是 DNS 是一個分層系統，各區域很少獨立運作。而金鑰簽名金鑰是由其自身簽名的，不會提供額外的信任基礎，因此使情況更加複雜。我們需要一種方法將我們區域中的信任與其父區域聯繫起來。

委派簽名者記錄

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 位址。

概述

與 HTTPS 相似，DNSSEC 在原本不安全的通訊協定之上啟用經過身份驗證的答案，因此增加了一層安全性。HTTPS 會對流量進行加密，以便網路上的任何人都無法窺探您的網際網路活動，而 DNSSEC 只是對回應進行簽名，從而偵測偽造回應。DNSSEC 提供了解決實際問題的解決方案，並且無需結合加密。

Cloudflare 的目標是讓啟用 DNSSEC 的過程盡可能輕鬆。現在，擁有 Cloudflare 付費計畫的客戶可以透過以下方式將 DNSSEC 新增到其 Web 資產中：點按開關以啟用 DNSSEC，然後將 DS 記錄 (我們將自動產生) 上傳到其網域名稱註冊商。詳細瞭解如何獲取 DNSSEC。

我們還發佈了一份網際網路草案，概述了註冊管理機構和網域名稱註冊商代表我們的客戶上傳 DS 記錄的一種自動方法。這將使 Cloudflare 能夠為我們的整個客戶社區自動啟用 DNSSEC。請關注最新消息。

設定 Cloudflare 輕鬆簡單

在 5 分鐘內建立網域。保留您的代管提供者。無需更改程式碼。

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

檢視案例研究