☰

DNSSEC 是否经常出现故障，或者 systemd-resolved 是否过于热心？

tag-icon • tag-icon dns systemd
DNSSEC 是否经常出现故障，或者 systemd-resolved 是否过于热心？

我最近将 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 机制，但这是我的看法：

萨凡纳

这真是一团糟。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 记录，则未签名的子区域是可以的，它通过返回签名的 NSEC 记录来代替答案来证明这一点；NSEC“不存在证明”表示全部此名称存在或不存在的记录类型。

因此，父“gnu.org”区域正确地声明“savannah.gnu.org”的 DS 记录不存在……但它还声明NS 记录也不存在，即，该名称根本没有委托给子区域。（但显然有一个 SSHFP 记录……）

由于验证者有原始的未签名答案，表明它来自一个子区域，并且有签名证明表明存在不委派给子区域，验证必定失败。

...但是，正如 #1 中提到的那样，这些检查都不应该首先进行，因为父级org.区域还证明其委托gnu.org.未签名，这意味着来自 gnu.org 的任何 NSEC 记录都无效。Systemd-resolved 不应该查看它们 - 它应该将整个 gnu.org 区域视为没有任何 DNSSEC。

相关内容