☰

DNSSEC 是否經常被破壞，或者 systemd 解析過於熱心？

tag-icon • tag-icon dns systemd
DNSSEC 是否經常被破壞，或者 systemd 解析過於熱心？

我最近切換了 DNS 解析器，systemd-resolved以便開始利用可用的 DNSSEC。我的配置是：

[Resolve]
DNS=8.8.8.8 8.8.4.4
DNSOverTLS=yes

（包括註解掉的預設值DNSSEC=allow-downgrade）

對於大多數網站來說，一切似乎都運作良好，無論是否啟用了 DNSSEC。然而，有時我會造訪一個無法解析的網站：

$ resolvectl query savannah.gnu.org
savannah.gnu.org: resolve call failed: DNSSEC validation failed: failed-auxiliary
$ resolvectl query keys.mailvelope.com
keys.mailvelope.com: resolve call failed: DNSSEC validation failed: failed-auxiliary
$ resolvectl query d1dkupr86d302v.cloudfront.net
d1dkupr86d302v.cloudfront.net: resolve call failed: DNSSEC validation failed: failed-auxiliary

我試圖透過以下方式驗證這一點DNSSEC 分析器（用於 savannah.gnu.org）。但是，我確實很難理解結果。我真的不明白它與任何其他未啟用 DNSSEC 的網域有何不同。

我的問題是：DNSSEC 是否經常被破壞，或者 systemd-resolved 在這裡做錯了什麼？

答案1

可能兩者都是。總的來說，根據先前的報告，我傾向於後者（systemd-resolved 在某些情況下過於嚴格）。然而，根據 DNSViz，域的配置也沒有完全通過所有檢查。

我也不能 100% 確定某些 DNSSEC 機制，但這是我的看法：

薩凡納.gnu.org

這是一個巨大的混亂。 Systemd-resolved 正確偵測到網域的問題...但根據不應該信任的資訊錯誤地拒絕它。

  1. 該gnu.org.區域有簽名，但其委託org.不包含任何用於驗證簽名的金鑰，因此解析器根本不應該查看這些簽名 - 它們不再是信任鏈的一部分。然而，systemd-resolved 無論如何都會查看它們。

  2. 該savannah.gnu.org.名稱存在於兩個地方，並且彼此不一致。如果沒有 DNSSEC，這個問題不會被注意到，但使用 DNSSEC 驗證總是會失敗。然而，由於問題#1，即使 systemd-resolved 應該悄悄地忽略它，它也會失敗驗證。

關於 #2 的更多細節：

相同的名稱伺服器託管著已簽署的父區域gnu.org.和未簽署的子區域savannah.gnu.org.。問題是前者缺乏對後者的實際 NS 委託；相反，它僅具有該名稱的普通非委託記錄。

事情之所以有效，是因為兩個區域都由相同的名稱伺服器託管，因此首先，當您在「savannah.gnu.org」查詢 A 或 AAAA 記錄時，答案會自動從未簽署的子區域提供。

很明顯，它是一個單獨區域的開始，因為它有 SOA 記錄。但是 DNSSEC 驗證器需要知道該區域是否應該簽名，因此它嘗試查詢 DS 記錄（或缺少 DS 記錄），這次回應始終由父區域提供。

如果父區域沒有任何 DS 記錄，則未簽署的子區域是可以的，它會透過傳回簽署的 NSEC 記錄來代替答案來證明； NSEC「不存在證明」表示全部該名稱存在或不存在的記錄類型。

因此，父“gnu.org”區域正確地聲稱“savannah.gnu.org”的 DS 記錄不存在......但它也聲稱NS記錄也不存在，即該名稱根本沒有委託給子區域。（不過顯然有一個 SSHFP 記錄......）

由於驗證器有原始的未簽名答案表明它來自子區域，並且簽名證明表明存在不委派給子區域時，驗證必須失敗。

……但是，如 #1 中提到的，這些檢查都不應該首先完成，因為父-父org.區域也證明其委託gnu.org.未簽名，這意味著來自 gnu.org 的任何 NSEC 記錄都沒有實際意義。 Systemd-resolved 不應該關注它們——它應該將整個 gnu.org 區域視為沒有任何 DNSSEC。

相關內容