其实并没有什么卯月的记录。
首先快速了解DNS的背景
DNS通常被称为互联网的电话簿。DNS是将域名（如cloudflare.com）转换为IP地址的协议。尽管整个互联网都严重依赖于DNS，但是它有一个巨大的安全漏洞：无法保证用户最终收到的DNS记录没有被篡改。这意味着可以伪造DNS记录将浏览器重定向至恶意网站来下载内容，在页面添加JavaScript来运行，或者将邮件引导至攻击者的邮件服务器。
DNSSEC介绍
因为我们一直以来将称DNS为互联网的电话簿，那么DNSSEC就是保证电话簿中列出的号码确实属于对应的联系人的协议。DNSSEC为此使用公钥密码系统，而且简而言之就是：
- 由DNS服务器记录私钥
- 由DNS解析器使用公钥验证签名
这些公钥由根区域保管。
实际情况下的DNSSEC
使用命令行工具dig查询DNS服务器并输出响应。使用其查询你使用的DNS解析器内www.cloudflare.com的IP记录的操作如下：
1
2
3
dig www.cloudflare.com +short
198.41.215.162
198.41.214.162
该工具默认显示A记录，并且由于+ short命令，其只输出结果。 如果我们想查看此记录是否可以使用DNSSEC验证，则可以执行：
1
2
3
4
dig www.cloudflare.com +short +dnssec
198.41.215.162
198.41.214.162
A 13 3 5 20180510124136 20180508104136 35273 cloudflare.com. zAmdoOfRWtCQ1kdrSN/ku4uiXHsjaHVemdgEzBbx9x1E7u3dlPEW4Cck x0Ca81AP6XFmTw/hBs9jJXNf+/2OeQ==
在最后一行你可以看见RRSIG记录。 这就是此记录附加的DNSSEC签名。解析器用此条信息来确认是否可以信任DNS的响应。然后我们还可以检索用来验证此记录的的公钥：
1
2
3
dig DNSKEY cloudflare.com +short
257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+GqJxpVXckHAeF+ KkxLbxILfDLUT0rAK9iUzy1L53eKGQ==
256 3 13 koPbw9wmYZ7ggcjnQ6ayHyhHaDNMYELKTqT+qRGrZpWSccr/lBcrm10Z 1PuQHB3Azhii+sb0PYFkH1ruxLhe5g==
在检索公钥的时候需要注意，我们应该以cloudflare.com的根域名为参数执行请求，而不是www.cloudflare.com，因为域名的所有记录都使用相同的密钥进行签名。请注意，之前的命令实际上返回了两条记录：
- 带有
256标志的DNSKEY记录是被称为Zone-signing-key的公钥，用于验证A，MX，CNAME，SRV等记录的签名 - 带有
257标志的DNSKEY记录被称为Key-Signing Key
从理论上来说，只需要一个公钥，但由于下面将要列出的原因需要两个。有关如何使用公钥验证签名的具体细节超出了本文的范围，但您可以在dig(1)联机帮助页中检索+ sigtrace选项的作用，或查看unbound-host命令的作用。
DNSSEC中的信任链
到目前为止，在本文中所有查询的响应都是由同一个域名服务器返回的，因此无论我们怎样使用签名信息进行验证都是不够：如果服务器遭到入侵，很有可能不仅仅是记录被篡改，密钥和签名也一样。 我们需要使用额外的信息源来验证所有信息。
为此，一个域名的完整签名验证（如：cloudflare.com）需要首先验证顶级域名（此处为.com）的key-signing-key，然后逐级执行与上述相同的操作（在根级检查.com的key-signing-key）。
这就是为什么当您启用DNSSEC时必须在注册商处添加特定的记录（DS记录）。DS记录即Delegation Signer，它包含公钥的哈希值以及关键字的元数据，例如使用的算法。
您可以运行以下命令查看cloudflare.com的DS记录：
1
2
dig +short DS cloudflare.com
2371 13 2 32996839A6D808AFE3EB4A795A0E6A7A39A76FC52FF228B22B76F6D6 3826F2B9
您还可以使用选项+trace验证此响应是否是由.com的域名服务器返回，而不是由cloudflare.com的域名服务器返回。 在此只展示相关行：
1
2
3
4
5
6
7
dig +trace DS cloudflare.com
[...]
cloudflare.com. 86400 IN DS 2371 13 2 32996839A6D808AFE3EB4A795A0E6A7A39A76FC52FF228B22B76F6D6 3826F2B9
[...]
com. 172800 IN NS e.gtld-servers.net.
[...]
;; Received 504 bytes from 192.12.94.30#53(e.gtld-servers.net) in 37 ms
因此，现在我们可以使用此方法利用其它来源来验证cloudflare.com的签名。但手动执行此过程的所有步骤十分麻烦。DNSViz是一个优秀的可视化工具用以验证DNSSEC信任链是否正常工作（如果没有，则显示在哪里失败）。
例如，对于cloudflare.com，点此查看输出 。
DNSSEC在Cloudflare的设置可以参看DNSSEC配置。
由于本人过于咸鱼，不免出现错翻的情况，附上原文链接How does DNSSEC work?。
本文采用CC BY-NC-ND 4.0许可协议进行许可，转载请注明出处。
本文最后更新时间为：2019-03-03-Sunday-11:14:03 AM
