我以前在我的内部网络上使用 OpenDNS。我今天发现 Comcast 已切换到 DNSSec：Comcast DNSSec。
我对 DNSSec 及其好处进行了一些研究。我了解 DNSSec 的基础知识。几乎 DNSSec 对您的 DNS 请求进行签名，因此您的 DNS 查询不会发生中间人情况。是否有很多恶意软件使用 DNS 中间人攻击？
所以后来我发现 OpenDNS 并不认为 DNSSec 是理想的解决方案：OpenDNS 关于 DNSSec 的意见。他们使用了一种我以前从未听说过的东西，叫做 DNSCurve。听起来与 DNSSec 非常相似。使用 Comcast 的解决方案，如果您使用他们的 DNS 服务器，您似乎会自动受到保护。不确定这是否适用于 OpenDNS。他们还有一个我很想使用的很酷的工具：DNSCrypt，它可以加密你的 DNS 请求。不幸的是，现在它只适用于 MACS。
所以总体问题是：我应该进行切换，还是 OpenDNS 的技术与 Comcast 上的 DNSSec 一样安全？
DNSSEC 和 DNSCurve 解决了 DNS 安全性的完全不同方面。
首先，DNSSEC 不会对您的查询进行签名。相反，DNSSEC 允许区域（例如域）由其所有者签名，并允许解析器（例如 Comcast 的 DNS 服务器）验证签名，从而确保它获得的区域数据是真实的。它可以保护解析器不接收不良数据，但不会阻止 MITM 或您与解析器之间的窥探。
另一方面，DNSCurve 对递归解析器和权威服务器之间的通信进行加密，并允许权威服务器对其数据进行签名以防伪造，但无法保护最终用户客户端免受不良递归解析器的侵害。OpenDNS 的 DNSCrypt 解决方案基于与 DNSCurve 相同的技术，但保护了 OpenDNS 等受信任的第 3 方递归解析器与终端客户端之间的最后一英里。
至于哪个更安全，也不是。它们都是安全的，但是安全性应用于不同的领域。无论哪种情况，您都在选择 DNS 安全的哪个方面更重要，而不是哪个安全工具更强大。
至于你应该做什么，这只有你可以决定，但请考虑以下几点：
您可以使用 Comcast 的 DNSSEC 解析器，并希望没有人窥探和 MITMs 您的机器和 Comcast 的解析器之间的连接。
您可以使用 OpenDNS 的解析器，使用 DNSCurve 连接到它们，并希望没有人将不良数据提供给这些解析器，因为它们不使用 DNSSEC。（公平地说，OpenDNS 在防止此类攻击方面有着非常好的记录。）
您可以使用免费提供的开源软件（例如 BIND、PowerDNS 或 Unbound）运行自己的解析器；在所述解析器上启用 DNSSEC；并将查询保留在本地网络上——或者更好的是，在每台机器上运行解析器。（恕我直言，这是最好的选择，因为它解决了其他两个选项的弱点）
DNSSEC 和 DNSCurve 本质上是做同样的事情。它们允许客户端验证 DNS 响应中的记录是否与区域所有者最初配置的相同。它们不是防弹的。父区域、注册商和注册管理机构仍然可以对他们直接或间接授权的区域做任何他们想做的事情。但总比没有好。
为此，显然必须签署区域。
使用 DNSCurve 签名的区域几乎不存在。实际上，它添加加密的事实完全没有用。给定签名区域的数量，数据包大小足以猜测查询是什么。
DNSSEC 正在获得一些牵引力，但其部署仍然相当缓慢。尽管如此，它仍然比 DNSCurve 部署得更多，openssh 和邮件服务器等流行工具可以利用它。
最安全的情况是验证由客户端自己完成。或者至少，如果您信任您的本地网络，在路由器上。现在 dnsmasq 支持 DNSSEC 验证，路由器固件也开始支持它。
现在，通过使用第 3 方解析器而不在您自己的网络上进行任何验证，您：
如果您是 Comcast 客户，DNS 解析器离您的路由器越近越好，而且您的连接已经完全依赖于 Comcast。如果您正在使用另一个第 3 方解析器，则您的路由器和该解析器之间的每一跳都可能被用来劫持响应。
因此，最好的选择仍然是使用本地 DNSSEC 验证解析器，例如 Unbound。
恶意软件不关心 DNSSEC 或 DNSCurve。一旦您的计算机被感染，大多数恶意软件可以直接将它们想要的任何内容注入您的浏览器，并在需要时更改您的 DNS 设置。
隐私是一个完全不同的主题，刚刚开始研究（请参阅DNS 隐私注意事项RFC）。
DNSSEC 仅尝试提供安全性，甚至没有任何提供任何隐私的尝试。
DNSCurve 提供安全性和隐私性。
对于递归 DNS 解析器（例如，您的问题中的 Comcast 和 OpenDNS），问题归结为这些技术中的至少一项是否由进行解析的域名的权威名称服务器部署，以及由解析所需的整个递归路径。这一点可确保 Comcast/OpenDNS 服务器本身可以从 Internet 的其他地方获得合法的解析。
但是，在他们的服务器可以代表您执行任何解决方案之前，您必须向他们发送您的请求。
如果您自己不使用任何精通 DNSSEC 或 DNSCurve 的软件，那么所有的赌注都没有了。
使用 DNSCurve 和 OpenDNS 的 DNSCrypt 客户端，您的所有查询都通过 DNSCurve 加密，只有 OpenDNS 可以看到实际内容，并提供有效的回复。
使用 DNSSEC，您可能还必须local_unbound在 FreeBSD 中使用类似 a 的东西。我还不完全确定它是如何工作的——它几周前才被导入，而且文档有些缺乏，但我认为它支持将流量转发到其他递归服务器，比如 Comcast 的服务器（带有forward-addr关键字），其中据说它还可以确保 DNSSEC 验证正在发生。
因此，您的问题不够具体，无法了解您的目标；但是，您使用 OpenDNS 似乎是有原因的，并且简单地将您的名称服务器改回 Comcast 不会在安全性方面提供任何好处。
但是，如果您已经在使用 OpenDNS，那么您当然应该考虑使用他们的 DNSCrypt 客户端。
我在我的电脑上安装了包含 Bind 的 Dnssec Trigger。您的机器上有一个本地密钥。我想找到一个包含这两种 DNS 协议的服务，因为它们不是专有的。
从他们的网站。
Dnssec 触发器使终端主机（笔记本电脑或台式计算机）能够对 DNS 流量使用 DNSSEC 保护。DNS 将计算机的名称转换为用于联系它们的 IP 地址。
它探测支持 DNSSEC 的服务器并指示 localhost 上的验证器使用它。如果失败，用户可以选择不安全。
这意味着浏览器可以（通常）获得支持 DNSSEC 的结果。它可能会使用 ADflag 信任来自 127.0.0.1 的结果。或者它可以自己进行 DNSSEC 验证。这可以启用 DANE (IETF wg)。
dnssec-trigger 的最后手段之一是将 SSL 端口 443 用于 DNSSEC。如果失败，DANE（https，也是 SSL 端口 443）不太可能工作。因此，从逻辑上讲，当 DANE 必须拥有该服务时，该服务很可能会提供 DNSSEC。