Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

4.5.2. 了解 DNSSEC

为了通过互联网连接,越来越多的网站现在能够使用 HTTPS 进行安全连接。但是,在连接到 HTTPS webserver 之前,必须执行 DNS 查找,除非您直接输入 IP 地址。这些 DNS 查找是不安全的,并会因为缺少身份验证而受到中间人攻击。换句话说,DNS 客户端无法确信,显示来自给定 DNS 名称服务器的回复是身份验证的,并且未被篡改。更重要的是,递归名称服务器无法确保从其他名称服务器获得的记录是真正的。DNS 协议没有为客户端提供一种机制,以确保其不会受到中间人攻击。引入了 DNSSEC,以解决在使用 DNS 解析域名时缺少身份验证和完整性检查的问题。它没有解决机密性问题。
发布 DNSSEC 信息涉及数字签名 DNS 资源记录以及发布公钥,从而使 DNS 解析器能够建立分层的信任链。所有 DNS 资源记录的数字签名将作为数字签名资源记录(RRSIG)生成并添加到区域中。区域的公钥添加为 DNSKEY 资源记录。为构建层次结构链,DNSKEY 的哈希发布在父区域中,作为签名(DS)资源记录委派。为了便于验证不存在,使用 NextSECure(NSEC )和 NSEC3 资源记录。在 DNSSEC 签名区域中,每个资源记录集(RRset )都有对应的 RRSIG 资源记录。请注意,用于委派到子区域(NS 和粘滞记录)的记录并未签名;这些记录显示在子区域中,并在其中签名。
处理 DNSSEC 信息由配置了 root 区域公钥的解析器完成。使用此密钥,解析器可以验证 root 区域中使用的签名。例如,root 区域已为 DS 记录进行了 签名 :root 区域还提供 .com 名称服务器的 NS 和 粘滞记录。解析器遵循这一委派,并 使用这些 委派的名称服务器查询 的 DNSKEY 记录。获取的 DNSKEY 记录的哈希应与 root 区域中的 DS 记录匹配。如果是这样,解析器将信任获得的 DNSKEY for .com。在 .com 区域中,RRSIG 记录由 .com DNSKEY 创建。此过程在 .com 内部类似地重复执行,如 redhat.com。使用此方法,验证 DNS 解析器只需要配置一个根密钥,而它在正常操作期间从全球收集多个 DNSKEY。如果加密检查失败,解析器会将 SERVFAIL 返回至应用程序。
DNSSEC 的设计方式使不支持 DNSSEC 的应用程序完全不可见。如果非 DNSSEC 应用查询 DNSSEC 解析器,它将接收答案,而无需任何这些新资源记录类型,如 RRSIG。但是,DNSSEC 解析器仍然会执行所有加密检查,如果它检测到恶意 DNS 答案,仍会向应用程序返回 SERVFAIL 错误。DNSSEC 可保护 DNS 服务器之间数据的完整性(权威和递归),它不提供应用与解析器之间的安全性。因此,向应用程序赋予其解析器的安全传输非常重要。最简单的方法是在 localhost 上运行 DNSSEC 功能解析器,并在 /etc/resolv.conf 中使用 127.0.0.1。或者可以使用到远程 DNS 服务器的 VPN 连接。

了解 Hotspot 问题

Wi-Fi Hots 或 VPN 依赖于 DNS:设备门户倾向于劫持 DNS,以便将用户重定向到页面,要求他们为其 Wi-Fi 服务进行身份验证(或支付费用)。用户连接到 VPN 时通常只需要使用内部 DNS 服务器,才能查找在公司网络之外不存在的资源。这需要通过软件进行额外的处理。例如,dnssec-trigger 可用于检测 Hotspot 是否在劫持 DNS 查询并且 unbound 可以充当代理服务器来处理 DNSSEC 查询。

选择 DNSSEC Capable Recursive Resolver

若要部署支持 DNSSEC 的递归解析器,可使用 BINDunbound。默认情况下启用 DNSSEC,并使用 DNSSEC 根密钥配置。要在服务器上启用 DNSSEC,但是在移动设备(如笔记本电脑)上使用 unbound 是首选的,因为它允许本地用户在使用 dnssec-trigger 时动态重新配置 Hotspots 所需的 DNSSEC 覆盖,在使用 Libreswan 时可以动态重新配置 Hotspots 所需的 DNSSEC 覆盖。unbound 守护进程进一步支持部署 etc/unbound/*.d/ 目录中列出的 DNSSEC 异常,这对于服务器和移动设备都非常有用。