在 DNSSEC 上全力以赴

Question

我一直在努力通过以下设置在我的系统上全面使用 DNSSEC：

• dnscrypt-proxy 在 127.0.0.1 上安装、启动并运行 require_dnssec = true
• systemd解析运行，与DNSSEC=yes和DNS=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 浏览器、dig 或其他正常使用时，在 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）查询正在进行？

任何见解表示赞赏！

Answer 1

如果 和dnscrypt-proxy都systemd-resolved使用127.0.0.1:53，则情况不应如此。您需要systemd-resolved按照dnscrypt-proxy wiki 的建议禁用，并锁定/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，请在条目options edns0下面添加（启用 DNS 安全扩展所需的），使其看起来像：nameserverresolv.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 公共解析器列表中选择不同的解析器。确保dnssec所选解析器支持。我个人使用 dnscrypt.eu 解析器，它是无日志、无过滤器、非 Google 且启用 dnssec 的。

参考：

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