網域名稱系統 (DNS) 就如同網際網路的電話簿:它會告訴電腦向哪裡傳送資訊,以及從哪裡擷取資訊。可惜的是,這也接受網際網路提供的任何位址,而不會進行任何詢問。
閱讀本文後,您將能夠:
複製文章連結
電子郵件伺服器使用 DNS 路由郵件,這意味著它們容易受到 DNS 基礎架構的安全性問題影響。2014 年 9 月,CMU 的研究人員發現本應透過 Yahoo!、Hotmail 和 Gmail 伺服器發送的電子郵件透過流氓郵件伺服器進行路由。攻擊者利用了網域名稱系統(DNS)中一個已存在數十年之久的漏洞,即接受應答前不會檢查憑據。
這個問題的解決方案是一種名為 DNSSEC 的通訊協定。這種通訊協定透過提供驗證,在 DNS 之上又增加了一層信任。當 DNS 解析程式尋找 blog.cloudflare.com 時,.com 名稱伺服器會幫助解析程式驗證針對 cloudflare 傳回的記錄,而 cloudflare 會幫助驗證針對 blog 傳回的記錄。根 DNS 名稱伺服器幫助驗證 .com,而根目錄發佈的資訊將透過徹底的安全性程序(包括「根簽署儀式」)進行審核。
DNSSEC 對現有 DNS 記錄新增加密簽章,藉此保護網域名稱系統的安全。這些數位簽章與 A、AAAA、MX、CNAME 等常見記錄類型一起儲存在 DNS 名稱伺服器中。透過檢查其相關簽名,您可以驗證所請求的 DNS 記錄是否來自其權威名稱伺服器,並且在途中沒有被變更,不是在中間人攻擊中注入的虛假記錄。
為了促進簽章驗證,DNSSEC 新增了一些新的 DNS 記錄類型:
RRSIG、DNSKEY 和 DS 記錄之間的互動,以及它們如何在 DNS 之上新增信任層,就是我們在本文中要討論的內容。
使用 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。
現在,解析程式的驗證如下所示:
當然,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 位址。
由於對 DNSSEC 的信任是自上而下的(根區域驗證 .com 區域,.com 區域驗證 cloudflare.com 區域,以此類推),啟用 DNSSEC 需要網站擁有者與您(註冊商)一起更新 DS 記錄。
這部分是有問題的——複製和貼上 DS 記錄會增加人為錯誤的可能性,並給不太擅長的使用者增加一定的難度。我們希望使 DNSSEC 盡可能易於部署。
如果 Cloudflare 可以直接與註冊商或註冊機構通訊,我們可以自動為 Cloudflare 上的每個網站啟動 DNSSEC,並在沒有人為干預的情況下管理其金鑰。
作為 DNSSEC 推出的一部分,我們與 .ca 註冊機構 CIRA 一起發布網際網路草案,為 Cloudflare 等 DNS 營運商提出了一種通訊協定:與註冊商和註冊機構進行通訊,以實現 DNSSEC 自動化管理。
一些註冊機構已經計劃增添支援,例如 NIC Chile (.cl) 和 eNIC (.ee)。如果您為註冊商或註冊機構工作,並有興趣瞭解更多資訊、參與開發通訊協定或新增與 Cloudflare 的整合,請透過電子郵件 dnssec-integration@cloudflare.com 聯絡我們。
與 HTTPS 相似,DNSSEC 在原本不安全的通訊協定之上啟用經過驗證的答案,因此增加了一層安全性。HTTPS 會對流量進行加密,以便網路上的任何人都無法窺探您的網際網路活動,而 DNSSEC 只是對回應進行簽名,從而偵測偽造回應。DNSSEC 提供了解決實際問題的解決方案,並且無需結合加密。
Cloudflare 的目標是讓啟用 DNSSEC 的過程盡可能輕鬆。所有 Cloudflare 客戶都可以透過以下方式將 DNSSEC 新增到其 Web 內容中:點按開關以啟用 DNSSEC,然後將 DS 記錄(我們將自動產生)上傳到其網域名稱註冊商。詳細瞭解如何取得 DNSSEC。
我們還發佈了一份網際網路草案,其中概述了註冊機構和網域名稱註冊商代表我們的客戶上傳 DS 記錄的一種自動方法。透過這種方法,Cloudflare 能夠為我們的整個社群自動啟用 DNSSEC。請關注最新更新。
入門
關於 DNS
DNS 伺服器
DNS 記錄
DNS 詞彙