我管理着几个有 10-30 台机器的网络，并且我运行一个bind名称服务器来为我的客户提供 DNS 解析（而不是转发到 Comcast 或 Google——我并不想以这种方式宣传我的用户的互联网活动）。我的名称服务器对一些本地事物具有权威性，并且它对其他所有事物都进行完全的从根解析。这在大多数情况下都可以正常工作，但即使在全新重启后，bind 也会很快开始记录got insecure response; parent indicates it should be secure错误。我相信这些发生在解析一个全新的名称时，当我的副本bind开始从.com或.org或其他任何地方解析时。
我还没有深入研究当前的 DNS 协议，或者开始tcpdump嗅探；我希望有人能说“你的时间基准关闭了”或类似的话，这样我就不用深入研究 DNS 了。（我正在运行 NTP，我相信我的系统时间足够接近，所以这不是问题。）
是否有一个常见问题会影响运行此类递归名称服务器的小型网站？或者是否有一个可以并行运行的好工具bind可以帮助我找出bind抱怨的原因？请注意，即使某些名称无法解析，我相信其他名称也可以。例如，我可能遇到foo.bar.com.报告为的问题validating .com/SOA: got insecure response，但gibble.gobble.com解析正常。（我的bind是在自建的 OpenWRT 路由器上运行，因此构建新版本的工具有些不方便，但如果我必须重新构建并重新安装新系统，我可以这样做。）
答案1
该消息意味着您正在查看的域已启用 DNSSEC（即父域具有指向子域的 DS 记录，这意味着子域中的记录应该签名），但响应未附带 DNSSEC 签名（域配置错误）或您的名称服务器无法解释 DNSSEC 签名（可能是使用您的 DNS 服务器无法处理的加密算法生成的签名）。如果没有无法解析的域的具体示例，我们就不知道是哪个域。
您可以关闭 DNSSEC 验证，这肯定会阻止错误（和名称解析）失败，但从安全角度来看，这不是一个好主意。如果您从不锁门，那么您也永远不会发现自己被锁在门外 ;-) 如果错误是由域上的 DNSSEC 配置错误引起的，那么您显然无能为力（我认为 BIND 无法提供有选择地忽略每个域的 DNSSEC 错误的方法，即使您想这样做）。如果问题是您的 BIND 版本不支持加密算法，那么更新 BIND 可能是唯一的解决方法。