如何在 AWS Route 53 上设置 DNSSEC

在 Route 53 中用 KMS 密钥启用 DNSSEC 签名，并在注册商处添加 DS 记录，让任何人都无法伪造你的 DNS 应答。

这对你的业务意味着什么

当有人访问你的网站或给你发邮件时，他们的电脑会先向 DNS 系统询问正确的地址。这些应答通常未经签名传输，因此能够篡改查询的攻击者可以悄悄把你的访客重定向到假冒网站，或把你的邮件改道到他自己的服务器上——而地址栏里始终显示着你真实的域名。

DNSSEC 能防止这一点。它用密码学方式为你的 DNS 应答签名，于是任何查询你的人都能证明应答确实来自你、且在途中未被改动。说得直白一点：它能挡住域名劫持和缓存投毒——这些正是把你自己的域名变成对付客户的武器的攻击。作为一项功能它本身免费（签名密钥会用到一个小型 AWS KMS 密钥，会产生少量月度费用），并且是你能开启的最强保护之一。

DNSSEC 在 Route 53 上的工作原理

Route 53 把这项工作做了一种值得在开始前理解清楚的拆分：

Route 53 用一个存放在 AWS KMS（Key Management Service，密钥管理服务）中的密钥为你的托管区域签名。开启签名会发布公钥（一条 DNSKEY）并生成一条 DS 记录。
接着，你的注册商——你为域名续费的那家公司——必须把那条 DS 记录发布到父级区域（例如 .com），让互联网的其余部分信任这些签名。

如果你的域名是通过 Route 53（Amazon Registrar）注册的，注册商这一步仍然必需，但可在 AWS 控制台内完成。如果你的注册商是另一家公司，你则需手动把 DS 记录复制过去。

真正的风险——请谨慎操作

配置错误时，DNSSEC 可能让你的整个域名下线。导致这种情况的两种方式：

注册商处的 DS 记录与 Route 53 实际签名所用的密钥不匹配。
在没有先于注册商处移除 DS 记录的情况下，就关闭签名、删除 KMS 密钥或把 DNS 迁离 Route 53——残留的 DS 记录会继续索要早已不存在的签名，导致查询失败。

请严格按下面的顺序操作。而且如果你要把 DNS 从 Route 53 迁走，请先在注册商处移除 DS 记录并关闭签名，再迁移。

先确认 Route 53 在为你解析 DNS

这只有在 Route 53 负责回应你域名的 DNS 时才有效。确认你域名的**域名服务器（nameservers）指向你托管区域（hosted zone）**所列的四个 Route 53 域名服务器。打开 Route 53 控制台，进入 Hosted zones，打开你的域名，记下 NS 记录的值——你注册商的域名服务器设置必须与这些一致。如果你的域名服务器指向别处，请到真正负责你 DNS 的服务商那里启用 DNSSEC。

Route 53 上的操作步骤

登录 AWS 控制台，打开 Route 53。
进入 Hosted zones，打开你域名的托管区域。
打开 DNSSEC signing 标签页，选择 Enable DNSSEC signing。
对于密钥签名密钥（key-signing key，KSK），你必须提供一个客户托管的 KMS 密钥：
- 选择 Create customer managed key（或选一个已有的合格密钥）。
- 该密钥必须是用途为 Sign and verify 的**非对称（asymmetric）**密钥，使用 ECC_NIST_P256 规格，并且必须位于 US East (N. Virginia) us-east-1 区域——Route 53 DNSSEC 要求密钥在该区域。
- 给这个 KSK 起个名字。
确认并启用签名（enable signing）。Route 53 现在会为托管区域签名。
仍在 DNSSEC signing 标签页，找到 DS record / Establish a chain of trust。Route 53 会显示你需要的值，包括 Key Tag、Signing algorithm、Digest algorithm 和 Digest（通常还有一条现成的 DS 记录行）。
现在前往你的注册商添加 DS 记录：
- 如果域名在 Route 53（Amazon Registrar）注册： 控制台可以在域名设置下引导你完成——或者把这些值复制到该域名的 DNSSEC 区域。
- 如果你的注册商是另一家公司： 打开它的 DNSSEC / DS 记录区域，把第 6 步的值原样填入——Key Tag、Algorithm（通常为 13）、Digest Type（通常为 2）和 Digest。
在注册商处保存。一旦 DS 记录被父级区域接受，信任链即告完成。

Route 53 上人们常踩的坑

KMS 密钥必须在 us-east-1。 Route 53 DNSSEC 不会接受来自其他区域的 KSK 密钥——这是最先把人绊倒的地方。
使用正确的密钥类型。 它必须是非对称、签名验证（sign-and-verify）、ECC_NIST_P256 的 KMS 密钥。对称或规格不对的密钥无法用作 KSK。
是两个系统，不是一个。 仅在 Route 53 里启用签名本身什么也不做——DS 记录还必须送达注册商。人们在第 5 步之后就停下，然后纳闷为什么它始终不通过验证。
原样复制 digest。 Digest 里哪怕错一个字符，注册商的 DS 记录就会与 Route 53 的签名密钥不匹配——而这正是导致域名下线的那种配置错误。请粘贴，绝不要手敲。
签名启用期间不要删除 KMS 密钥。 而且 Route 53 仍在签名时，绝不要移除注册商处的 DS 记录。
迁移 DNS 前按正确顺序关闭。 要迁走：先移除注册商处的 DS 记录，等它清除完毕，再在 Route 53 里关闭签名——不要反着来。
给它一点时间。 DNSSEC 变更完全传播并通过验证需要几分钟到一天不等。

验证是否生效

当 Route 53 中签名已启用、且注册商处 DS 记录已就位后，运行本站的免费检测。它会用通俗的语言告诉你 DNSSEC 是否已正确发布并对你的域名受信。

完成了？免费检查您的域名以确认设置已生效——并查看您在全部 34 项检查中的完整评级。