在 DNSSEC 上全力以赴

我一直在努力通過以下設置在我的系統上全面使用 DNSSEC：

• dnscrypt-proxy在 127.0.0.1 上安裝、啟動並執行require_dnssec = true
• systemd-resolved running, with DNSSEC=yesandDNS=127.0.0.1
• 只nameserver 127.0.0.1在/etc/resolv.conf
• 通過 NetworkManager 連接到我知道的 WiFi 網路 DHCP 配置將 8.8.8.8 和 8.8.8.4 設置為 DNS 伺服器

/run/systemd/resolve/resolv.conf在 127.0.0.1 下列出 8.8.8.8 和 8.8.8.4。

resolvectl status節目

DNSSEC setting: yes
DNSSEC supported: yes
Current DNS Server: 127.0.0.1
DNS Servers: 127.0.0.1

在全域部分，但

DNSSEC setting: yes
DNSSEC supported: yes
Current DNS Server: 8.8.8.8
DNS Servers: 8.8.8.8
                          8.8.8.4

在我的界面部分（為什麼？）。

tcpdump使用 Web 瀏覽器、探勘或其他正常使用時，在 udp:53 上根本沒有任何活動。這意味著我的本地 dnscrypt-proxy 正在處理我係統上的所有 DNS 請求。我還假設由於上面提到的配置設置，我會一路走 DNSSEC。

但是，該期刊不時包含以下行：

Nov 30 09:10:41 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question v.dropbox.com IN SOA: failed-auxiliary
Nov 30 09:10:41 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question bolt.v.dropbox.com IN DS: failed-auxiliary
Nov 30 09:10:41 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question bolt.v.dropbox.com IN SOA: failed-auxiliary
Nov 30 09:10:41 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question bolt.v.dropbox.com IN A: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question v.dropbox.com IN SOA: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question d.v.dropbox.com IN A: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question v.dropbox.com IN SOA: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question d.v.dropbox.com IN A: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question d2e801s7grwbqs.cloudfront.net IN SOA: failed-auxiliary
Nov 30 09:10:43 tuxifaif systemd-resolved[179937]: DNSSEC validation failed for question d2e801s7grwbqs.cloudfront.net IN A: failed-auxiliary

• resolvectl query v.dropbox.com導致相同的 DNSSEC 驗證錯誤
• dig v.dropbox.com工作得很好
• dig v.dropbox.com @8.8.8.8也可以正常工作（當然會產生兩行輸出tcpdump）

我還檢查了https://dnsleaktest.com，它告訴我很多 172.253.xx 伺服器正在接收解析我在網路瀏覽器中輸入的域名的請求。這些 IP 似乎歸 Google 所有。

那麼這是什麼意思？該系統上是否正在進行任何（非 DNSSEC）查詢？

任何見解表示讚賞！

如果兩者都使用dnscrypt-proxy和，則不應如此。您需要按照dnscrypt-proxy wiki的建議禁用，並鎖定網路管理器可能進行的更改。所以，這裡是步驟：systemd-resolved``127.0.0.1:53``systemd-resolved``/etc/resolv.conf

• 禁用systemd-resolved：

sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved

• 檢查是否有其他東西使用與:相同的address:port對。如果有，請禁用它們。dnscrypt-proxy``sudo ss -lp 'sport = :domain'
• 如果dnscrypt-proxy正在偵聽127.0.0.1:53並且resolv.conf有，請在條目下方nameserver 127.0.0.1添加（啟用 DNS 安全擴展所必需的） ，使其看起來像：options edns0``nameserver``resolv.conf

nameserver 127.0.0.1
options edns0

• 鎖定/etc/resolv.conf文件以進行更改：sudo chattr +i /etc/resolv.conf.
• 您可能需要重新啟動dnscrypt-proxy.

總的來說，關鍵是要確保：

• 只是dnscrypt-proxy在使用127.0.0.1:53
• resolv.conf具有相同的地址dnscrypt-proxy
• resolv.conf受到其他軟體（例如您的網路管理器）所做更改的保護。

此外，dnsleak 測試顯示 Google IP 並不意味著 dns 解析器服務由 Google 運營。伺服器可能歸 Google 所有，但由另一個實體運營。如果您不想要它，您可以從dnscrypt-proxy public resolvers list中選擇不同的解析器。確保dnssec為所選解析程序提供支持。我個人使用 dnscrypt.eu 解析器，它們是無日誌、無過濾器、非Google和啟用 dnssec 的。

參考：

• https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Installation-linux
• https://github.com/DNSCrypt/dnscrypt-proxy/wiki/systemd

引用自：https://unix.stackexchange.com/questions/554896