主页 / server / 问题 / 720293
Accepted
comfreak
Asked: 2015-09-06 03:52:58 +0800 CST

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

  • 772

我正在使用名为dnsmasq(version 2.72-3+deb8u1) 的 DNSSEC 验证 DNS-Resolver 运行本地 Debian 8.1 安装。

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

今天在浏览时，我想访问IETF相当有名的站点，但我不能，因为无法解析域。我检查了命令行来验证这一点，我确实得到了一个SERVFAIL. 我检查了谷歌 DNS 服务器（8.8.8.8），SERVFAIL只得到了 IP 地址。

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

这里是 my 的相应行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）。

如果有人可以帮助我追踪问题，我将不胜感激。

dnsmasq

2 个回答

  1. Best Answer

    这是由于 CloudFlare（IETF 的 CDN 提供商）选择 ECDSAP256SHA256 作为他们的签名算法。Dnsmasq 从 2.69 开始就实施了 ECDSA，但是直到 2015 年 3 月发布的 2.73 才被破坏并且没有修复。因此，您需要更新的 dnsmasq 或修补版本来正确解决它。

    从2.73 部分的 dnsmasq更改日志：

    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。

    • 5

  2. 使用最新的 dnscrypt 2.0.8 和最新的 dnssec 2.79 发生在我身上；这是暂时的，只持续了 12 分钟。

    所以它不限于早期版本。根据综合 DNSSEC 监控和分析工具案例中的“DNS 陷阱”部分（强调添加）：

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

    在本节中，我们将从配置错误的角度描述验证失败的一些原因。在任何情况下，被认为是伪造的 RRset 也会使任何依赖的 RRset 无效。例如，伪造的 DNSKEY RRset 意味着其 RRSIG 可能被这些 DNSKEY 验证的所有 RRset 也是伪造的。

    ...

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

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

    • 2

相关问题