有一个问题：

与 DNSSEC 相比，DNSCurve 更像是用于 DNS 服务器的 TLS，后者是签名记录。DNSCurve 使用点对点加密来保护通信，而 DNSSEC 使用预先计算的签名来确保所提供记录的准确性。

所以我们可以这样总结：
DNSSEC : Accurate Results
DNSCurve : Encrypted Traffic

从理论上讲，您可以使用流量加密来确保准确性，就像 TLS 对网站所做的那样。除了确保您的准确性的不是真正的加密之外，是通过 PKI 提供的身份验证。基本的 DNSCurve PKI 存在一系列关键问题。

这里的第一个问题是，使用 DNSCurve，涉及的每个 DNS 服务器都需要一个私钥，并且由于密钥签名被编码到解析器的地址中，因此在任播 DNS 服务器的情况下，每个服务器都需要相同的私钥。但即使他们使用不同的密钥，您仍然信任安装 DNS 服务器的本地安全性。如果服务器安装在敌对的地方，那么结果可能会受到影响。DNSSEC 并非如此。

ICANN 已声明，对于 DNS 根区域服务器，永远不会实施 DNSCurve。许多根服务器在不太受信任的位置运行，地方政府滥用的可能性将是巨大的。这正是 DNSSEC 被设计成在 DNS 服务器之外进行签名的原因。DNS 依赖于庞大的服务器网络，而这些网络可能并不值得单独信任，因此 DNSSEC 的设计使得信任仅基于它们所提供的信息，而不是运营商的诚实。

第二个问题是 DNSCurve 通过将公钥编码到解析器名称中来保护公钥。但 DNSSEC 不对解析器名称进行签名。这意味着 DNSSEC（在根区域中实施）不能用作 DNSCurve 的信任根，因为 DNSCurve 要求准确的一件事实际上正是 DNSSEC 无法确保准确性的事情。

所以本质上 DNSCurve 几乎是一个非首发。虽然它可用于保证您与单个 DNS 解析器通信的安全性，但目前无法以一种可以保证您检索到的任何结果的准确性的方式在全球范围内锚定您的信任。

除非重新设计 DNSCurve 以允许可信密钥分发，否则它必须保持客户端安全工具，而不是确保 DNS 记录真实性的工具。

由于 DNSCurve 相对较新，并且主要由 djb 单独开发，因此这些令人瞩目的问题可能只是他的疏忽，可能会在将来的某个日期修复。尽管考虑到伯恩斯坦博士在维护他的发明方面的往绩，我还是不会屏住呼吸。

主要原因是当 DNSCurve 出现时，主要根服务器已经采用了 DNSSEC。此外，它们没有解决相同的问题，它们在某些方面重叠，但在其他方面有所不同。它们可以很好地一起使用。

请注意，我们有一个问题DNSSec (Comcast) vs DNSCurve (OpenDNS)，它很好地详细说明了差异：

首先，DNSSEC 不会对您的查询进行签名。相反，DNSSEC 允许区域（例如域）由其所有者签名，并允许解析器（例如 Comcast 的 DNS 服务器）验证签名，从而确保它获得的区域数据是真实的。它可以保护解析器不接收不良数据，但不会阻止 MITM 或您与解析器之间的窥探。

另一方面，DNSCurve 对递归解析器和权威服务器之间的通信进行加密，并允许权威服务器对其数据进行签名以防伪造，但无法保护最终用户客户端免受不良递归解析器的侵害。OpenDNS 的 DNSCrypt 解决方案基于与 DNSCurve 相同的技术，但保护了 OpenDNS 等受信任的第 3 方递归解析器与终端客户端之间的最后一英里。

至于哪个更安全，也不是。它们都是安全的，但是安全性应用于不同的领域。无论哪种情况，您都在选择 DNS 安全的哪个方面更重要，而不是哪个安全工具更强大。