☰

全力投入 DNSSEC

tag-icon • tag-icon dns resolv.conf dig systemd-resolved dnscrypt
全力投入 DNSSEC

我一直在努力通过以下设置在我的系统上全面启用 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）查询？

任何见解表示赞赏！

答案1

如果 和dnscrypt-proxy都systemd-resolved使用127.0.0.1:53，则情况不应如此。您需要systemd-resolved按照建议禁用dnscrypt-proxy 维基，并锁定/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 的。

参考：

相关内容