01.11.2024

域名系统

安全

DNSSEC 解释：如何保护您的域名并防止 DNS 攻击

DNS 是互联网的骨干——但它从未以安全为设计初衷。每当用户在浏览器中输入您的域名时，DNS 查询就会发送到网络中，如果没有适当的保护，该查询可能被拦截、篡改或中毒。DNSSEC（域名系统安全扩展）是关闭这一漏洞的密码学解决方案，在配置正确的服务器上部署它是保护您在线存在的最具影响力的步骤之一。

本综合指南涵盖您需要了解的一切：DNS 如何工作、为什么它容易受到攻击、DNSSEC 如何解决这些漏洞，以及如何在您的托管环境中逐步实施它。

1. 什么是 DNS，为什么它容易受到攻击？ {#dns-vulnerabilities}

域名系统（DNS）充当互联网的电话簿。当用户在浏览器中输入 www.example.com 时，DNS 将该人类可读的主机名转换为机器可读的 IP 地址——比如 93.184.216.34——这样连接就可以建立。

这个过程在毫秒内发生，无声地，每天进行数十亿次。但这里有一个关键问题：传统 DNS 没有内置机制来验证您收到的响应是否真实。DNS 是在 1980 年代初为一个更小、更受信任的互联网设计的。身份验证根本不是优先考虑的事项。

两个最危险的 DNS 攻击向量

#### DNS 缓存中毒

缓存中毒攻击（也称为 DNS 欺骗）发生在攻击者将虚假 DNS 记录注入递归解析器的缓存时。一旦被中毒，解析器会向查询该域的每个用户提供恶意 IP 地址——将他们重定向到网络钓鱼网站、恶意软件分发页面或虚假登录门户——用户完全不知道发生了什么。

臭名昭著的卡明斯基攻击（2008 年发现）证明了 DNS 缓存的脆弱性有多么严重，可以在一分钟内使用暴力技术被中毒。

#### 中间人 (MitM) DNS 攻击

在 MitM DNS 攻击中，对手位于客户端和 DNS 解析器之间，拦截并修改传输中的 DNS 响应。这在不安全的网络上特别危险，流量可能被重新路由到攻击者控制的基础设施，而不会触发任何浏览器警告。

#### 为什么这些攻击如此有效

DNS 响应默认不进行身份验证
解析器缓存响应并将其提供给许多用户
用户无法看到 DNS 是否被篡改
即使是 HTTPS 也不能完全防止 TLS 握手前的 DNS 级别重定向

这正是 DNSSEC 被设计来解决的问题。

2. 什么是 DNSSEC，它如何工作？ {#how-dnssec-works}

DNSSEC（域名系统安全扩展）是一套 IETF 规范，为 DNS 添加了密码学身份验证。它不加密 DNS 查询或响应——DNS over HTTPS (DoH) 处理这个问题——但它对 DNS 数据进行数字签名，允许解析器验证它们收到的记录是真实的且未被篡改。

将 DNSSEC 视为每个 DNS 记录上的防篡改封条。如果封条被破坏或丢失，解析器就知道数据不能被信任。

核心原则：数字签名

DNSSEC 使用非对称密码学（公钥/私钥对）来签署 DNS 记录：

私钥签署 DNS 记录，生成数字签名
公钥在 DNS 区域本身中发布
解析器使用公钥验证签名，然后才接受响应
如果验证失败，解析器返回 SERVFAIL 错误，而不是提供可能恶意的数据

这意味着即使攻击者拦截或修改 DNS 响应，密码学签名也不会匹配，解析器将拒绝篡改的数据。

3. 关键 DNSSEC 组件说明 {#dnssec-components}

理解 DNSSEC 需要熟悉几种新的 DNS 记录类型，它们协同工作以建立和验证真实性。

DNSKEY 记录

DNSKEY 记录包含 DNS 区域的公密码学密钥。有两种类型：

密钥类型	缩写	用途
区域签名密钥	ZSK	签署区域内的单个 DNS 记录
密钥签名密钥	KSK	签署 DNSKEY 记录集本身

KSK 是两者中更敏感的——它签署 ZSK，而 ZSK 又签署所有其他记录。这种两层方法允许区域运营商频繁轮换 ZSK，而无需更改 KSK（因此无需在父区域更新 DS 记录）。

RRSIG 记录（资源记录签名）

DNSSEC 启用区域中的每个签署的 DNS 记录集 (RRset) 都有一个对应的RRSIG 记录，其中包含数字签名。当解析器查询 DNSSEC 签署的区域时，它会收到记录及其 RRSIG，然后使用 DNSKEY 验证签名。

DS 记录（委派签名者）

DS 记录在父区域中发布（例如，.com 对于 example.com），包含子区域 KSK 的哈希。这是连接信任链中父区域和子区域的关键链接。

NSEC / NSEC3 记录（下一个安全）

这些记录提供经过身份验证的不存在证明——它们证明查询的 DNS 记录确实不存在，防止攻击者伪造”未找到”响应。NSEC3 是更安全的变体，因为它使用哈希名称来防止区域枚举。

4. 信任链：DNSSEC 的核心机制 {#chain-of-trust}

DNSSEC 的安全模型建立在分层信任链之上，该链镜像 DNS 层次结构本身。理解这个链对于理解 DNSSEC 为什么有效至关重要。

Root Zone (.)
    └── Signed by Root KSK (Trust Anchor)
         └── .com Zone
              └── DS record points to example.com KSK
                   └── example.com Zone
                        └── DNSKEY (KSK + ZSK)
                             └── RRSIG signs all records

验证如何逐步工作

第 1 步——查询启动

用户的浏览器向递归解析器查询 www.example.com。如果解析器进行 DNSSEC 验证，它会请求 DNS 记录及其关联的 RRSIG 签名。

第 2 步——获取 DNSKEY

解析器检索 example.com 的 DNSKEY 记录，并使用 ZSK 验证请求的记录上的 RRSIG。

第 3 步——验证 KSK

解析器然后通过检查在 .com 父区域中发布的 DS 记录来验证 KSK 本身。

第 4 步——追踪到根

.com 区域的真实性根据根区域的 DS 记录进行验证，根区域根据根信任锚进行验证——DNSSEC 验证解析器预配置为信任的一组公钥（由 ICANN 维护）。

第 5 步——接受或拒绝

如果链中的每个签名都正确验证，解析器将 DNS 响应返回给客户端。如果任何签名失败或在预期位置丢失，解析器返回 SERVFAIL——保护用户免受可能恶意的数据。

5. 实施 DNSSEC 的好处 {#benefits}

5.1 防止缓存中毒和欺骗

这是 DNSSEC 的主要价值主张。因为每个 DNS 记录都进行了密码学签名，攻击者无法在不使签名失效的情况下将虚假记录注入解析器的缓存。即使是复杂的卡明斯基式攻击对 DNSSEC 验证解析器也无效。

5.2 数据完整性保证

DNSSEC 保证 DNS 记录在传输中未被修改。对于依赖 DNS 进行电子邮件路由（MX 记录）、服务发现（SRV 记录）或证书验证（CAA 记录）的企业，这种完整性对于运营可靠性至关重要。

5.3 高级安全协议的基础

DNSSEC 启用了几种依赖于经过身份验证的 DNS 的更高级别安全机制：

DANE（命名实体的基于 DNS 的身份验证）：允许通过 DNS 验证 TLS 证书，减少对证书颁发机构的依赖
SSHFP 记录：在 DNS 中存储 SSH 指纹，启用自动主机密钥验证
DKIM 和 SPF 验证：通过确保基于 DNS 的电子邮件记录未被篡改来加强电子邮件身份验证

5.4 增加用户和客户信任

实施 DNSSEC 的组织表明了对安全最佳实践的承诺。对于电子商务网站、金融服务和任何处理敏感用户数据的平台，DNSSEC 是补充您的SSL 证书和更广泛安全态势的重要防御层。

5.5 监管和合规性对齐

许多安全框架和政府 IT 标准（包括 NIST 指南和各种国家网络安全授权）建议或要求对面向互联网的服务实施 DNSSEC。主动实施它可以让您走在合规要求之前。

6. DNSSEC 实施分步指南 {#implementation}

第 1 步：验证兼容性

在生成任何密钥之前，确认您的DNS 托管提供商和域名注册商都支持 DNSSEC。具体来说，您需要：

支持 DNSSEC 签名的 DNS 服务器（BIND 9.7+、PowerDNS、Knot DNS 等）
接受您的 TLD 的 DS 记录提交的注册商
确认您的 TLD 支持 DNSSEC（几乎所有主要 TLD 都支持，包括 .com、.net、.org、.io）

如果您在VPS 托管环境中管理自己的 DNS，您可以完全控制此配置。

第 2 步：生成密码学密钥对

在基于 BIND 的 DNS 服务器上，使用 dnssec-keygen 实用程序生成您的 ZSK 和 KSK：

# Generate the Zone Signing Key (ZSK)
dnssec-keygen -a RSASHA256 -b 1024 -n ZONE example.com

# Generate the Key Signing Key (KSK)
dnssec-keygen -a RSASHA256 -b 2048 -f KSK -n ZONE example.com

这为每个密钥生成两对文件：

Kexample.com.+008+XXXXX.key — 公钥（添加到您的区域文件）
Kexample.com.+008+XXXXX.private — 私钥（保持安全，永不发布）

> 安全说明：将私钥存储在安全、访问受控的位置。考虑为高安全性环境使用硬件安全模块 (HSM)。

算法建议（2024）：

ECDSA P-256（算法 13）：推荐用于新部署——密钥大小更小，验证更快
RSA/SHA-256（算法 8）：广泛支持，兼容性好
避免较旧的算法，如 RSA/SHA-1（算法 5）——被认为在密码学上较弱

第 3 步：签署您的 DNS 区域

在您的区域文件中包含您的公钥，然后签署区域：

# Add key includes to your zone file
$INCLUDE /etc/bind/keys/Kexample.com.+008+XXXXX.key
$INCLUDE /etc/bind/keys/Kexample.com.+013+YYYYY.key

# Sign the zone
dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) 
  -N INCREMENT -o example.com -t db.example.com

这生成一个签署的区域文件（例如 db.example.com.signed），包含所有原始记录加上它们的 RRSIG 签名和 NSEC3 记录。

更新您的 BIND 配置以使用签署的区域文件：

zone "example.com" {
    type master;
    file "/etc/bind/db.example.com.signed";
};

重新加载 BIND：

sudo rndc reload

第 4 步：自动化区域签名（推荐）

手动区域签名容易出错，每次记录更改时都需要重新签名。对于生产环境，使用BIND 的内联签名或自动化 DNSSEC 管理：

# In named.conf.local — enable auto-DNSSEC
zone "example.com" {
    type master;
    file "/etc/bind/db.example.com";
    auto-dnssec maintain;
    inline-signing yes;
    key-directory "/etc/bind/keys";
};

启用内联签名后，BIND 会自动签署新记录并处理密钥轮换。

第 5 步：提取并发布 DS 记录

从您的 KSK 中提取 DS 记录数据：

dnssec-dsfromkey Kexample.com.+013+YYYYY.key

这输出类似于：

example.com. IN DS 12345 13 2 A1B2C3D4E5F6...

登录您的域名注册商的控制面板并提交此 DS 记录。注册商将在父区域（例如 .com）中发布它，完成信任链。

> 重要：在 DS 记录全局可见之前会有传播延迟（通常为 24-48 小时）。在此期间不要删除您的未签署区域。

第 6 步：验证您的 DNSSEC 配置

使用这些工具确认 DNSSEC 正常工作：

# Check DNSSEC validation with dig
dig +dnssec example.com A

# Verify the chain of trust
dig +trace +dnssec example.com

# Check DS record publication
dig DS example.com @a.gtld-servers.net

在线验证工具：

DNSViz (dnsviz.net) — 信任链的可视化分析
Verisign DNSSEC 调试器 — 综合验证测试
ICANN DNSSEC 分析器 — 快速通过/失败验证检查

在 dig 响应中查找 ad（经过身份验证的数据）标志——这确认 DNSSEC 验证成功。

第 7 步：规划您的密钥轮换策略

DNSSEC 密钥必须定期轮换以维持安全。推荐的轮换间隔：

密钥类型	推荐轮换
ZSK	每 3-6 个月
KSK	每 1-2 年

密钥轮换必须使用预发布或双签名方法小心执行，以避免在转换期间破坏信任链。尽可能自动化此过程。

7. AlexHost VPS 上的 DNSSEC：为什么重要 {#alexhost-dnssec}

部署 DNSSEC 的可靠性只取决于运行它的基础设施。DNS 签名是一项计算密集、延迟敏感的操作——您的托管环境质量直接影响性能和安全性。

为什么 AlexHost VPS 适合 DNSSEC 部署

AlexHost 的VPS 托管提供 DNSSEC 所需的技术基础：

NVMe SSD 存储：DNSSEC 签名涉及区域文件和密钥存储的频繁磁盘 I/O。NVMe 驱动器提供低延迟、高吞吐量的性能，即使在繁重的签名负载下也能保持 DNS 响应时间快速。
完全根访问：DNSSEC 配置需要深层系统级访问——安装和配置 BIND 或 PowerDNS、管理密钥目录、编辑区域文件以及安排自动签名作业。AlexHost VPS 为您提供无限制的根访问来完成所有这些。
DDoS 防护：DNS 服务器是放大和反射 DDoS 攻击的频繁目标。AlexHost 的内置 DDoS 缓解保护您的 DNS 基础设施免受可能中断解析的容量攻击。
高性能网络：低延迟连接确保 DNSSEC 验证（涉及 DNSKEY 和 DS 记录的额外 DNS 查询）不会显著影响查询响应时间。

控制面板选项

如果您更喜欢基于 GUI 的 DNS 管理方法，AlexHost 提供带 cPanel 的 VPS 和一系列VPS 控制面板，包括 DNSSEC 管理界面，使您可以轻松启用和管理 DNSSEC，而无需仅在命令行上工作。

补充安全服务

DNSSEC 在分层安全策略中效果最佳。将其与以下配对：

SSL 证书 — 加密用户和您的服务器之间的流量，补充 DNSSEC 的 DNS 层保护
域名注册 — 使用支持 DS 记录提交的提供商注册和管理您的域，以实现无缝 DNSSEC 部署
电子邮件托管 — DNSSEC 保护的 MX 和 SPF 记录加强您的电子邮件安全态势，降低针对您的域的电子邮件欺骗和网络钓鱼攻击的风险

8. 要避免的常见 DNSSEC 错误 {#common-mistakes}

即使是经验丰富的管理员在部署 DNSSEC 时也会犯错。以下是最关键的陷阱：

❌ 忘记在区域更改后重新签名

每次修改 DNS 记录时，都必须重新签署区域。未签署的记录将无法通过 DNSSEC 验证。使用内联签名或自动化工具来防止这种情况。

❌ 让签名过期

RRSIG 记录有过期日期。如果签名在续期前过期，您的整个域将无法为具有 DNSSEC 验证解析器的用户解析。监控签名有效性并自动化续期。

❌ 在签名处于活动状态之前发布 DS 记录

如果您在区域正确签署并提供 DNSSEC 响应之前在注册商处发布 DS 记录，解析器将尝试验证并失败——使您的域离线。始终在提交 DS 记录之前验证签名是否正常工作。

❌ 丢失私钥

如果您丢失了私钥，就无法重新签署您的区域。维护所有私钥材料的安全、冗余备份。

❌ 使用弱算法

避免 RSA/SHA-1 和其他已弃用的算法。对于新部署，使用 ECDSA（算法 13）或 RSA/SHA-256（算法 8）。

❌ 忽视密钥轮换

忽视密钥轮换是一个安全风险。实施有文档记录的轮换计划，并在生产环境中执行之前在暂存环境中测试该过程。

9. 常见问题 {#faq}

DNSSEC 会加密我的 DNS 查询吗？

不会。DNSSEC 对 DNS 数据进行身份验证——它验证记录是真实的且未被修改——但它不加密 DNS 查询或响应的内容。为了查询隐私，除了 DNSSEC 外，还要使用 DNS over HTTPS (DoH) 或 DNS over TLS (DoT)。

DNSSEC 会减慢我的 DNS 响应吗？

实际上影响很小。DNSSEC 响应稍大（由于额外的记录），验证需要一些额外的查询。在具有快速存储的现代硬件上——如 AlexHost 的 NVMe 支持的 VPS——这种开销可以忽略不计。

如果 DNSSEC 验证失败会发生什么？

如果 DNSSEC 验证解析器无法验证签名链，它返回 SERVFAIL 错误。用户的浏览器将显示 DNS 解析错误。这是有意的——安全失败比提供可能恶意的 DNS 数据更好。

如果我已经有 HTTPS/SSL，我还需要 DNSSEC 吗？

是的，它们保护不同的层。SSL/TLS 加密用户和您的服务器之间的连接，但它不能防止在 TLS 握手*之前

全场主机优惠15%