DNSSEC 如何運作

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。請關注最新消息。