DNSSEC - 它如何防止 MITM 攻擊？
我已經閱讀了幾個小時
DNSSEC，但我仍然無法理解它如何保護免受MITM攻擊。我還在這裡閱讀了與 serverfault 相關的所有問題DNSSEC。請看一下這個
DNSSEC數據包擷取：https ://www.cloudshark.org/captures/79e23786259b是什麼阻止了攔截每個查詢，並為每個和記錄
MITM用自己的密鑰對回复？DNSKEYS``RRSIG``DS例如，
MITM將為 www.ietf.org 生成 RRSIG，然後DNSKEYS為生成 RRSIG，ietf.org然後為 生成DS記錄ietf.org。然後是“org”的另一組DNSKEYS和DS記錄，然後是<Root>.在 TLS 中，我們可以信任 CA 的信任鏈，因為根 CA 已預安裝在每個系統上，因此我們可以根據它檢查回复。在
DNSSEC中，我不相信 rootDNSKEY安裝在像 Root CA 那樣的系統上。那麼是什麼讓我們可以信任我們收到的這個根密鑰呢？
這個問題通過信任鏈
DS解決：這個鏈中的每個連結都在前一個區域中籤署了記錄，正如您的問題中已經提到的。這強調了根名稱伺服器上的錨點的重要性。如果這是欺騙，則整個信任鏈都會受到損害。因此，解析器必須預先配置信任錨。RFC 6781解釋：4.2.3。解析器中錨定的密鑰的妥協
密鑰也可以在解析器中預先配置為信任錨。如果信任錨密鑰被洩露，則應通知使用這些密鑰的解析器管理員這一事實。區域管理員可能會考慮建立一個郵件列表來傳達 SEP 密鑰即將更新的事實。這種通信當然需要通過某種方式進行認證，例如，通過使用數字簽名。
面臨更新錨定密鑰任務的最終使用者應始終驗證新密鑰。新密鑰應在帶外進行身份驗證，例如，通過使用使用傳輸層安全性 (TLS) 保護的公告網站 $$ RFC5246 $$.
您可以直接從 Internet Systems Consortium下載Current Root Trust Anchors (
bind.keys) 。該站點使用 TLS 進行保護，並且該文件也使用其簽名密鑰進行簽名。如果您沒有任何內容
named.conf並且沒有bind.keys文件，named 將使用已編譯的 in 鍵。注意：這些是託管密鑰，所以這僅適用於您第一次執行命名。假設密鑰尚未過期（在這種情況下，named 將記錄密鑰已過期並且驗證將不起作用），named 將使用 RFC 5011 檢測新密鑰並自動滾動和維護密鑰。一旦命名為管理鍵，目前鍵將在
managed-keys.bindor中*.mkeys，如果您使用視圖。**另一個問題是與您的解析器的通信，即“最後一英里”。**解析器可能正在驗證簽名並使用 DNS身份驗證數據(AD) 位進行回答，但由於 DNS 以純文字形式工作，結果可能會被中間人 (MITM) 攻擊者修改。對此有多種可能的解決方案：
- 您可以擁有一個具有錨鍵文件的本地解析器，但這對於大眾來說並不是一個實用的解決方案。如果沒有配置轉發器，它還會導致更多流量到根名稱伺服器。這是一個不信任任何人的解決方案，您可以自己驗證簽名。
- DNS-over-TLS和DNS-over-HTTPS。例如 Cloudflare 及其
1.1.1.1支持：需要的是轉向新的現代協議。有一對
的不同方法。一種是 DNS-over-TLS。這需要現有的 DNS 協議並添加傳輸層加密。另一個是基於 HTTPS 的 DNS。它包括安全性以及所有現代增強功能，例如支持其他傳輸層（例如，QUIC）和伺服器 HTTP/2 伺服器推送等新技術。DNS-over-TLS 和 DNS-over-HTTPS 都是開放標準。
我們認為 DNS-over-HTTPS 特別有前景——快速、更易於解析和加密。– – 我們希望隨著獨立的 DNS-over-HTTPS 服務現在可用，我們將看到更多來自瀏覽器、作業系統、路由器和應用程序的實驗來支持該協議。
- DNSCrypt使用加密簽名對 DNS 客戶端和 DNS 解析器之間的通信進行身份驗證。這從未向 IETF 提出過（沒有 RFC）。