什么是DNSSEC以及如何保护你的域名免受DNS劫持

将域名翻译为IP地址的DNS系统是在互联网早期设计的，几乎没有考虑安全性。这导致了诸如DNS缓存中毒和DNS劫持等漏洞。DNSSEC是专门为解决这些威胁而开发的，通过向DNS响应添加密码认证。

什么是DNSSEC?

DNSSEC(域名系统安全扩展)是DNS协议的一套扩展，为DNS响应添加数字签名验证。每个DNS响应都伴随一个数字签名，允许解析器验证数据是否来自合法来源且在传输过程中没有被篡改。

DNSSEC不加密DNS数据 — DNS查询和响应仍以纯文本形式发送。相反，它添加身份验证和完整性验证以确认答案来自权威名称服务器，而不是拦截流量的攻击者。

DNSSEC防止的威胁

DNS缓存中毒

攻击者将伪造的DNS响应注入递归解析器的缓存中，导致查询该域名的用户接收虚假IP地址并被引导到恶意网站。

DNS劫持

攻击者获得对DNS服务器的控制权或修改域名的DNS记录，将流量重定向到他们控制的服务器。这可能导致凭证盗取或恶意软件分发。

中间人DNS攻击

攻击者在DNS响应到达用户之前在传输中拦截并修改DNS响应。DNSSEC防止这种情况，因为任何修改都会导致签名验证失败。

DNSSEC如何工作

DNSSEC使用公钥密码学来建立从根区域到你的域名的信任链。它引入了几种新的记录类型：

• DNSKEY — 包含用于验证签名的区域的公钥
• RRSIG — 每个资源记录集的数字签名
• DS(委托签署者) — 存储在父区域中的DNSKEY的哈希以建立信任链
• NSEC/NSEC3 — 为不存在的记录提供已认证的存在否定

验证过程

1. 解析器收到带有RRSIG签名的DNS响应
2. 它从区域检索DNSKEY并验证RRSIG
3. 它针对父区域中的DS记录检查DNSKEY
4. 此过程重复到根区域信任锚点
5. 如果信任链完整且有效，则响应被信任

信任链的工作原理 — DS、DNSKEY和RRSIG深入

DNSSEC的核心是信任链，它从根区域开始链接信任，通过每个级别直到到达你的域名。每个区域用私钥签署自己的数据并在DNSKEY记录中发布匹配的公钥，而父区域仅存储该密钥的哈希(DS记录)来担保子区域。这意味着解析器永远不需要直接信任任何单个名称服务器 — 它信任一条签名链，该链一直回溯到根，这是内置于每个验证解析器中的信任锚。

在每个区域中有两种类型的密钥，服务于不同的目的，允许灵活地轮换密钥而无需每次都通知父级：

• KSK(密钥签署密钥) — 仅签署DNSKEY RRset。这是父级的DS记录指向的密钥，所以轮换它更难，因为注册商处的DS也必须更新。
• ZSK(区域签署密钥) — 签署区域中的所有其他记录(A、MX、TXT等)。它可以频繁和轻松地轮换，因为它不影响父级处的DS。

当解析器收到答案时，它按此顺序验证：使用DNSKEY(ZSK)验证所请求记录的RRSIG → 使用KSK验证DNSKEY RRset → 将KSK的哈希与父级处的DS记录进行比较 → 用父级的密钥验证该DS的RRSIG，以此类推直到根区域。如果任何哈希或签名不匹配，解析器返回SERVFAIL而不是给用户一个可能伪造的答案。

如何为你的域名启用DNSSEC

启用DNSSEC需要在权威名称服务器（区域文件所在位置）和注册商（域名注册位置）两端进行配置：

第一步 — 在名称服务器上签署区域

如果你使用AsiaGB名称服务器，区域签署可以自动处理。只需在名称服务器设置中启用DNSSEC，系统就会自动为你生成DNSKEY和RRSIG记录。

第二步 — 向注册商提交DS记录

区域签署后，你将收到一条DS记录（包含密钥标签、算法、摘要类型和摘要）。将这些值提交到域名注册商的管理面板，以便父区域将信任链链接到你的域名。DS记录示例如下：

example.com.  3600  IN  DS  12345 13 2 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE...

以下是每个值的含义——这些是大多数注册商表单要求你填写的字段：

对于.co.th和.in.th域名，提交DS记录可能需要通过注册局的支持渠道或表单，而.com域名可以直接从AsiaGB域名管理面板输入DS记录。提交后，DS记录将根据父区域的TTL传播（通常在几小时内）。

使用dig和DNSViz验证DNSSEC

启用DNSSEC后，在认为完成之前，请确认信任链完整。最快的方式是在自己的机器上使用dig命令：

# 检查区域是否已签署（是否有RRSIG）
dig example.com A +dnssec +multiline

# 检查存储在父区域的DS记录
dig example.com DS +short

# 检查区域的DNSKEY（KSK + ZSK）
dig example.com DNSKEY +short

# 与+cd（禁用检查）对比普通查询，查看验证是否通过
dig example.com A

如果验证成功，dig的回答将在HEADER中包含ad（已认证数据）标志，例如flags: qr rd ra ad;。如果ad缺失或返回status: SERVFAIL，说明信任链不完整——通常是因为注册商处的DS尚未传播或输入有误。

除了dig，可视化工具能让整体情况更清晰：

• dnsviz.net — 从根绘制信任链到你的域名，并用红色突出显示任何断裂的链接
• MXToolbox DNSKEY/DNSSEC Checker — 快速检查DNSKEY和DS记录
• Verisign DNSSEC Debugger — 显示每个验证步骤的状态

陷阱 — 密钥轮换和破坏DNSSEC的DNS迁移

DNSSEC是一把双刃剑：配置正确时非常安全，但密钥处理不当或以错误方式迁移DNS可能会让域名对验证解析器（如Google的8.8.8.8）立即从互联网上消失。最常见的问题包括：

1. 在未先删除DS记录的情况下迁移DNS提供商

这是域名中断的首要原因。当你从一个DNS提供商迁移到另一个时，新提供商会生成自己的KSK，因此注册商处的旧DS记录不再与新的DNSKEY集匹配 → 信任链断裂 → SERVFAIL。正确的做法是先在注册商处删除DS记录，等待TTL过期（临时禁用DNSSEC），然后迁移DNS，之后再重新启用DNSSEC并提交新的DS。

2. 密钥轮换

密钥应定期轮换以保证安全性，但必须有重叠，而不是立即替换——ZSK使用预发布方法（在开始签署之前提前公布新ZSK），KSK使用双签名方法（同时用旧KSK和新KSK签署，更新父级的DS以包含两个值，然后删除旧的）。如果在不考虑TTL的情况下立即交换密钥，仍然缓存旧密钥的用户将验证失败。

3. 时钟偏差

每个RRSIG都有起始和过期时间。如果服务器或解析器的时钟有误，或者因忘记自动区域重新签署导致签名过期，签名将立即被视为无效。自动DNS系统（如AsiaGB的系统）会在过期前重新签署，从而避免此问题。

DNSSEC的优势与局限性

优势

• 有效防止DNS缓存投毒和劫持
• 提高DNSSEC验证解析器用户的信任度
• DANE（基于DNS的命名实体身份验证）的基础，用于TLS验证

局限性

• DNSSEC不加密DNS流量——需要DNS over HTTPS (DoH) 或 DNS over TLS (DoT)
• 由于附带签名导致DNS响应更大
• 密钥轮换必须谨慎管理
• 并非所有注册商都支持DS记录提交

关于DNSSEC的常见问题

DNSSEC会加密我的DNS数据吗？

不会。DNSSEC不加密DNS——查询和响应仍以明文形式发送，因此任何拦截流量的人都可以看到你查询了哪些域名。DNSSEC只提供身份验证和完整性。若需DNS隐私，还需要使用DNS over HTTPS (DoH) 或 DNS over TLS (DoT)，它们在与DNSSEC不同的层面运行，可以一起使用。

启用DNSSEC会让我的网站变慢吗？

不会明显变慢。唯一的影响是由于附带签名导致DNS响应稍大，以及解析器需要进行少量额外验证工作，以毫秒计。对于典型网站，这对页面加载速度没有影响。

如果我的注册商不支持DNSSEC怎么办？

如果你当前的注册商没有输入DS记录的字段，即使DNS提供商签署了区域，你也无法启用DNSSEC。解决方案是将域名转移到支持它的注册商，例如AsiaGB，它支持.com、.co.th和.in.th域名的DS记录配置。

我可以在启用了DNSSEC的域名上迁移主机吗？

可以，通常情况下可以。迁移Web服务器（更改A/AAAA记录指向新IP）不会影响DNSSEC，只要你保持相同的DNS提供商，因为新记录会自动用相同的密钥集签署。DNSSEC只在你更改DNS提供商或名称服务器而不更新DS记录时才会出现问题。