dnsmasq 对 DNSSEC 验证返回 (false)“虚假”结果

Question

dnsmasq我正在运行本地 Debian 8.1 安装，其中有一个名为(版本2.72-3+deb8u1)的 DNSSEC 验证 DNS 解析器。

我将其设置为SERVFAIL如果无法验证启用 DNSSEC 的域则返回，即，如果该域具有 DNSSEC 条目，则必须正确验证它才能转发到客户端。

今天我浏览的时候，想访问一下相当著名的因特网工程任务组但我无法做到，因为无法解析域名。我使用命令行进行检查以验证这一点，结果确实得到了SERVFAIL。我使用 Google DNS 服务器 (8.8.8.8) 进行了检查，结果没有得到任何结果，SERVFAIL只有 IP 地址。

之后，我启用了每个 DNS 请求的日志记录并检查了结果。看来我的感觉是对的，DNSSEC 验证失败了，尽管它从 DNS 转发器获得的响应与我从 Google 获得的响应相同。

这是我的相应行syslog：

Sep  5 13:27:13 dnsmasq: query[A] www.ietf.org from 192.168.1.10
Sep  5 13:27:13 dnsmasq: forwarded www.ietf.org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: forwarded www.ietf.org to 178.63.73.246
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] ietf.org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DS] ietf.org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DS] org to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] . to 81.3.21.188
Sep  5 13:27:13 dnsmasq: reply . is DNSKEY keytag 1518
Sep  5 13:27:13 dnsmasq: reply . is DNSKEY keytag 19036
Sep  5 13:27:13 dnsmasq: reply org is DS keytag 21366
Sep  5 13:27:13 dnsmasq: reply org is DS keytag 21366
Sep  5 13:27:13 dnsmasq: reply org is DNSKEY keytag 19629
Sep  5 13:27:13 dnsmasq: reply org is DNSKEY keytag 21366
Sep  5 13:27:13 dnsmasq: reply org is DNSKEY keytag 9795
Sep  5 13:27:13 dnsmasq: reply org is DNSKEY keytag 12023
Sep  5 13:27:13 dnsmasq: reply ietf.org is DS keytag 45586
Sep  5 13:27:13 dnsmasq: reply ietf.org is DS keytag 45586
Sep  5 13:27:13 dnsmasq: reply ietf.org is DNSKEY keytag 45586
Sep  5 13:27:13 dnsmasq: reply ietf.org is DNSKEY keytag 40452
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] cloudflare-dnssec.net to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DS] cloudflare-dnssec.net to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DNSKEY] net to 81.3.21.188
Sep  5 13:27:13 dnsmasq: dnssec-query[DS] net to 81.3.21.188
Sep  5 13:27:13 dnsmasq: reply net is DS keytag 35886
Sep  5 13:27:13 dnsmasq: reply net is DNSKEY keytag 45464
Sep  5 13:27:13 dnsmasq: reply net is DNSKEY keytag 35886
Sep  5 13:27:13 dnsmasq: reply cloudflare-dnssec.net is DS keytag 537
Sep  5 13:27:13 dnsmasq: reply cloudflare-dnssec.net is BOGUS DNSKEY
Sep  5 13:27:13 dnsmasq: validation result is BOGUS
Sep  5 13:27:13 dnsmasq: reply www.ietf.org is <CNAME>
Sep  5 13:27:13 dnsmasq: reply www.ietf.org.cdn.cloudflare-dnssec.net is 104.20.0.85
Sep  5 13:27:13 dnsmasq: reply www.ietf.org.cdn.cloudflare-dnssec.net is 104.20.1.85

现在我不确定域名是否暂时配置错误或我的连接被篡改或我的 DNS 服务器是否配置错误，即使到目前为止其他所有域名都运行正常，包括“ietf.org”（没有 www）。

如果有人能帮助我追踪这个问题，我将不胜感激。

Answer 1

这是因为 CloudFlare（IETF 的 CDN 提供商）选择 ECDSAP256SHA256 作为其签名算法。Dnsmasq 从 2.69 版开始实施 ECDSA，但它一直存在问题，直到 2015 年 3 月发布的 2.73 版才修复。因此，您需要更新的 dnsmasq 或修补版本才能正确解析它。

来自 dnsmasq更改日志在 2.73 部分中：

Fix broken DNSSEC validation of ECDSA signatures.

来自 Cloudflare DS 记录集：

cloudflare.net。86400 IN DS 2371 13 2 90F710A107DA51ED78125D30A68704CF3C0308AFD01BFCD7057D4BD0 3B62C68B

13 是算法类型。DNSSEC 中允许的每种算法都有指定的编号。算法 13 是使用 SHA-256 的 P-256 曲线的 ECDSA。

最后dig +trace ds www.ietf.org包括通过 Cloudflare 的 CNAME 记录。

www.ietf.org.1800 IN CNAME www.ietf.org.cdn.cloudflare-dnssec.net。

Answer 2

我使用最新的 dnscrypt 2.0.8 和最新的 dnssec 2.79 时也遇到了这种情况；这是暂时的，只持续了 12 分钟。

因此它并不局限于早期版本。根据全面 DNSSEC 监控和分析工具案例（强调添加）：

B. 错误配置导致的虚假验证

在本节中，我们从配置错误的角度描述了验证失败的一些原因。无论如何，被视为虚假的 RRset 也会使任何依赖的 RRset 无效。例如，虚假的 DNSKEY RRset 意味着所有可能通过这些 DNSKEY 验证其 RRSIG 的 RRset 也是虚假的。

...

虚假：验证器无法在 RRset 和信任锚之间形成信任链，也无法安全地证明不存在这样的链。示例：覆盖 secure.com 中的 RRset 的过期 RRSIG 会导致虚假响应；同样，如果 broken.com 区域中存在 DS（其中不存在 DNSKEY），则会导致该区域中的任何 RRset 处于虚假状态

虽然安全验证是理想的，但不安全的结果也是可行的，并且相当于正常的、未经身份验证的名称解析。但是，虚假结果表明验证失败——要么是因为 DNS 数据被篡改，要么是因为配置错误。验证器将返回给递归（即代表另一个客户端）查询的响应视为虚假，该响应具有 SERVFAIL 错误状态并且不包含 DNS 数据，这表明一般名称解析失败。最终用户无法区分由数据篡改导致的 SERVFAIL 响应和由配置错误导致的 SERVFAIL 响应。但无论哪种情况，最终结果都是一样的：无法解析有问题的名称。本研究重点关注由错误配置导致的虚假验证。