BIND9：DNS 解析有时（！）需要很长时间或根本不起作用

Question

经过更多研究，问题似乎如下：

初始设置包含两个转发器DNSSEC- 支持（GoogleDNS 8.8.8.8、8.8.4.4）和一些不支持（OpenDNS 208.67.222.222、208.67.220.220）。我让 BIND9 在完全启用 DNSSEC 的情况下运行，按照以下配置：

dnssec-enable      yes;
dnssec-validation  yes;
dnssec-lookaside   auto;

A）每当请求（A？）被转发到谷歌DNS服务器，my_server 收到回复 (A)，发送 DNSSEC 查询（DS？）并得到正确答案。决议完成，签名确认，一切顺利，案件结案（见上文，正常情况）。

b)每当请求（A？）被转发到开放DNS服务器，my_server 收到回复 (A)，发送了 DNSSEC 查询 (DS？)，OpenDNS 未能正确答复，因为它不支持 DNSSEC。因此 BIND9 在中抛出了一个错误syslog，指出它got insecure response并试图在其他地方获取它的 DNSSEC 验证（见上文，有问题的案例）。

我仍然不完全明白当时发生了什么，但显然那就是打嗝开始的时候。现在我不知道 GoogleDNS 服务器是否不喜欢在没有先提供相应的 A? 查询的情况下给出 DS? 答案。但在这两个有问题的情况下（sueddeutsche.net、dasoertliche.de），条目似乎也没有正确签名，因此 DNSSEC 无法产生正确的验证。因此，DNSSEC 后备验证 (DLV) 启动了 ( Type32769?)，但一切再次陷入困境。不知道为什么。

c) 解决方案：毕竟，我已经完成了以下操作，并且还没有遇到任何问题（所以看起来问题已经解决了）：

首先，我将转发器切换为仅

forwarders         { 8.8.8.8; 8.8.4.4; };

这样就不再混淆 DNSSEC 支持了。其次，我注释掉了

//dnssec-lookaside   auto;

因为在挖掘大量 tcpdump 后，似乎每当解析速度缓慢时，延迟要么是由 GoogleDNS 需要一些时间来返回答案（很少发生）造成的，要么是在 DLV 期间经常发生的。由于 DLV 目前正被逐步淘汰，2017 年不再提供条目

https://www.isc.org/blogs/dlv/

我认为从安全角度来看这是可以接受的。

现在，另一种解决方案是放弃 GoogleDNS 服务器并仅使用 OpenDNS 作为转发器。但随后我必须注释掉上面提到的所有 dnssec 条目，从而完全禁用 DNSSEC，因为 OpenDNS 不支持它。这将使我的 dns 查询容易受到攻击，这需要添加一个替代的安全层，例如dnscrypt（如 Rui F Ribeiro 所提到的）。虽然这看起来是一个有价值的项目（因为它完全加密了 dns 流量，因此不仅保持其不变，而且攻击者无法读取），但它有点超出了我当前的时间预算。

如果上述解释有道理，有 DNS 专家愿意插话吗？

Answer 1