DNSSEC 解决了什么问题?

信息安全 dns 域 dns 欺骗 dnssec
2021-08-25 09:32:24

我已经阅读了该站点上标记为 DNSSEC 的问题,多年来,您听到了有关 DNSSEC 采用以及在其域中启用它的组织的统计数据……但没有人提及他们实际试图解决的问题。好吧,它“签署 DNS 响应”,但这是一种方法,而不是目标。

“IP 欺骗将不再可能,”当话题出现时,科技新闻会写道。或者“DNSSEC 允许域名所有者签署他们的 DNS 记录” howtogeek 写道然而,如果我作为攻击者可以欺骗 DNS 响应,那么我可能是中间人,对连接有明显的读/写访问权限,允许我修改内容。或者如果有人使用 HTTPS,我是否可以欺骗 IP 地址并不重要,因为我没有匹配的 CA 签名证书。

域所有者可以签署他们的 DNS 记录甚至没有意义,因为公钥(用于签署数据)最终会如何与 DNS 客户端联系?除了使每个 DNS 响应膨胀似乎非常低效之外,如果您将公钥与签名数据结合起来,那么将公钥与签名一起交换是一项简单的操作。

据称被 DNSSEC 阻止的攻击是 DNS 缓存中毒,但这不是通过让递归解析器使用随机源端口来解决的问题吗?

此外,我今天从我的 ISP (荷兰语)那里听说他们正在启用它。签署记录的不是域名所有者吗?此外,我还阅读了他们不久前启用的 SIDN(荷兰 TLD .nl 的所有者)。他们甚至在主页上有一个计数器,用于计算启用 DNSSEC 的域的数量。一些注册商(例如 TransIP)也启用了它。谁在签署这些东西:域名所有者、注册商或 TLD?

最后,并非所有内容都已签名。似乎有些域启用了 DNSSEC,而有些则没有(即使它们都来自同一个顶级域)。客户怎么会知道它是否应该被签名?在欺骗响应时剥离签名似乎是一种简单的攻击。

有人可以解释一下:

  • DNSSEC 的目标是什么?
  • 谁必须启用它才能使其工作?
  • 谁签署了域名?
  • 客户端如何检测签名被删除?
2个回答

1. DNSSEC 的目标是什么?

DNSSEC 签署 DNS 记录。它不加密,它只是确认真实性。

来自 TLD(例如 .org 或 .de)的根签名密钥、来自注册商的 TLD 签名密钥以及注册商签署您(可能)通过其 Web 界面输入的 DNS 记录。[2]

您也可以让他们为您的密钥签名,以便您自己维护一个签名区域。[3]

DNSSEC 存在添加到域的字段,因此在为您的计算机打开它之后,它并不是对每个网站都有效的东西。如果注册商不支持它,或者如果 TLD 不支持它,您的计算机将无法验证您正在查询的域记录的真实性。

2. 谁必须启用它才能工作?

我们已经介绍了根目录、您选择的 TLD 和注册商。现在 ISP 或其他递归解析器(例如 OpenDNS)也可以启用或不启用它。启用它意味着他们的解析器将检查签名并在验证失败时返回错误代码。[4]

用户的客户端还必须启用某些功能才能使其工作:如果您的客户端(例如 Firefox)没有对无效签名发出警报,则签名将永远不会添加任何值。[5]

3. 谁签署域名?

注册商要么签署您的记录,要么签署您签署记录的密钥。所以你信任注册商。如果您不信任注册商,您将不得不换一个。而且您信任 TLD,因为他们可以使用他们喜欢的任何密钥对其进行签名(因为他们可以签署注册商的密钥)。出于同样的原因,您信任根。

4. 客户端如何检测签名被删除?

如果有人删除了签名,大概是为了修改记录而不触发签名验证错误,则可能看起来该域根本没有启用 DNSSEC。但是,父签名者(TLD)会提到应该为域启用 DNSSEC,并且 TLD 的响应是签名的,因此不能伪造。[6]

那么如果我们也删除 TLD 的签名呢?好的,然后根会告诉我们(带有签名)TLD 应该启用它。

如果根是可信的,根只签署合法的 TLD,TLD 是可信的,TLD 只签署注册商,注册商是可信的,那么您可以确定签署的记录直接来自域所有者。

5. 奖励:DNSSEC 本身是否有任何问题?

它使响应更大(不是安全问题,而是性能问题)并有助于域枚举。

由于他们解决 NXDOMAIN 签名的方式,域枚举成为可能。签名是离线完成的,因此名称服务器不必即时签署。但是,对于不存在的东西,您如何提前签署回复?通过签署“在 ftp.example.com. 和 mail.example.com. 之间没有其他记录”的回复,并在有人要求 jkl.example.com 之类的内容时返回该回复。[1]

现在枚举,您从 aaaa.example.com 开始。它会告诉你第一条记录,比如 ftp.example.com。然后你请求 ftq.example.com(增加一个字符),它会给你下一条记录。

这是通过散列名称并“在散列 a8fba8[...] 和 da8a8bfdf[...] 之间没有其他记录”来解决的。这称为 NSEC3。[8]这仍然允许散列枚举,然后离线破解散列,这比通过查询名称服务器进行猜测要快几个数量级,也更隐秘。[9]

是否可以枚举名称是一个持续的讨论。设计 DNSSEC 的人通常会说 DNS 系统应该是一个公共电话簿;部署 DNS 服务器的人通常更喜欢将电话簿保密。[7]


[1] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Zone_enumeration_issue.2C_controversy.2C_and_NSEC3

[2] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Operation

[3] “您通过创建 DS 记录告诉您的注册商您的签名密钥的指纹” https://security.stackexchange.com/a/11571/10863

[4] “他们启用他们的 DNS 解析器(你用来将花哨的域名转换为 IP 地址)来验证 DNSSEC。所以从现在开始,如果你向你的 ISP 询问域的 IP 并且签名无效,你将得到一个错误而不是错误的 IP。” security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267595_142626

[5] “取决于客户端是否喜欢(或提醒)未签名的响应,就像 Web 浏览器上的 TLS 一样。” security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267602_142604

[6] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Recursive_name_servers “如果“example.com”有 DS 记录,但回复中没有 RRSIG 记录,则说明有问题,可能中间有人攻击正在进行中”

[7] https://security.stackexchange.com/a/11571/10863 “DNS(和 DNSSec)主要由第一阵营的人设计;[...] 服务器往往由第二阵营的人运行营”

[8] https://security.stackexchange.com/a/126518/10863

[9] https://dnscurve.org/nsec3walker.html见“未来工作”

它解决了完整性保证。将不再可能 MITM 签名区域。现在任何人都可以伪造 DNS 记录,但他们不能使用 DNSSEC。客户端已经知道根区域的公钥,并且可以验证到该区域的整个链。

注册域时,您必须告诉 TLD 区域您的域名服务器所在的位置。此时,您还可以附加一个公钥。TLD 区域签署您的条目,从那时起,每个人都可以通过检查 TLD 区域来验证您的区域的完整性。您自己的区域反过来可以签署它的记录。由于您的公钥是已知且经过验证的,因此只有您可以签署您的区域。TLD 区域依次从根区域以相同的方式签名,并且 DNS 客户端知道该公钥。这样,如果有人试图欺骗 DNS 响应,他们必须首先修改您的 DNS 客户端,以替换存储的根密钥,或者完全禁用 DNSSEC。