我最近将我的 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 在这里做错了什么？
大概两者都有。总的来说，根据之前的报告，我倾向于后者（systemd-resolved 在某些情况下过于严格）。但是，根据 DNSViz，域的配置也没有完全通过所有检查。
我也不是 100% 确定某些 DNSSEC 机制，但这是我的看法：
这是一个巨大的混乱。Systemd-resolved 正确地检测到域的问题......但根据它不应该信任的信息错误地拒绝了它。
该gnu.org.区域有签名，但它的委派org.不包括任何用于验证它们的密钥，因此解析器根本不应该查看这些签名——它们不再是信任链的一部分。但是，systemd-resolved 无论如何都会查看它们。
这个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 记录代替答案来证明这一点；te NSEC“不存在证明”表示该名称存在或不存在的所有记录类型。
所以父“gnu.org”区域正确地声称“savannah.gnu.org”的DS记录不存在......但它也声称NS记录也不存在，即名称未委托到子区。（虽然显然有一个 SSHFP 记录......）
由于验证者拥有表明它来自子区域的原始未签名答案，以及表明没有对子区域的委派的签名证明，因此验证必须失败。
...但是，正如 #1 中提到的，首先不应该进行这些检查，因为父-父org.区域也证明其委派gnu.org.是未签名的，这意味着来自 gnu.org 的任何 NSEC 记录都没有实际意义. Systemd-resolved 不应该查看它们——它应该将整个 gnu.org 区域视为没有任何 DNSSEC。