其实并没有什么卯月的记录。
首先快速了解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