#main-nav-header { display:none; }

DNSSEC 如何运作

域名系统（DNS）就如同互联网的电话簿：它告诉计算机向哪里发送信息，从哪里检索信息。可惜的是，它也接受互联网提供给它的任何地址，而不会进行任何询问。

电子邮件服务器使用 DNS 路由邮件，这意味着它们容易受到 DNS 基础设施的安全性问题影响。2014 年 9 月，CMU 的研究人员发现，本应通过 Yahoo!、Hotmail 和 Gmail 服务器发送的电子邮件变成通过流氓邮件服务器发送。攻击者利用了域名系统（DNS）中一个已存在数十年之久的漏洞，即接受应答前不会检查凭据。

这个问题的解决方案是一种名为 DNSSEC 的协议。通过提供身份验证，这种协议在 DNS 之上增加了一个信任层。在某个 DNS 解析器查找 blog.cloudflare.com 时，.com 域名服务器帮助解析器验证针对 cloudflare 返回的记录，而 cloudflare 帮助验证针对 blog 返回的记录。根 DNS 名称服务器帮助验证 .com，而根服务器发布的信息将通过彻底的安全程序（包括“根签名仪式”）进行审核。

委派签名者记录

DNSSEC 引入了委派签名者（DS）记录，以允许将信任从父区域转移到子区域。区域操作员对包含公共 KSK 的 DNSKEY 记录进行哈希处理，并将其提供给父区域以作为 DS 记录发布。

每次将解析器引用到子区域时，父区域也会提供 DS 记录。此 DS 记录是解析器获知子区域启用 DNSSEC 的方式。为了检查子区域的公共 KSK 的有效性，解析器对其进行哈希处理并将其与父区域的 DS 记录进行比较。如果两者匹配，则解析器可以假定公共 KSK 未被篡改，这意味着它可以信任子区域中的所有记录。这就是在 DNSSEC 中建立信任链的方式。

请注意，KSK 的任何变更都需要更改父区域的 DS 记录。更改 DS 记录是一个多步骤的过程，如果执行不正确，最终可能会破坏该区域。首先，父级需要添加新的 DS 记录，然后需要等到原始 DS 记录的 TTL 过期后将其删除。这就是为什么换掉区域签名密钥比密钥签名密钥要容易得多。

明确否认存在

如果您向 DNS 询问不存在的域的 IP 地址，它将返回一个空答案 - 无法明确答复“抱歉，您请求的区域不存在”。如果您想对响应进行身份验证，这就是一个问题，因为没有可签名的消息。DNSSEC 通过添加 NSEC 和 NSEC3 记录类型来解决此问题。它们都允许对否认存在的答复进行身份验证。

NSEC 会返回“下一个安全”的记录。例如，假设有一个为 api、blog 和 www 定义 AAAA 记录的名称服务器。如果您请求 store 的记录，它将返回一个包含 www 的 NSEC 记录，表示当记录按字母顺序排序时，strore 和 www 之间没有 AAAA 记录。这明确地告诉您 store 不存在。并且，由于 NSEC 记录经过签名，您可以像验证任何 RRset 一样验证其相应的 RRSIG。

但是，使用这种解决方案，人们无需知道他们要寻找的记录，就可以浏览区域并收集每条记录。如果区域管理员希望该区域的内容为隐私内容，则这可能造成潜在的安全威胁。您可以在 DNSSEC：复杂性和注意事项了解有关此问题的更多信息，并在 DNSSEC Done Right 了解 Cloudflare 的独特解决方案。

信任链

现在，在区域内建立信任并将其连接到父区域的方法已经有了，但是我们如何信任 DS 记录呢？DS 记录就像其他任何 RRset 一样签署，这意味着它在父级中具有相应的 RRSIG。整个验证过程不断重复，直到获得父级的公共 KSK。为了验证父级的公共 KSK，我们需要转到父级的 DS 记录，以此类推，沿着信任链上行。

但是，当我们最终到达根 DNS 区域时，又有一个问题：没有父 DS 记录可用于验证。在这里，我们可以看到全球互联网非常人性的一面：

在“根区域签名仪式”上，来自世界各地的特定几人以公开且经严格审核的方式签署根 DNSKEY RRset。这次仪式会产生一个 RRSIG 记录，该记录可用于验证根名称服务器的公共 KSK 和 ZSK。我们不会由于父级的 DS 记录而信任公共 KSK，而是因为信任访问私有 KSK 所涉的安全性过程而假定其有效。

在父区域和子区域之间建立信任的能力是 DNSSEC 不可或缺的一部分。如果信任链中的任何部分被破坏，我们就不能信任我们所请求的记录，因为中间人可能会更改记录并将我们引导到任何 IP 地址。

Summary

Similar to HTTPS, DNSSEC adds a layer of security by enabling authenticated answers on top of an otherwise insecure protocol. Whereas HTTPS encrypts traffic so nobody on the wire can snoop on your Internet activities, DNSSEC merely signs responses so that forgeries are detectable. DNSSEC provides a solution to a real problem without the need to incorporate encryption.

Cloudflare’s goal is to make it as easy as possible to enable DNSSEC. All Cloudflare customers can add DNSSEC to their web properties by flipping a switch to enable DNSSEC and uploading a DS record (which we'll generate automatically) to their registrar.: Learn more about how to get DNSSEC.

We’ve also published an Internet Draft outlining an automated way for registries and registrars to upload DS records on behalf of our customers. This will enable Cloudflare to automatically enable DNSSEC for our entire community. Stay tuned for updates.

深受数百万互联网资产的信赖

查看案例研究