Defaults.Exposed › 修复 › DNSSEC

如何修复 DNSSEC

DNSSEC 是给你域名通讯录盖的一枚数字封印。它让互联网能证明这个域名住在哪里这个问题的答案确实来自你、且在途中未被篡改。少了它，答案可被伪造——你的访客就被悄悄送往别处。

对您业务的关键影响： 没有 DNSSEC，一个能投毒 DNS 答复的攻击者可以把你的客户引向一个你网站的完美副本，而他们浏览器里仍显示着你真实的域名。登录信息、卡号和个人数据被收割，你直到退单和投诉时才知道。一个半成品、做坏了的 DNSSEC 配置更糟：它会让你的网站对越来越大一部分访客无法访问，而你永远不会察觉到任何错误。

这会让您付出什么代价

• 输入你真实域名的访客被悄悄重定向到一个仿冒站点，它截走他们的密码和卡号——而因为地址栏全程显示你的域名，谁都不会起疑，直到欺诈举报到来。
• 你的邮件被悄悄改道：攻击者伪造你邮件服务器的答复，读取或拦截消息，并在那些会给你发验证码的账户上重置密码——全程都不碰你的收件箱。
• 一个半配置的 DNSSEC（公开封印存在、但对应的密钥缺失）会让你的网站和邮箱对大型 ISP 和企业网络上的客户时灵时不灵——你无法复现的间歇性你的网站对我打不开的报告。
• 潜在客户的安全团队做一次签约前检查，发现没有 DNSSEC，便把你记为基础薄弱——一份免费的设置却让一笔交易陷入风险。
• 公共部门和较大的 B2B 买家越来越把 DNSSEC 当作基线期望（它被写进了 NIS2 等法规）；它的缺失会在谈话还没开始前就悄悄把你挡在招标门外。

为什么它重要。 DNS 是互联网的通讯录，而它的答案默认是未签名地传输的——任何能塞进一个伪造答复的人，都能把你的客户和邮件随意引向任何地方，而你真实的域名仍显示在浏览器里。DNSSEC 给这些答案盖上一枚防篡改的封印，使其能被验证为确实来自你。在大多数提供商那里修复是免费的；唯一真实的代价是做错了——这正是我们要把两半都仔细走一遍的原因。

一句话说清 DNSSEC

每当有人访问你的网站或给你发邮件，他们的电脑都会先向互联网问一个简单的问题：这个域名到底住在哪里？答案——你网站和邮件服务器的那组地址——由 DNS（互联网的通讯录）返回。

令人不安的部分是这样的：默认情况下，那些答案是未签名地传输的。没有任何东西附在上面证明这个答案是真的。如果有人能在那场对话里塞进一个伪造的答复——而确实存在众所周知、已被验证的方式做到这一点——你访客的电脑就会欣然接受它。从那一刻起，访客可能正在与一台攻击者的服务器对话，而他们的浏览器里仍显示着你的域名。

DNSSEC 就是修复办法。它给你的 DNS 答案加上一枚防篡改的数字封印。开启 DNSSEC 后，互联网能用数学方法验证一个答案确实来自你、且在途中未被改动。一个伪造的答复通不过验证、被丢弃。这就是一本任何人都能乱涂的通讯录，和一本每个条目都有签名、有见证的通讯录之间的区别。

本页覆盖我们的检查一并查看的两个部分：封印是否已发布（DS 记录），以及它背后对应的密钥是否真的存在（DNSKEY 记录）。你很快会看到为什么两者都重要——因为只有其一而无其二，本身就是一种麻烦。

这会让你付出什么代价

这些是真实、聚合的模式——不指任何一家具名企业。

• **隐形的重定向。**攻击者投毒你域名的 DNS 答复。客户输入你真实的网址，在地址栏看到你真实的域名，却落到一个由攻击者托管的、你登录页或结账页的完美副本上。他们输入的每个密码和卡号都直接进了犯罪分子手里。你只在退单和我是被你网站黑的电话开始时才听说——而线索通向的是你的品牌，不是攻击者的。
• **悄无声息的邮件拦截。**DNS 不只指向你的网站；它也指向你的邮件服务器。伪造那个答复，入站邮件就能被先改道经过一个攻击者。他们读取敏感消息、收割那些为验证是你本人而由服务发送的一次性验证码，并在与你域名相关的账户上重置密码——全程从不登录你的邮箱。
• **你无法复现的故障。**这一种来自半成品的 DNSSEC 配置。公开封印（DS）摆在你的注册商处，但对应的密钥（DNSKEY）缺失或不对。在那些会校验 DNSSEC 的 ISP 和企业网络上的访客——而且这类网络逐年增多——干脆完全无法解析你的域名。对你和你的技术人员来说，网站和邮箱都好好的，但一部分真实客户却收到此站点无法访问，而你看不到任何错误。它恰恰因为从内部看不见，才是最难诊断的问题之一。
• **丢掉的交易。**潜在客户的安全或采购团队对你的域名做一次例行的签约前扫描。无 DNSSEC 在 DNS 安全基础上显示为一个红点。对一个免费、被充分理解的控制项来说，它的缺失读作疏忽——足以悄悄让你丢掉一份你都不知道已陷入危机的合同。
• **你连资格都没有的招标。**法规和买家清单越来越把 DNSSEC 列为期望的基线安全卫生（它在 NIS2 的 DNS 安全条款下被提及）。较大的 B2B 和公共部门买家可能在销售对话开始前就把你筛掉，仅仅因为这个框没打勾。

它实际上是什么

DNSSEC 以一条信任链的方式工作，它有两个必须彼此吻合的活动部件。这正是我们的检查要查两样东西的核心原因。

**DNSKEY——你的密钥。**你的 DNS 提供商持有一把加密密钥，并用它给你的 DNS 记录签名。那把密钥的公开半被发布为一条 DNSKEY 记录。把它想成握在你这一端的封印图章。

**DS 记录——为密钥背书的指纹。**那把密钥的一段简短指纹，叫 DS（委派签名，Delegation Signer）记录，被发布在上一级——在你域名的注册局处，经由你的注册商。这正是让互联网其余部分信任你密钥的东西：每一级为下一级背书，一路向上直到互联网的根。DS 就是那枚封印被正式登记，好让其他所有人都能认出它。

要让 DNSSEC 真正保护你，两者都必须存在、且必须匹配：

• **DS 存在 + DNSKEY 存在且匹配 → 良好。**信任链完整。伪造的答复被拒，正当的被验证通过。这是通过状态。
• **无 DS（也无 DNSKEY）→ DNSSEC 干脆就没开。**你没有防护，但什么也没坏。这是最常见的尚未做状态。（在我们的评分里，这是 DS 检查记你不利的地方；而组合密钥检查把一个干净、完全关闭的状态当作提示性、而非硬性失败，因为没有任何东西正在主动坏掉。）
• **DS 存在，但 DNSKEY 缺失或不匹配 → 坏了，比关着更糟。**互联网看到一枚已发布的封印，却指向一把并不存在的密钥。会校验的解析器据此判定你的域名已被篡改，并拒绝解析它——造成上面描述的间歇性故障。这是最紧急要修的状态，我们的检查把它标为高严重级。
• **DNSKEY 存在，但注册商处无 DS → 已开启但未激活。**你的记录已签名，但因为指纹从未在上一级登记，互联网其余部分无从信任它们。你做了功、却没有防护。修复办法是在你的注册商处添加 DS 记录。

一句话概括良好的状态：你注册商处有一条 DS 记录，其指纹与你 DNS 提供商处一把在线的 DNSKEY 匹配，两者都经一次快速查询确认。

如何修复（免费，约 10–30 分钟）

**把这一节交给管理你域名或网站的人。**在大多数提供商那里修复本身免费——唯一的代价是仔细操作，让两半保持同步。只有当你之后想让我们监控它是否一直正确开启时，我们才收费。

黄金法则：**先启用签名（这会创建 DNSKEY），再在注册商处发布 DS 记录——绝不反过来，也绝不只做其一而缺另一。**在密钥存在之前就发布 DS，正是导致故障的原因。

简单路径（推荐——Cloudflare）：

1. 在 Cloudflare 里，确认确实由 Cloudflare 运行你的 DNS（你的域名服务器指向 Cloudflare）。
2. 进入 DNS → Settings → DNSSEC → Enable DNSSEC。Cloudflare 替你生成并管理密钥（这会自动创建 DNSKEY 那一半）。
3. Cloudflare 会向你显示要在注册商处发布的 DS 记录详情。
4. 登录你的域名注册商（如 GoDaddy、Namecheap、OVH），找到 DNSSEC 区域。把 Cloudflare 给你的 DS 值粘进去。
5. 等待 24–48 小时完全传播。你的网站和邮箱全程照常工作。

其他 DNS 提供商（AWS Route 53、你的 Web 主机等）：

1. 在你 DNS 提供商的控制面板里，启用 DNSSEC / 给此区域签名。这会生成签名密钥并发布 DNSKEY 记录。
2. 复制提供商产生的 DS 记录。
3. 在你的注册商的 DNSSEC 设置下，添加那条 DS 记录。
4. 确认注册商已接受它，并等待传播。

平台说明：

• Cloudflare——一键启用，再在注册商处粘贴一次 DS。迄今最简单的路子。
• AWS Route 53——在托管区域上启用 DNSSEC 签名，然后在你域名的注册商处添加 DS 记录（如果域名注册在 Route 53，AWS 可以替你关联）。
• Microsoft 365 / Google Workspace——这些运行的是你的邮箱，通常不是你的 DNS 区域。DNSSEC 在你 DNS 记录实际所在的地方启用（往往是你的注册商、主机或 Cloudflare），而不是在 365/Workspace 的管理中心。
• **你的 DNS 提供商根本不支持 DNSSEC？**这在较老或低价的主机上很常见。干净的修复办法是把 DNS 管理迁到一个支持它的提供商（Cloudflare 免费），然后按上面的简单路径走。迁移 DNS 不需要迁移你的网站或邮箱。

验证它确实生效：

• 运行 dig DS yourdomain.com 和 dig DNSKEY yourdomain.com——两者都应返回记录。
• 或用任意免费的在线 DNSSEC 检查器，确认一条绿色/有效的信任链。
• 在两者都返回匹配记录之前，别当它做完了。有 DS 而无 DNSKEY 正是那个坏掉的状态——立即修复或移除它。

常见错误

• **在密钥存在之前就发布 DS。**最具破坏力的单一错误：在 DNS 提供商处签名真正生效之前，就在注册商处添加了 DS 记录。这造成了已发布封印、缺失密钥的状态，使你的域名对会校验 DNSSEC 的访客无法解析。永远先启用签名，再发布 DS。
• **换提供商后留下一条过时的 DS。**如果你迁移 DNS 提供商（或关闭签名）却忘了在注册商处移除或更新旧的 DS 记录，你就指向了一把不再存在的密钥——同样的坏结果。当你关闭或迁移 DNSSEC 时，在同一次改动中把注册商处的 DS 一并更新。
• **做完第一步就停。**在 DNS 提供商处启用签名（创建了 DNSKEY），却从未在注册商处添加 DS。在 DNS 仪表盘里一切看上去都开着，但没有 DS，防护永远不激活。你做了功，却一点好处都没拿到。
• **以为 HTTPS 或邮件认证已经覆盖了它。**小锁和邮件认证（SPF / DKIM / DMARC）很有价值，但解决的是不同的问题。它们都阻止不了一个伪造的 DNS 答复一开始就把访客送往错误的地方。
• **启用后不监控。**密钥会轮换，提供商会变更，记录会被编辑。今天完美的配置，几个月后可能悄悄坏掉。如果 DNSSEC 重要到值得启用，就值得定期检查它是否仍然有效。

它在你评分中的位置

这两项检查都计入你的 DNS 安全得分。DS 记录检查被当作两者中优先级更高的那个：缺失的 DS 是一个真实的漏洞，被算作失败。DNSKEY检查确认信任链的其余部分完好——只有当一条匹配的 DS和 DNSKEY 都存在时它才通过，并把那个危险的有 DS 无密钥坏掉状态标为高严重级。一个干净的 DNSSEC 干脆还没启用结果，是许多企业常见的起点；从那里走到一对完整、匹配的 DS + DNSKEY，是一次免费、被充分理解的升级，它提升你的 DNS 安全地位，并消除一条真实的冒充与拦截通道。

在您的托管服务商上完成设置

热门服务商的分步指引：

• 在 GoDaddy 上设置 DNSSEC
• 在 Namecheap 上设置 DNSSEC
• 在 Cloudflare 上设置 DNSSEC
• 在 AWS Route 53 上设置 DNSSEC

常见问题