DNSSEC 是一个复杂的话题，而让事情更加混乱的是，按 IANA 定义，有几种标准的安全算法用于为 DNS 记录签名。Algorithm 13 是椭圆曲线数字签名算法 (ECDSA) 的一个变种。虽然目前只有不到 0.01% 的域在使用，但我们想说，ECDSA 帮助我们消除了 DNSSEC 广泛采用的最后两个障碍：区域枚举和 DDoS 放大。
阅读本文后，您将能够：
复制文章链接
DNSSEC 是一个复杂的话题，而让事情更加混乱的是，按 IANA 定义，有几种标准的安全算法用于为 DNS 记录签名。Algorithm 13 是椭圆曲线数字签名算法 (ECDSA) 的一个变种。虽然目前只有不到 0.01% 的域在使用，但我们想说，ECDSA 帮助我们消除了 DNSSEC 广泛采用的最后两个障碍：区域枚举和 DDoS 放大。
区域列举可通过实时签名来防止，而这只有采用 ECDSA 的快速签名生成才有计算效率。椭圆曲线产生的密钥和签名也比其 RSA 的对应结果要小得多，这意味着对 DNS 查询的响应更小。这大大降低了基于 DNS 的 DDoS 攻击的放大系数。
DNSSEC 通过 NSEC 和 NSEC3 记录引入了经过验证的的存在否认。然而，正如我们在 DNSSEC 的复杂性和考虑中所讨论，NSEC 和 NSEC3 都允许攻击者遍历区域。解决方案是一种聪明的技术，称为“DNSSEC 善意的谎言”（参见 RFC 4470 和 4471 描述），但它只能在 DNSSEC 记录被实时签名的情况下实施。
RSA 是 DNSSEC 中最普遍的签名算法，部分原因是它是该协议定义的唯一必要算法。不幸的是，用 RSA 进行实时签名的开销太高了。
ECDSA 的性能提升非常显著。生成 ECDSA 签名的计算开销为生成可比 RSA 签名的十分之一。这使得实时签名（和 DNSSEC 善意的谎言）变得可行，即使在大规模实施的情况下。
在我们的 DNSSEC 测试期间（签名域不到 1000 个），Cloudflare 每秒钟应答数万次 DNSSEC 查询。这意味着每天有超过 10 亿次查询，而且我们实时签署所有必须的 RRSIG 记录。采用速度 RSA 快 10 倍的签名算法，就我们的 DNSSEC 服务器负载而言，会产生巨大的差别。
最初开始研究 ECDSA 时，我们使用的 OpenSSL 实现使用 Go 语言。考虑到我们正在做的所有签名，优化签名生成是一个非常重要的优先事项。因此，我们用低级别的汇编重写了 ECDSA 的实现，现在它的速度是 Go 中的 20 倍以上。这些代码是开源的，并将进入 Go 1.7，以便整个加密社区都能够利用我们的优化。了解详情
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 解决了 DNSSEC 的主要问题，但它几乎没有得到全球 DNSSEC 社区利用。我们简单看了一下 ECDSA 在 DNS 根区域和 Alexa 排名前 100 万网站中的采用情况。
首先，我们检查了根 DNS 区域，看看顶级域名使用的是哪种 DNSSEC 算法。下表显示了根区域文件中的 DS 记录指定的安全算法：
curl -s http://www.internic.net/domain/root.zone | awk '$4 == "DS" { print $6}' | sort -n | uniq -c
我们对 Alexa 排名前 100 万网站进行了类似的分析，为全球互联网流量提供了一个适当的横截面。
| 算法 | 签名 DS 记录数量 |
|---|---|
| 1 (RSA/MD5) | 1 |
| 3 (DSA/SHA1) | 10 |
| 5 (RSA/SHA-1) | 3322 |
| 7 (RSASHA1-NSEC3-SHA1) | 5083 |
| 8 (RSA/SHA-256) | 7003 |
| 10 (RSA/SHA-512) | 201 |
| 13 (ECDSA Curve P-256 with SHA-256) | 23 |
最引人注目的发现是，在 100 万个网站中，只有 15,643 个网站以某种形式启用了 DNSSEC。在这 1.5% 中，只有 23 个区域是用 Algorithm 13 签名的。而且，这些 Algorithm 13 签名区域中有一半以上是在 Cloudflare 网络后。这意味着在 Cloudflare 以外的 Alexa 排名前 100 万区域中，只有不到 12 个区域使用 ECDSA。这支持了 Roland van Rijswijk-Deij 等人的研究结果，即 .com、.net 和 .org 中 99.99% 的签名域名都使用 RSA。
那么，为什么 Algorithm 13 的使用率如此之低，尤其是考虑到它解决了 DNSSEC 中如此重大的问题？RSA 是在 DNSSEC 协议的一开始就被引入的。而 ECDSA 是一种新的加密算法，解析器、注册服务机构和注册管理机构仍未跟进采用。
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 记录上传到注册管理机构。我们正在努力使这成为一个自动化过程，以便域名注册者甚至不需要上传 DS 记录，但仍需要注册服务商的干预。
好消息是，我们正朝着正确的方向发展。在过去的12个月里，DNSSEC 总体上有了相当大的增长。而且，在我们宣布 DNSSEC 公测和通用 DNSSEC 之间的三周内，Hover、OVH、Metaname、Internet.bs 和 .NZ 注册服务机构已经增加了对 Algorithm 13 的支持。
我们认为，DNSSEC 是现代 Web 的一项必要技术，ECDSA 使全球 DNSSEC 采用具有现实可能性。希望我们能继续看到大大小小的注册服务机构和注册管理机构支持 Algorithm 13。