有人可以通知，请对这两种方法的差异和优点/缺点给予冗长的答复吗？
我不是DNS专家，不是程序员。 我对DNS有一个体面的基本理解，并且有足够的知识来理解kaminsky错误如何工作。 据我所知，DNSCurve具有更强大的encryptionfunction，安装简单，而且是一个更好的解决scheme。
DNSSEC是不必要的复杂，使用可破解的encryption，但它提供了端到端的安全性，DNSCurve没有。 然而，我所阅读的许多文章似乎都表明，端到端的安全性没有什么用处，也没有什么区别。
那么哪个是真的？ 哪一个更好的解决scheme，或每个的缺点/优点是什么？
编辑：
我将不胜感激，如果有人能解释什么是通过encryption消息内容，当目标是身份validation，而不是保密。
密钥是1024位RSA密钥的certificate在这里 。
DNSCurve为DNS数据包提供了实际的encryption，尽pipe只是在逐跳的基础上，特别是在recursion服务器和权威服务器之间的跳跃。
在该path上使用时，可以提供区域数据的身份validation。 然而，任何进一步下游的客户端都不能从这种authentication中受益，因为安全性只是“逐跳的”。 坐在解决途径中间的恶意parsing器仍然可以提供虚假的数据。
另一方面，DNSSEC提供了一个端到端可validation的encryption签名，certificate收到的数据与授权服务器上的数据相同。 DNSSEC使用encryption技术，但实际上并未encryption任何DNSstream量。
DNSCurve使用椭圆曲线encryptionalgorithm允许使用比RSA更小的密钥来实现相同级别的encryption强度。 不过，有人build议在DNSSEC所设想的列表中包含类似的algorithm。
DNSSEC由IETF（RFC 4034和RFC 4035，由RFC 5155更新）标准化，并在几个非常stream行的名称服务器实现中实现，包括BIND（当然）和NSD / Unbound。 PowerDNS将很快有DNSSEC支持。
DNSSEC无疑是复杂的，但正在努力简化这一点（参见http://opendnssec.org/ ），并且部署正在不断增加。 各种顶级域名（.se，.br，.org，.gov等）已经与DNSSEC签订了协议，并宣布根域将在今年年底之前通过DNSSEC签署。
DNSCurve非常有趣，但是由于它独立的开发方式，很less有机会看到任何重要的部署。 恕我直言，它没有机会被部署在根服务器上。
顺便说一下，使用“可破解的encryption技术”对DNSSEC的断言似乎是完全没有根据的。 你说什么基础？
区域签名密钥通常（但不一定）是1024位长。 这些密钥通常是每个月左右滚动一次，目前最好的估计是，至less需要几年的时间来蛮力 1024位密钥。
在这个时候，针对1024位RSA的暴力攻击需要在几百万个计算核心上运行大约两年，每个处理器或主板的内存要有数十GB的内存
这不是你典型的僵尸networking。 来自同一篇论文：
接下来考虑特殊用途的硬件，最乐观的方法表明，1024位RSA模数的筛选可以在一年内完成约10,000,000美元，再加上一次性开发成本约20,000,000美元，并且具有可比的时间和成本为matrix。 在我们看来，这种devise所遇到的（普遍的）怀疑主义就在这一点上。 这样的数据不应该被解释为上限，即“小心，1024比特的RSA可以在两年内以大约2000万美元（假设自由开发）被打破”，但是作为下限，即“没有理由担心太多了：即使在非常有利的攻击条件下，考虑到1024位RSA模数仍然需要巨大的资源。“因此，这些估计不应该被认为是有威胁性的，而是作为自信心。
或从一个一年的PCPro文章 ：
从这个angular度来看，要破解一个1024位的RSA密钥卡巴斯基估计需要1500万台计算机运行一年才能成功
坦率地说，没有人会花费这么多的精力来破解一个域名的ZSK！
另外，真正的安全性在密钥签名密钥中，通常至less2048位，通常更长（4096位）。 破解RSA密钥花费的时间量与密钥长度成指数关系，而不是线性增长。
对LWN声明的评论
DNSCurve确保pipe道，而不是消息。 它不能用来防止恶意caching，也不是DNSSEC的function。
并链接到法语的讨论 。
理解“信任”而不是“encryption”是保证安全的关键。 你可以与使用“encryption”的人进行“安全的”对话，但是如果另一端的人不是你认为的那个人，那么你有什么好处呢？
DNSSec和DNSCurve之间的主要差异在于，DNSSec签署了一切，从根本到每个运营商DNS服务器提供的主机logging都有一个明确的信任链。
DNSCurve根本不会签署任何信任链。 DNSCurve的重点缩小到防止DNS响应的被动或盲目平衡。
归结为实用性… DNSSec面临着巨大的运营挑战 – 您如何实际创build一个与地球一样大小的信任锚？ 当数百万个域名正在签署使用什么机制来灌输信任时，伪造任何签名所需的密钥资料不会落入错误的手中，或者被不恰当地使用？ 从操作的angular度来看，大规模的信任是非常困难的。
DNSCurve甚至不尝试。
现在回答了这个基本问题，我认为要解决的问题实际上是两种技术中的哪一种更合适。
互联网本质上是一个胡说八道的话题，因为这是一个突出的讨论和启发。 在我看来，一个完全信任的互联网并不是一个合理的或可以获得的目标，如果这样做的话，自由和言语和行为上的负面影响就可能会产生负面影响。
在我看来，所有需要的是一个DNS解决scheme， 至less和底层的交通工具一样值得信赖。 它需要实际上防止盲目注入虚假消息或钝化嗅探请求并伪造UDP响应的攻击者盗用DNSlogging。 除此之外，不需要保证安全性。 这样，互联网继续路由数据包，并以可靠但不一定安全的方式提供DNS服务。
我认为DNSSec及其全球信任主播是一个愚蠢的差事，几乎完全集中在解决一个不存在的问题上。 （可通过互联网使用的所有端端encryption系统已经有自己的validation身份的方法）
DNSSec速度缓慢，价格昂贵，并且将显着延迟DNS的明确和现在的问题，如迁移到IPv6应该昨天解决。
DNSCurve所做的就是保护networking，使得命名服务至less与networking上数据包的底层传输一样可靠，但不是如此。 在我看来，它解决了现实世界中实际面临的确切问题。 DNSCurve防止被动MITM，但它实际上并没有防止主动MITM没有ssh风格的“信心”签名caching。
扮演魔鬼主张大规模部署DNSSec可能会产生积极影响。 PKI信息结构可以replaceSSL安全服务器CA，并为IPSec和其他encryption对话之间的对等提供一些信任绑定。
说实话？ 两者都不够好。 DNSSEC在自己的重量下崩溃：过于复杂，充满了漏洞，并可能永远不能正常工作。 DNSCurve擅长它，但不够远。 打补丁到DNS服务器比较容易，但是由于它被写入和被提升的方式，可能永远不会被广泛使用。
我宁愿在自己的（recursion）DNS服务器上部署DNSCurve，而不是在DNSSEC上部署DNSCurve，但仅仅是因为DNSCurve对于它可以做什么和不能做什么更明确，并且不会像DNSSEC那样提供一个错误的安全感 – 聪明的人认为DNSSEC已经足够好了，事实并非如此 。
我的直觉是，DNS安全战争还有更多，我们可能会看到第三个选项出现。 希望它会build立在DNSCurve上，因为我认为DNSCurve是非常好的devise，以确保pipe道的向后兼容的方式。
我得出的结论是，DNSCurve是一个更好的select。
因为：
DNSSEC使用1024位RSA密钥进行签名，2003年被大型networking僵尸networking认为是不可破解的。 今天的情况依然如此。
为了正确实施，许多代码必须被重写。
根服务器不会签署完整的数据库，不提供全面的保护。
域名到期后30天内的重播攻击是可能的。
为了实现安全，有必要公开所有的域名。
DNSCurve没有这些问题，并且允许以DNSSEC不支持的方式进行身份validation，可用性和机密性（如不需要公开名称）。 此外，它不需要修改代码，只需要额外的软件。
它还可以防止DNSSEC所没有的伪造数据包，并防止由于使用随机数而导致的重放攻击。 DNSCurve可能会受到DNSSec所没有的MITM攻击，但是我的理解是，如果DNSCurve一直执行到根目录，情况就不会如此。