Cloudflare
DNSSEC
Segurança
DNS
Criptografia

DNSSEC 与 Cloudflare:它保护什么、不保护什么以及如何顺利激活

DNSSEC 不加密任何内容——它对 DNS 响应进行签名以证明真实性。了解这种区别是激活该功能而不创建破坏生产的操作依赖性的第一步。

DNSSEC 与 Cloudflare:它保护什么、不保护什么以及如何顺利激活

关于 DNSSEC 最常见的混淆是将其描述为“[DNS 加密1”。从这个错误前提出发的团队会得出两个同样错误的结论:要么因为“我们已经有了 TLS”而放弃该功能,要么在不了解刚刚引入的操作依赖性的情况下激活该功能。 DNSSEC 对 DNS 响应进行签名以证明真实性 — 它不会加密任何内容。它阻止的攻击、配置管理不善的后果以及它根本没有涵盖的三个不同主题值得单独处理。

DNSSEC 的实际作用

当递归解析器查询权威服务器并收到响应时,传统 DNS 中没有机制来验证该响应是否合法。 Dan Kaminsky 在 2008 年描述的缓存中毒攻击(以及后来的变体)正是利用了这一点:攻击者将虚假记录注入解析器的缓存中,在域所有者不知情的情况下将流量重定向到其控制下的 IP。用户查询受损的解析器,收到带有看似正常响应的恶意 IP,然后继续前进。 TLS 本身并不能解决这个问题:如果用户被带到具有该域的有效证书的服务器(例如通过另一个 CA 中的 DV 获得的证书),即使目的地是欺诈性的,HTTPS 链也会显得完整。

DNSSEC 在任何 TCP 连接之前解决 DNS 层的问题。每个 DNS 响应都携带 RRSIG 记录 - 使用区域私钥生成的加密签名。支持 DNSSEC 验证的解析器使用区域中发布的公钥(DNSKEY 记录)验证签名,并通过检查父区域中的 DS 记录来验证该公钥是否合法 - 信任链从根向下延伸,穿过 TLD 区域(.com、.com.br)并到达您的区域。在声明 DNSSEC 支持的区域中,签名无效或缺失的记录会导致 SERVFAIL:解析器拒绝响应,而不是传递可能被篡改的数据。

DNSSEC 不涵盖的内容

DNSSEC 不加密 DNS 查询。网络上的观察者仍然可以看到您正在查询哪些域 - 为此,有 DNS over HTTPS (DoH) 和 DNS over TLS (DoT),这是加密传输的独立协议。 DNSSEC 也不会保护您的服务内容,不会缓解针对您的权威服务器的 DDoS,也不会防止在与您的域名相似的域名上进行误植或网络钓鱼。保证是狭窄且具体的:您的区域的 DNS 响应在正确签名后会到达解析器而不会被篡改。

在 Cloudflare 上激活

Cloudflare 中的技术流程很简单:区域 DNS 面板上的按钮生成密钥对,开始签署区域中的所有记录,并开始自动提供 RRSIG 记录。所有计划均提供该功能,包括免费计划。接下来您要做的事情将决定 DNSSEC 是否正常工作或中断生产。

在仪表板中激活后,Cloudflare 会显示您需要向注册商注册的 DS 记录。此 DS 记录由注册商发布到 TLD 区域,是将 TLD 的信任与您的区域连接起来的链接 - 如果没有它,信任链就不完整,并且经过 DNSSEC 验证的解析器会将您的区域视为未签名,而不是无效。 DS 注册过程因注册商而异:有些在控制面板上有图形界面,有些则要求您手动输入字段 - 密钥标签、算法、摘要类型和摘要。启用 DNSSEC 后,Cloudflare 会显示所有这些格式化值。

密钥轮换问题

DNSSEC 的运营风险不在于激活,而在于维护。 Cloudflare 定期轮换区域的 DNSSEC 密钥。发生这种情况时,需要更新向注册商注册的 DS 记录以反映新密钥。如果注册商支持通过 API 自动进行 DS 更新(例如 Cloudflare Registrar、处于注册域模式的 Amazon Route 53 以及启用了 API 的 Namecheap),则无需手动干预即可进行轮换。如果注册商不支持,Cloudflare 会向您发送警报,并且您有一段时间手动更新。

缺少此窗口会产生直接后果:寄存器中的 DS 指向该区域不再使用的密钥。经过 DNSSEC 验证的解析器开始接收由与已发布 DS 不同的密钥签名的 RRSIG,断定已发生篡改,并对您的域的任何查询返回 SERVFAIL。从用户的角度来看,域只是停止解析。该修复需要更新注册商中的 DS 并等待 TLD 区域的 TTL 传播,这通常很长,大约需要几个小时,因为您无法控制该 TTL。

安全激活:之前和之后要检查的内容

在启用 DNSSEC 之前,请确认您的注册商接受相关域的 DS 记录。对于 0 域,Registro.br 现在支持 DNSSEC,但历史支持不一致 - 在 Cloudflare 上激活之前,值得直接在仪表板中检查 DS 选项是否适用于您的特定域。在无法向注册商注册 DS 的情况下激活 Cloudflare 会留下已签名的区域,但没有完整的信任链,这不会提供任何额外的保护,还会创建一种可能在未来诊断中产生混乱的状态。

激活并注册 DS 后,请使用 dnssec-analyzer.verisignlabs.com 或 dnsviz.net 等工具测试验证,然后再考虑该过程已完成。这些工具显示信任链中的每个环节,并识别无效、过期或丢失的 RRSIG 记录。设置密钥轮换警报 - Cloudflare 的仪表板提供电子邮件通知 - 并在 DNS 操作手册中记录 DS 更新过程。凌晨三点管理不善的轮换,公司的主域返回 SERVFAIL,这种事件应该在事件发生之前(而不是之后)记录在操作手册中。

考虑并行启用 CAA 记录。 CAA 指定哪些证书颁发机构有权为该域颁发证书,Cloudflare 支持无限制的注册类型。与 DNSSEC 相结合,CAA 关闭了第二个攻击面:即使攻击者设法通过另一个漏洞欺骗 CA,CAA 记录也会限制哪些 CA 可以向域颁发证书。

另请阅读

  • [DNS 代理与仅 DNS:有何变化以及每种模式何时有意义2?
  • [Cloudflare DNS:远远超出解析名称的网络基础设施3
  • [Cloudflare 负载均衡和地理转向:当 DNS 成为智能流量层4
  • [Cloudflare 电子邮件路由:在您的域上接收电子邮件 - 以及不包括的内容55
  • [Cloudflare WAF:托管保护实际上阻止了什么以及它通过了什么6
  • [WAF + 速率限制 + 爬虫程序管理:边缘 7° 保护三重奏