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)。
如果有人能帮助我追踪这个问题,我将不胜感激。
答案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。
答案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 响应。但无论哪种情况,最终结果都是一样的:无法解析有问题的名称。本研究重点关注由错误配置导致的虚假验证。