有人可以告知，请就这两种方法的差异和优点/缺点给出一个冗长的答复？
我不是 DNS 专家，也不是程序员。我对 DNS 有相当基本的了解，并且有足够的知识来理解像 kaminsky 错误这样的事情是如何工作的。据我了解，DNSCurve 具有更强的加密功能，设置起来更简单，并且是一个更好的解决方案。
DNSSEC 不必要地复杂并使用易破解的加密，但它提供了端到端的安全性，而 DNSCurve 却没有。但是，我读过的许多文章似乎都表明端到端安全性几乎没有用或没有任何区别。
那么哪个是真的？哪个是更好的解决方案，或者每个的缺点/优点是什么？
编辑：
当目标是身份验证而不是保密时，如果有人可以解释加密消息内容所获得的结果，我将不胜感激。
密钥是 1024 位 RSA 密钥的证明在这里。
DNSCurve 为 DNS 数据包提供真正的加密，尽管只是在逐跳的基础上，特别是在递归服务器和权威服务器之间的跃点上。
当在该路径上使用时，它可以提供区域数据的身份验证。然而，任何下游的客户端都无法从这种身份验证中受益，因为安全性只是“逐跳”。位于解析路径中间的恶意解析器仍然可以提供虚假数据。
另一方面，DNSSEC 提供端到端的可验证加密签名，证明接收到的数据与权威服务器上的数据相同。DNSSEC 使用加密技术，但实际上并不加密任何 DNS 流量。
DNSCurve 使用椭圆曲线加密算法允许使用比 RSA 小得多的密钥来实现相同级别的加密强度。然而，有人提议在 DNSSEC 假定的列表中包含类似的算法。
DNSSEC 由 IETF（RFC 4034 和 RFC 4035，由 RFC 5155 更新）标准化，并在几个非常流行的名称服务器实现中实现，包括 BIND（当然）和 NSD/Unbound。PowerDNS 很快就会支持 DNSSEC。
DNSSEC 诚然复杂，但正在努力简化这一点（参见例如http://opendnssec.org/），并且部署一直在增加。各种 TLD（.se、.br、.org、.gov 等）已与 DNSSEC 签署，并且已宣布根区域将在年底前签署 DNSSEC。
DNSCurve 非常有趣，但由于它的开发方式独立，它几乎没有机会看到任何重大部署。恕我直言，它被部署在根服务器上的机会为零。
顺便说一句，您关于使用“可破解加密”的 DNSSEC 的断言似乎完全没有根据。你这么说的依据是什么？
区域签名密钥通常（但不一定）为 1024 位长。这些密钥通常每月左右滚动一次，目前最好的估计是至少需要几年时间才能强制使用 1024 位密钥。
这不完全是典型的僵尸网络。来自同一篇论文：
或者来自一年前的PCPro 文章：
坦率地说，没有人会花这么多精力来破解一个域的 ZSK！
此外，真正的安全性在于密钥签名密钥，这些密钥通常至少为 2048 位，并且通常更长（4096 位）。破解 RSA 密钥所需的时间随密钥长度呈指数增长，而不是线性增长。
对 LWN索赔的评论
以及法语讨论的链接。
理解“信任”而不是“加密”是安全的关键。您可以使用“加密”与某人进行“安全”对话，但如果对方不是您认为的那个人，这对您有什么好处？
DNSSec 和 DNSCurve 之间的主要区别在于 DNSSec 对所有内容进行签名，从根目录一直到每个运营商 DNS 服务器提供的主机记录都有一条清晰的信任链。
DNSCurve 不签署任何内容，根本没有信任链。DNSCurve 的重点被缩小到防止 DNS 响应的被动或盲目平衡。
归结为实用性...... DNSSec 存在巨大的运营挑战 - 您如何实际创建一个地球大小的信任锚？当数以百万计的域被签名时，使用什么机制来灌输信心，即伪造任何签名所必需的密钥材料不会落入坏人之手或没有被不当使用？从运营的角度来看，大规模的信任很难实现和维持。
DNSCurve 甚至没有尝试。
现在已经回答了基本问题，我认为实际上要解决的问题是什么以及这两种技术中的哪一种更适合。
互联网本质上既是胡说八道的渠道，也是重要的讨论和启蒙的渠道。在我看来，一个完全值得信赖的互联网不是一个合理或可实现的目标，如果它变成这样，可能会对自由和不规范的言论和行为产生负面影响。
在我看来，所需要的只是一个至少与底层传输一样值得信赖的 DNS 解决方案。它需要切实防止盲目注入虚假消息或被动嗅探请求并伪造 UDP 响应的攻击者对 DNS 记录的毒害。它不需要保证超出此范围的安全性。这样，互联网继续以可靠但不一定安全的方式路由数据包并提供 DNS 服务。
在我看来，DNSSec 及其全球信任锚是一项愚蠢的差事，几乎完全专注于解决不存在的问题。（所有可以在互联网上使用的端端加密系统都已经有了自己的身份验证方法）
DNSSec 速度慢、成本高，并且会显着延迟 DNS 的明显和当前问题，例如迁移到 IPv6 应该在昨天得到解决。
DNSCurve 所做的是保护网络，以便命名服务至少与网络上数据包的底层传输一样可靠，但并非如此。在我看来，它解决了现实世界中实际面临的确切问题。DNSCurve 可以防止被动 MITM，但它实际上并不能防止没有 ssh 风格的“信仰之跃”签名缓存的主动 MITM。
扮演魔鬼提倡大规模部署 DNSSec 可能会产生积极影响。PKI 基础设施可以替代 SSL 安全服务器 CA，并为 IPSec 和对等点之间的其他加密对话提供一些信任绑定。
诚实地？一个都不够好。DNSSEC 因自身的重量而崩溃：它过于复杂，漏洞百出，而且可能永远无法正常工作。DNSCurve 擅长它的功能，但还远远不够。打补丁到 DNS 服务器更容易，但由于它的编写和推广方式，可能永远不会被广泛使用。
我宁愿在我自己的（递归）DNS 服务器上部署 DNSCurve 而不是 DNSSEC，但这只是因为 DNSCurve 更明确地说明了它可以做什么和不能做什么，并且不会像 DNSSEC 那样提供错误的安全感——很多聪明的人认为 DNSSEC 已经足够好了，但事实并非如此。
我的预感是，DNS 安全战争还有更多尚未到来，我们可能会看到第三种选择出现。希望它将建立在 DNSCurve 上，因为我认为 DNSCurve 非常适合以向后兼容的方式保护管道。
我得出了一个结论，DNSCurve 是一个更好的选择。
因为：
DNSSEC 使用 1024 位 RSA 密钥进行签名，这在 2003 年已经被大型网络、僵尸网络认为是牢不可破的。今天的情况仍然如此。
要正确实现，必须重写许多代码。
根服务器不会签署完整的数据库，不提供全面保护。
域过期后最多 30 天的重播攻击是可能的。
为了实现安全性，有必要公开所有域名。
DNSCurve 没有这些问题，并且允许以 DNSSEC 没有的方式进行身份验证、可用性和机密性（如不必公开名称）。此外，它不需要修改代码，只需要额外的软件。
由于使用了随机数，它还具有针对伪造数据包的保护，而 DNSSEC 没有，以及针对重放攻击的保护。DNSCurve 可能会受到 DNSSec 没有的 MITM 攻击，但据我了解，如果 DNSCurve 一直实施到根目录，情况就不会如此。