ECDSA：DNSSEC 的缺失部分

Cloudflare 是世界上最大的 托管 DNS 提供商。我们绝不希望我们的 DNSSEC 服务器成为分布式拒绝服务（DDoS）攻击的放大手段。每次您从 DNSSEC 服务器请求一个记录时，它也会返回与该记录相关的签名，以及用于验证该签名的公钥。这可能包含大量信息。

为防止可能的攻击者滥用我们的 DNS 基础设施，使 DNSSEC 查询的响应尽可能小是一个重要的要求。ECDSA 密钥和签名较小，对此有很大帮助。

用 ECDSA 实现 128 位的安全需要一个 256 位的密钥，而可比的 RSA 密钥将是 3072 位。仅仅从密钥来看看，就有 12 倍的放大系数。有关加密密钥大小不同的更多信息，请阅读这篇博客文章。

但是，大多数 RSA 密钥不是 3072 位，所以 12 倍的放大系数可能不是接近现实的数字。让我们来看看 DDoS 放大最糟糕的现实情况，即否定响应（NSEC 记录）。对于位于 Cloudflare 背后的域（使用 ECDSA 签名和 DNSSEC 善意的谎言），典型的 DNSSEC 响应是 377 字节。相比之下，对未使用 ECDSA 或 DNSSEC 善意的谎言的域而言，响应为 1075 个字节。

考虑到其他所有大规模的 DNSSEC 实施都依赖于 RSA 签名的情况，攻击者利用我们的 DNSSEC 基础设施作为 DDoS 手段就缺乏吸引力了。

ECDSA 并非没有需要取舍之处。根据Roland van Rijswijk-Deij 等人研究，只有 80% 的解析器支持 ECDSA 验证。这个数字还在增长，但这意味着，如果我们现在把整个 DNSSEC 互联网切换到 ECDSA，每天将有数百万互联网用户遭遇 DNSSEC 验证失败，并退回到以未验证的 DNS 记录应答。

此外，虽然 ECDSA 签名创建比 RSA 快，但签名验证实际上要慢得多。Roland van Rijswijk-Deij 等人的研究表明，即使有了我们贡献给 OpenSSL 的 ECDSA 优化，ECDSA 仍然比 1024 位的 RSA（这是最常用于区域签名密钥的算法）慢 6.6 倍。这是一个严重的问题，因为过载的 DNS 解析器有可能使整个互联网变慢。

所有这些关于 Algorithm 13 的讨论有一个非常重要的注意事项：只有 1.5% 的 Web 资产具备支持 DNSSEC 的能力。并非所有的注册服务机构支持 DNSSEC，而且增加支持也不是易事。注册服务机构需要允许用户上传 DS 记录，然后需要将其上传到注册管理机构。我们正在努力使这成为一个 自动化过程，以便域名注册者甚至不需要上传 DS 记录，但仍需要注册服务机构的干预。

好消息是，我们正朝着正确的方向发展。在过去的12个月里，DNSSEC 总体上有了相当大的增长。而且，在我们宣布 DNSSEC 公测和通用 DNSSEC 之间的三周内，Hover、OVH、Metaname、Internet.bs 和 .NZ 注册服务机构已经增加了对 Algorithm 13 的支持。

我们认为，DNSSEC 是现代 Web 的一项必要技术，ECDSA 使全球 DNSSEC 采用具有现实可能性。希望我们能继续看到大大小小的注册服务机构和注册管理机构支持 Algorithm 13。