本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 在 Amazon Route 53 中配置 DNSSEC 签名 域名系统安全扩展 (DNSSEC) 签名允许 DNS 解析程序验证来自 Amazon Route 53 且未被篡改的 DNS 响应。使用 DNSSEC 签名时，托管区域的每个响应都使用公有密钥加密技术进行签名。有关 DNSSEC 的概述，请参阅 [AWS re:Invent 2021 - Amazon Route 53：年度回顾](https://www.youtube.com/watch?v=77V23phAaAE)中的 DNSSEC 部分。 在本章中，我们将说明如何为 Route 53 启用 DNSSEC 签名、如何使用密钥签名密钥 (KSKs) 以及如何解决问题。您可以使用 DNSSEC 登录 AWS 管理控制台 或以编程方式使用 API。有关使用 CLI 或使用 Rou SDKs te 53 的更多信息，请参阅[设置 Amazon Route 53](setting-up-route-53.md)。 在启用 DNSSEC 签名之前，请注意以下事项： + 为了帮助防止区域中断并避免域变得不可用的问题，您必须快速解决和处理 DNSSEC 错误。我们强烈建议您设置 CloudWatch 警报，在检测到`DNSSECInternalFailure`或`DNSSECKeySigningKeysNeedingAction`错误时提醒您。有关更多信息，请参阅 [使用 Amazon 监控托管区域 CloudWatch](monitoring-hosted-zones-with-cloudwatch.md)。 + DNSSEC 中有两种密钥：密钥签名密钥 (KSK) 和区域签名密钥 (ZSK)。在 Route 53 DNSSEC 签名中，每个 KSK 都基于您拥有的 AWS KMS 中的[非对称客户托管密钥](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#asymmetric-keys-concept)。您负责 KSK 管理，其中包括根据需要进行轮换。ZSK 管理由 Route 53 执行。 + 当您为托管区域启用 DNSSEC 签名时，Route 53 将 TTL 限制为一周。如果您为托管区域中的记录设置了一周以上的 TTL，则不会出现错误。但是，Route 53 对记录强制执行一周的 TTL。TTL 少于一周的记录和其它托管区域中未启用 DNSSEC 签名的记录不受影响。 + 当您使用 DNSSEC 签名时，不支持多供应商配置。如果您配置了白标域名称服务器（也称为虚名称服务器或私有名称服务器），请确保这些名称服务器由单一 DNS 提供商提供。 + 某些 DNS 提供商在其权威 DNS 中不支持委派签名者（DS）记录。如果您的父区域由不支持 DS 查询（未在 DS 查询响应中设置 AA 标志）的 DNS 提供商托管，则当您在其子区域中启用 DNSSEC 时，子区域将变得无法解析。确保您的 DNS 提供商支持 DS 记录。 + 设置 IAM 权限以允许除区域拥有者之外的其他用户添加或删除区域中的记录非常有用。例如，区域拥有可以添加 KSK 并启用签名，还可能负责密钥转动。但是，其他人可能负责使用托管区域的其它记录。有关 IAM policy 示例，请参阅 [域记录所有者的权限示例](access-control-managing-permissions.md#example-permissions-record-owner)。 + 要查看该顶级域是否支持 DNSSEC，请参阅 [可向 Amazon Route 53 注册的域。](registrar-tld-list.md)。 **Topics** + [启用 DNSSEC 签名并建立信任链。](dns-configuring-dnssec-enable-signing.md) + [禁用 DNSSEC 签名](dns-configuring-dnssec-disable.md) + [使用适用于 DNSSEC 的客户托管密钥](dns-configuring-dnssec-cmk-requirements.md) + [使用密钥签名密钥 () KSKs](dns-configuring-dnssec-ksk.md) + [Route 53 中的 KMS 密钥和 ZSK 管理](dns-configuring-dnssec-zsk-management.md) + [Route 53 中的 DNSSEC 不存在证明](dns-configuring-dnssec-proof-of-nonexistence.md) + [DNSSEC 签名的问题排查](dns-configuring-dnssec-troubleshoot.md) # 启用 DNSSEC 签名并建立信任链。 **** 递增步骤适用于托管区域拥有者和父区域维护者。这二者可以是同一个人，但如果不是，区域拥有者应该通知父区域维护者并与其合作。 我们建议按照本文中的步骤对区域进行签名并将其纳入信任链中。以下步骤将最大限度地降低启用 DNSSEC 所存在的风险。 **注意** 在 [在 Amazon Route 53 中配置 DNSSEC 签名](dns-configuring-dnssec.md) 中开始之前，请务必阅读先决条件。 启用 DNSSEC 签名需要执行三个步骤，如以下几节所述。 **Topics** + [步骤 1：准备启用 DNSSEC 签名](#dns-configuring-dnssec-enable-signing-step-1) + [步骤 2：启用 DNSSEC 签名并创建 KSK](#dns-configuring-dnssec-enable) + [步骤 3：建立信任链](#dns-configuring-dnssec-chain-of-trust) ## 步骤 1：准备启用 DNSSEC 签名 准备步骤可通过监控区域可用性并减少启用签名与插入委派签名者 (DS) 记录之间的等待时间，帮助您最大限度地降低启用 DNSSEC 所存在的风险。 **准备启用 DNSSEC 签名** 1. 监控区域可用性。 您可以监控区域以了解域名的可用性。这可以帮助您在启用 DNSSEC 签名后解决可能需要回滚的任何问题。您可以使用查询日志记录来监控流量最多的域名。有关设置查询日志记录的更多信息，请参阅 [监控 Amazon Route 53](monitoring-overview.md)。 可以通过 Shell 脚本或第三方服务来完成监控。但是，其不应作为确定是否需要回滚的唯一信号。由于域名不可用，您也可能会从客户处获得反馈。 1. 降低区域的最大 TTL。 区域的最大 TTL 是该区域中最长的 TTL 记录。在以下示例区域中，区域的最大 TTL 为 1 天（86400 秒）。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html) 降低区域的最大 TTL 将有助于缩短启用签名与插入委派签名者 (DS) 记录之间的等待时间。我们建议将区域的最大 TTL 降低到 1 小时（3600 秒）。如果任何解析程序在缓存已签名记录时遇到问题，您可以在一个小时后回滚。 **回滚：**撤消 TTL 更改。 1. 降低 SOA TTL 和 SOA 最小字段。 SOA 最小字段是 SOA 记录数据中的最后一个字段。在以下 SOA 记录示例中，最小字段的值为 5 分钟（300 秒）。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html) SOA TTL 和 SOA 最小字段决定了解析程序记住否定回答的时长。启用签名后，Route 53 名称服务器开始返回否定回答的 NSEC 记录。NSEC 包含解析程序可能用来综合否定回答的信息。如果由于 NSEC 信息导致解析程序对姓名假定否定回答而必须回滚，那么您只需等待 SOA TTL 和 SOA 最小字段的最大值，解析程序就会停止假定。 **回滚：**撤消 SOA 更改。 1. 确保 TTL 和 SOA 最小字段更改有效。 用于确保您[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)到目前为止所做的更改已传播到所有 Route 53 DNS 服务器。 ## 步骤 2：启用 DNSSEC 签名并创建 KSK 您可以在 Route 53 控制台上使用 AWS CLI 或启用 DNSSEC 签名并创建密钥签名密钥 (KSK)。 + [CLI](#dnssec_CLI) + [控制台](#dnssec_console) 当您提供或创建 KMS 密钥时，应遵循以下几个要求。有关更多信息，请参阅 [使用适用于 DNSSEC 的客户托管密钥](dns-configuring-dnssec-cmk-requirements.md)。 ------ #### [ CLI ] 您可以使用已有密钥，或通过使用自己的 `hostedzone_id`、`cmk_arn`、`ksk_name` 和 `unique_string` 值运行如下 AWS CLI 命令来创建密钥（以确保请求是唯一的）： ``` aws --region us-east-1 route53 create-key-signing-key \ --hosted-zone-id $hostedzone_id \ --key-management-service-arn $cmk_arn --name $ksk_name \ --status ACTIVE \ --caller-reference $unique_string ``` 有关客户托管式密钥的更多信息，请参阅 [使用适用于 DNSSEC 的客户托管密钥](dns-configuring-dnssec-cmk-requirements.md)。另请参阅[CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html)。 要启用 DNSSEC 签名，请使用您自己的值运行如下 AWS CLI 命令：`hostedzone_id` ``` aws --region us-east-1 route53 enable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id ``` 有关更多信息，请参阅[enable-hosted-zone-dnssec](https://docs.aws.amazon.com/cli/latest/reference/route53/enable-hosted-zone-dnssec.html)和 [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)。 ------ #### [ Console ] **要启用 DNSSEC 签名并创建 KSK** 1. 登录 AWS 管理控制台 并打开 Route 53 控制台，网址为[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)。 1. 在导航窗格中，选择 **Hosted zones**（托管区域），然后选择您要为其启用 DNSSEC 签名的托管区域。 1. 在 **DNSSEC signing**（DNSSEC 签名）选项卡上，选择 **Enable DNSSEC signing**（启用 DNSSEC 签名）。 **注意** 如果本部分中的选项为 **Disable DNSSEC signing**（禁用 DNSSEC 签名），则表示您已完成启用 DNSSEC 签名的第一步。请确保您为 DNSSEC 的托管区域建立了信任链，或者此区域已经存在信任链，然后您便完成了操作。有关更多信息，请参阅 [步骤 3：建立信任链](#dns-configuring-dnssec-chain-of-trust)。 1. 在 **Key-signing key (KSK) creation**（密钥签名密钥 (KSK) 创建）部分，选择 **Create new KSK**（创建新的 KSK），并在 **Provide KSK name**（提供 KSK 名称）下输入 Route 53 将为您创建的 KSK 名称。名称只能包含字母、数字和下划线 (\$1)。此名称必须唯一。 1. 在 **Customer managed CMK**（客户托管 CMK）中，选择 Route 53 在为您创建 KSK 时要使用的客户管理密钥。您可以使用适用于 DNSSEC 签名的现有客户托管密钥，也可以创建新的客户托管密钥。 当您提供或创建客户托管密钥时，有几个要求。有关更多信息，请参阅 [使用适用于 DNSSEC 的客户托管密钥](dns-configuring-dnssec-cmk-requirements.md)。 1. 输入现有客户托管密钥的别名。如果要使用新的客户托管式密钥，请输入客户托管密钥的别名，Route 53 将为您创建密钥。 **注意** 如果您选择让 Route 53 创建客户托管密钥，请注意，每个客户托管密钥都会单独收取费用。有关更多信息，请参阅 [AWS 密钥管理服务定价](https://aws.amazon.com/kms/pricing/)。 1. 选择 **Enable DNSSEC signing**（启用 DNSSEC 签名）。 ------ **启用区域签名后，请完成以下步骤**（无论是使用控制台还是 CLI）： 1. 确保区域签名有效。 如果你使用了 AWS CLI，你可以使用`EnableHostedZoneDNSSEC()`调用输出中的操作 ID 来运行 [get-change](https://docs.aws.amazon.com/cli/latest/reference/route53/get-change.html) 或[GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)确保所有 Route 53 DNS 服务器都在签署响应（status =`INSYNC`）。 1. 至少等待前一个区域的最大 TTL 的时长。 等待解析程序清除其缓存中的所有未签名记录。为此，等待时长至少应为前一个区域的最大 TTL。在上面的 `example.com` 区域，等待时间为 1 天。 1. 监控客户问题报告。 启用区域签名后，客户可能会开始看到与网络设备和解析程序相关的问题。建议的监控周期为 2 周。 下面是可能会看到的问题示例： + 某些网络设备可以将 DNS 响应大小限制在 512 字节以下，这对于某些签名响应来说太小。应重新配置这些网络设备，以便允许更大的 DNS 响应。 + 一些网络设备对 DNS 响应进行深入检查并删除其无法理解的某些记录，如用于 DNSSEC 的记录。应该重新配置这些设备。 + 一些客户的解析程序称可以接受比其网络支持的响应大小更大的 UDP 响应。您可以测试网络功能并适当配置解析程序。有关更多信息，请参阅 [DNS 回复大小测试服务器](https://www.dns-oarc.net/oarc/services/replysizetest/)。 **回滚：**调用 [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)，然后回滚中的步骤。[步骤 1：准备启用 DNSSEC 签名](#dns-configuring-dnssec-enable-signing-step-1) ## 步骤 3：建立信任链 在 Route 53 中为托管区域启用 DNSSEC 签名后，请为托管区域建立信任链，以完成 DNSSEC 签名设置。您可以通过在*父*托管区域创建 Delegation Signer (DS) 记录，并使用 Route 53 提供的信息，以完成此操作。根据域注册的位置，您可以将记录添加到 Route 53 中的父托管区域或其它域注册商。 **要建立 DNSSEC 签名信任链。** 1. 登录 AWS 管理控制台 并打开 Route 53 控制台，网址为[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)。 1. 在导航窗格中，选择 **Hosted zones**（托管区域），然后选择要为其建立 DNSSEC 信任链的托管区域。*您必须首先启用 DNSSEC 签名。* 1. 在 **DNSSEC signing**（DNSSEC 签名）选项卡，在 **DNSSEC signing**（DNSSEC 签名）中，选择 **View information to create DS record**（查看信息以创建 DS 记录）。 **注意** 如果您没有在本部分中看到 **View information to create DS record**（查看信息以创建 DS 记录），那么在建立信任链之前，必须启用 DNSSEC 签名。选择 **Enable DNSSEC signing**（启用 DNSSEC 签名）并完成 [步骤 2：启用 DNSSEC 签名并创建 KSK](#dns-configuring-dnssec-enable) 中的所述步骤，然后回到这些步骤建立信任链。 1. 在 **Establish a chain of trust**（建立信任链）中，选择 **Route 53 registrar**（Route 53 注册商）或者 **Another domain registrar**（另一域注册商），具体取决于您的域注册位置。 1. 使用步骤 3 提供的值以在 Route 53 中为父托管区域创建 DS 记录。如果您的域未托管在 Route 53，请使用提供的值在域注册商网站上创建 DS 记录。 要建立父区域的信任链： + 如果通过 Route 53 管理您的域，请执行以下步骤： 确保配置正确的签名算法（ECDSAP256SHA256 以及类型 13）和摘要算法（SHA-256 和类型 2）。 如果 Route 53 是您的注册商，请在 Route 53 控制台中执行以下操作： 1. 请注意 **Key type**（密钥类型）、**Signing algorithm**（签名算法）和 **Public key**（公有密钥）的值。在导航窗格中，选择 **Registered domains**。 1. 选择一个域，然后在 **DNSSEC 密钥**选项卡中选择**添加密钥**。 1. 在**管理 DNSSEC 密钥**对话框中，从下拉菜单中为 **Route 53 注册商**选择适当的**密钥类型**和**算法**。 1. 为 Route 53 注册商复制 **Public key**（公有密钥）。在 **Manage DNSSEC keys**（管理 DNSSEC 密钥）对话框中，将值粘贴到 **Public key**（公有密钥）框中。 1. 选择**添加**。 Route 53 会将 DS 记录从公有密钥添加到父区域。例如，如果您的域是 `example.com`，则 DS 记录会添加到 .com DNS 区域。 + 如果您的域托管在其他注册机构处，请按照**其他域名注册商**部分中的说明进行操作。 为确保以下步骤顺利进行，请将低 DS TTL 引入父区域。如果您需要回滚更改，我们建议将 DS TTL 设置为 5 分钟（300 秒）以加快恢复速度。 + 要建立子区域的信任链： 如果您的父区域由其他注册表管理，请联系注册商以引入区域的 DS 记录。通常无法调整 DS 记录的 TTL。 + 如果您的父区域托管在 Route 53 上，请联系父区域拥有者以引入区域的 DS 记录。 将 `$ds_record_value` 提供给父区域拥有者。您可以通过单击 “**查看信息” 在控制台中创建 DS 记录**并复制 D **S 记录**字段，或者调用 [getDNSSec](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetDNSSEC.html) API 并检索 “” 字段的值来获取它：DSRecord ``` aws --region us-east-1 route53 get-dnssec --hosted-zone-id $hostedzone_id ``` 父区域拥有者可以通过 Route 53 控制台或 CLI 插入记录。 + 要使用插入 DS 记录 AWS CLI，父区域所有者创建并命名了一个类似于以下示例的 JSON 文件。父区域拥有者可能会将文件命名为 `inserting_ds.json`。 ``` { "HostedZoneId": "$parent_zone_id", "ChangeBatch": { "Comment": "Inserting DS for zone $zone_name", "Changes": [ { "Action": "UPSERT", "ResourceRecordSet": { "Name": "$zone_name", "Type": "DS", "TTL": 300, "ResourceRecords": [ { "Value": "$ds_record_value" } ] } } ] } } ``` 然后运行以下命令： ``` aws --region us-east-1 route53 change-resource-record-sets --cli-input-json file://inserting_ds.json ``` + 要使用控制台插入 DS 记录， 打开 Route 53 控制台，网址为[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)。 在导航窗格中，选择 **Hosted zones**（托管区域）、托管区域的名称，然后选择 **Create record**（创建记录）按钮。确保为 **Routing policy**（路由策略）选择简单路由。 在**记录名称**字段中输入与 `$zone_name` 相同的名称，从**记录类型**下拉菜单中选择 DS，并在**值**字段中输入 `$ds_record_value` 的值，然后选择**创建记录**。 **回滚：**从父区域中删除 DS，等待 DS TTL，然后回滚建立信任的步骤。如果父区域托管在 Route 53 上，父区域拥有者可以将 JSON 文件中的 `Action` 从 `UPSERT` 更改为 `DELETE`，然后重新运行上面的示例 CLI。 1. 等待更新传播，具体基于域记录的 TTL。 如果父区域使用的是 Route 53 DNS 服务，则父区域所有者可以通过 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API 确认完全传播。 否则，您可以定期检查 DS 记录的父区域，然后再等 10 分钟，以提高完整传播 DS 记录插入的可能性。请注意，一些注册商计划了 DS 插入，例如，每天一次。 在父区域中引入委派签名者 (DS) 记录时，已获取 DS 的经验证的解析程序将开始验证来自该区域的响应。 为了确保建立信任的步骤顺利进行，请完成以下操作： 1. 找到最大 NS TTL。 有 2 组 NS 记录与您的区域相关： + 委托 NS 记录 — 这是由父区域持有的您的区域的 NS 记录。您可以通过运行如下 Unix 命令找到此记录（如果区域为 example.com，则父区域为 com）： `dig -t NS com` 选择一个 NS 记录，然后运行以下命令： `dig @one of the NS records of your parent zone -t NS example.com` 例如： `dig @b.gtld-servers.net. -t NS example.com` + 区内 NS 记录 — 这是您的区域中的 NS 记录。您可以通过运行以下 Unix 命令找到此记录： `dig @one of the NS records of your zone -t NS example.com` 例如： `dig @ns-0000.awsdns-00.co.uk. -t NS example.com` 请注意两个区域的最大 TTL。 1. 等待最大 NS TTL。 在 DS 插入之前，解析程序获得签名响应，但未验证签名。插入 DS 记录后，在区域的 NS 记录到期之前，解析程序无法看到该记录。当解析程序重新获取 NS 记录时，也将会返回 DS 记录。 如果您的客户在时钟不同步的主机上运行解析程序，请确保时钟与正确时间相差 1 小时以内。 完成此步骤后，所有 DNSSEC 感知解析程序将会验证您的区域。 1. 注意名称解析。 应注意解析程序验证您的区域时没有出现问题。确保同时考虑到客户向您报告问题所需的时间。 我们建议监控最长 2 周时间。 1. （可选）加长 DS 和 N TTLs S 的长度。 如果对设置满意，可以保存所做的 TTL 和 SOA 更改。请注意，Route 53 将已签名区域的 TTL 限制为 1 周。有关更多信息，请参阅 [在 Amazon Route 53 中配置 DNSSEC 签名](dns-configuring-dnssec.md)。 如果您可以更改 DS TTL，建议将其设置为 1 小时。 # 禁用 DNSSEC 签名 在 Route 53 中禁用 DNSSEC 签名的步骤有所不同，具体取决于托管区域所属的信任链。 例如，您的托管区域可能具有包含 Delegation Signer (DS) 记录的父区域，作为信任链的一部分。托管区域本身也可能是启用 DNSSEC 签名的子区域的父区域，这是信任链的另一部分。在执行禁用 DNSSEC 签名的步骤之前，请调查并确定托管区域的完整信任链。 在禁用签名时，必须仔细撤消托管区域启用 DNSSEC 签名的信任链。要从信任链中删除托管区域，请删除包含此托管区域的信任链的所有 DS 记录。这意味着您必须按顺序执行以下操作： 1. 删除此托管区域对于属于信任链一部分的子区域具有的所有 DS 记录。 1. 从父区域删除 DS 记录。如果您具有信任岛（父区域中没有 DS 记录，此区域中的子区域没有 DS 记录），则可以跳过此步骤。 1. 如果无法删除 DS 记录，为了从信任链中删除该区域，请从父区域中删除 NS 记录。有关更多信息，请参阅 [为域添加或更改名称服务器和粘附记录](domain-name-servers-glue-records.md)。 通过以下递增步骤，您可以监控各个步骤的有效性，以避免区域中的 DNS 可用性问题。 **禁用 DNSSEC 签名** 1. 监控区域可用性。 您可以监控区域以了解域名的可用性。这可以帮助您在启用 DNSSEC 签名后解决可能需要回滚的任何问题。您可以使用查询日志记录来监控流量最多的域名。有关设置查询日志记录的更多信息，请参阅 [监控 Amazon Route 53](monitoring-overview.md)。 可以通过 Shell 脚本或付费服务完成监控。但是，其不应作为确定是否需要回滚的唯一信号。由于域名不可用，您也可能会从客户处获得反馈。 1. 查找当前 DS TTL。 您可以通过运行以下 Unix 命令找到 DS TTL： `dig -t DS example.com example.com` 1. 找到最大 NS TTL。 有 2 组 NS 记录与您的区域相关： + 委托 NS 记录 — 这是由父区域持有的您的区域的 NS 记录。您可以通过运行以下 Unix 命令找到此记录： 首先找到父区域的 NS（如果您的区域为 example.com，则父区域为 com）： `dig -t NS com` 选择一个 NS 记录，然后运行以下命令： `dig @one of the NS records of your parent zone -t NS example.com` 例如： `dig @b.gtld-servers.net. -t NS example.com` + 区内 NS 记录 — 这是您的区域中的 NS 记录。您可以通过运行以下 Unix 命令找到此记录： `dig @one of the NS records of your zone -t NS example.com` 例如： `dig @ns-0000.awsdns-00.co.uk. -t NS example.com` 请注意两个区域的最大 TTL。 1. 从父区域删除 DS 记录。 请与父区域拥有者联系以删除 DS 记录。 **回滚：**重新插入 DS 记录，确认 DS 插入有效，并等待最大 NS（而不是 DS TTL），然后所有解析程序将再次开始验证。 1. 确认删除 DS 是否有效。 如果父区域使用的是 Route 53 DNS 服务，则父区域所有者可以通过 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API 确认完全传播。 否则，您可以定期检查 DS 记录的父区域，然后再等 10 分钟，以提高完整传播 DS 记录删除的可能性。请注意，一些注册商计划了 DS 删除，例如，每天一次。 1. 等待 DS TTL。 等待直到所有解析程序缓存中的 DS 记录过期。 1. 禁用 DNSSEC 签名并停用密钥签名密钥 (KSK)。 + [CLI](#CLI_dnssec_disable) + [控制台](#console_dnssec_disable) ------ #### [ CLI ] 致电 [DisableHostedZoneDNSSEC 然后](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)。[DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) APIs 例如： ``` aws --region us-east-1 route53 disable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id aws --region us-east-1 route53 deactivate-key-signing-key \ --hosted-zone-id $hostedzone_id --name $ksk_name ``` ------ #### [ Console ] **禁用 DNSSEC 签名** 1. 登录 AWS 管理控制台 并打开 Route 53 控制台，网址为[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)。 1. 在导航窗格中，选择 **Hosted zones**（托管区域），然后选择您要为其禁用 DNSSEC 签名的托管区域。 1. 在 **DNSSEC signing**（DNSSEC 签名）选项卡上，选择 **Disable DNSSEC signing**（禁用 DNSSEC 签名）。 1. 在 **Disable DNSSEC signing**（禁用 DNSSEC 签名）的页面上，根据您要禁用 DNSSEC 签名的区域，选择以下任一选项。 + **仅限父区域** — 此区域具有带有 DS 记录的父区域。在这种情况下，您必须删除父区域的 DS 记录。 + **仅限子区域** — 此区域具有包含一个或多个子区域的信任链的 DS 记录。在这种情况下，您必须删除区域的 DS 记录。 + **父区域和子区域** — 此区域包含一个或多个子区域的信任链的 DS 记录*以及*具有 DS 记录的父区域。对于此场景，请执行以下操作： 1. 删除区域的 DS 记录。 1. 删除父区域的 DS 记录。 如果您具有信任岛，可跳过本步骤。 1. 确定您在步骤 4 中删除的每个 DS 记录的 TTL，请确保最长的 TTL 时间已过期。 1. 选中复选框以确认您已按顺序执行步骤。 1. 在字段中键入 *disable*，如图所示，然后选择 **Disable**（禁用）。 **停用密钥签名密钥 (KSK) 的步骤** 1. 登录 AWS 管理控制台 并打开 Route 53 控制台，网址为[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)。 1. 在导航窗格中，选择 **Hosted zones**（托管区域），然后选择您要为其停用密钥签名密钥的托管区域。 1. **在 “密**钥签名密钥” (KSKs)** 部分，选择要停用的 KSK，然后在 “**操作**” 下，选择 **“编辑 KSK”，将 KSK 状态设置为 “**非活动**”，然后选择 “****保存 KSK**”。** ------ **回滚：**呼叫[ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html)和 [EnableHostedZoneDN](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) APIs SSEC。 例如： ``` aws --region us-east-1 route53 activate-key-signing-key \ --hosted-zone-id $hostedzone_id --name $ksk_name aws --region us-east-1 route53 enable-hosted-zone-dnssec \ --hosted-zone-id $hostedzone_id ``` 1. 确认禁用区域签名是否有效。 使用`EnableHostedZoneDNSSEC()`呼叫中的 ID 进行运行 [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)，确保所有 Route 53 DNS 服务器都已停止对响应进行签名（状态 =`INSYNC`）。 1. 注意名称解析。 应注意解析程序验证您的区域时没有导致问题。还要考虑 1-2 周客户向您报告问题所需的时间。 1. （可选）清除。 如果您不想重新启用签名，则可以清 KSKs 理[DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)并删除相应的客户托管密钥以节省成本。 # 使用适用于 DNSSEC 的客户托管密钥 当您在 Amazon Route 53 中启用 DNSSEC 签名时，Route 53 会为您创建密钥签名密钥 (KSK)。要创建 KSK，Route 53 必须使用支持 DNSSEC AWS Key Management Service 的客户托管密钥。本节介绍了有关客户管理密钥的详细信息和要求，在您使用 DNSSEC 时能够有所帮助。 在使用适用于 DNSSEC 的客户托管密钥时，请牢记以下几点： + 与 DNSSEC 签名一起使用的客户托管密钥必须位于美国东部（弗吉尼亚北部）区域。 + 客户托管密钥必须是采用 [ECC\$1NIST\$1P256 密钥规格](https://docs.aws.amazon.com//kms/latest/developerguide/asymmetric-key-specs.html#key-spec-ecc)的[非对称客户托管密钥](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks)。这些客户托管密钥仅用于签名和验证。有关创建非对称客户托管密钥的帮助，请参阅 AWS Key Management Service 开发人员指南中的[创建非对称客户托管密钥](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-asymmetric-cmk)。要帮助查找现有客户托管密钥的加密配置，请参阅 AWS Key Management Service 开发人员[指南中的查看客户托管密钥的加密配置](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-crypto-config.html)。 + 如果您在 Route 53 中自行创建客户托管密钥以与 DNSSEC 一起使用，则必须包含特定的密钥策略语句，以便为 Route 53 提供所需的权限。Route 53 必须能够访问您的客户托管密钥，以便它可以为您创建 KSK。有关更多信息，请参阅 [DNSSEC 签名所需的 Route 53 客户托管密钥权限](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC)。 + Route 53 可以创建客户托管密钥供您使用 DNSSEC 签名，无需额外 AWS KMS 权限。 AWS KMS 但是，如果要在创建密钥后对其进行编辑，则必须具有特定的权限。您必须具有以下特定权限：`kms:UpdateKeyDescription`、`kms:UpdateAlias` 和 `kms:PutKeyPolicy`。 + 请注意，无论您是创建客户托管密钥还是让 Route 53 为您创建密钥，您拥有的每个客户托管密钥都会单独收取费用。有关更多信息，请参阅[AWS Key Management Service 定价](https://aws.amazon.com/kms/pricing/)。 # 使用密钥签名密钥 () KSKs 启用 DNSSEC 签名时，Route 53 会为您创建密钥签名密钥 (KSK)。在 Route 53 中， KSKs 每个托管区域最多可以有两个。启用 DNSSEC 签名后，您可以添加、删除或编辑您的。 KSKs 使用您的设备时，请注意以下几点 KSKs： + 在删除 KSK 之前，您必须编辑 KSK 以将其状态设置为 **Inactive**（非活动）。 + 当为托管区域启用 DNSSEC 签名时，Route 53 会将 TTL 限制为一周。如果将托管区域中记录的 TTL 设置为超过一周，则不会出现错误，但 Route 53 会强制执行一周的 TTL。 + 为了帮助防止区域中断并避免域变得不可用的问题，您必须快速解决和处理 DNSSEC 错误。我们强烈建议您设置 CloudWatch 警报，在检测到`DNSSECInternalFailure`或`DNSSECKeySigningKeysNeedingAction`错误时提醒您。有关更多信息，请参阅 [使用 Amazon 监控托管区域 CloudWatch](monitoring-hosted-zones-with-cloudwatch.md)。 + 本节中描述的 KSK 操作允许您轮换区域。 KSKs有关更多信息和 step-by-step示例，请参阅博客文章[使用 Amazon Route 53 配置 DNSSEC 签名和验证中的 DNSSEC](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/) *密钥轮换*。 要 KSKs 在中使用 AWS 管理控制台，请按照以下各节中的指导进行操作。 ## 添加密钥签名密钥 (KSK) 启用 DNSSEC 签名时，Route 53 会为您创建密钥签名密钥 (KSK)。您也可以 KSKs 单独添加。在 Route 53 中， KSKs 每个托管区域最多可以有两个。 创建 KSK 时，您必须提供或请求 Route 53 以创建用于 KSK 的客户托管密钥。当您提供或创建客户托管密钥时，有几个要求。有关更多信息，请参阅 [使用适用于 DNSSEC 的客户托管密钥](dns-configuring-dnssec-cmk-requirements.md)。 请按照以下步骤在 AWS 管理控制台中添加 KSK。 **要添加 KSK** 1. 登录 AWS 管理控制台 并打开 Route 53 控制台，网址为[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)。 1. 在导航窗格中，选择 **Hosted zones**（托管区域），然后选择一个托管区域。 1. **在 **DNSSEC 签名**选项卡的密**钥签名密钥 (KSKs)** 下，选择**切换到高级视图**，然后在**操作**下选择添加 KSK。** 1. 在 **KSK** 项下，输入 Route 53 将为您创建的 KSK 的名称。名称只能包含字母、数字和下划线 (\$1)。此名称必须唯一。 1. 输入适用于 DNSSEC 签名的客户托管密钥，或输入 Route 53 将为您创建的新客户托管密钥的别名。 **注意** 如果您选择让 Route 53 创建客户托管密钥，请注意，每个客户托管密钥都会单独收取费用。有关更多信息，请参阅[AWS Key Management Service 定价](https://aws.amazon.com/kms/pricing/)。 1. 选择 **Create KSK**（创建 KSK）。 ## 编辑密钥签名密钥 (KSK) 您可以将 KSK 的状态编辑为 **Active**（活动）或者 **Inactive**（非活动）。当 KSK 处于活动状态时，Route 53 将使用该 KSK 进行 DNSSEC 签名。在删除 KSK 之前，您必须编辑 KSK 以将其状态设置为 **Inactive**（非活动）。 按照以下步骤在 AWS 管理控制台中编辑 KSK。 **要编辑 KSK** 1. 登录 AWS 管理控制台 并打开 Route 53 控制台，网址为[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)。 1. 在导航窗格中，选择 **Hosted zones**（托管区域），然后选择一个托管区域。 1. **在 **DNSSEC 签名**选项卡的密**钥签名密钥 (KSKs)** 下，选择**切换到高级视图**，然后在**操作**下选择编辑 KSK。** 1. 对 KSK 进行所需的更新，然后选择 **Save**（保存）。 ## 删除密钥签名密钥 (KSK) 在删除 KSK 之前，您必须编辑 KSK 以将其状态设置为 **Inactive**（非活动）。 您可能删除 KSK 的原因之一是例行密钥转动的一部分。定期转动加密密钥是最佳实践。您的组织可能有关于转动密钥频率的标准指导。 请按照以下步骤在 AWS 管理控制台中删除 KSK。 **要删除 KSK** 1. 登录 AWS 管理控制台 并打开 Route 53 控制台，网址为[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)。 1. 在导航窗格中，选择 **Hosted zones**（托管区域），然后选择一个托管区域。 1. **在 **DNSSEC 签名**选项卡的密**钥签名密钥 (KSKs)** 下，选择**切换到高级视图**，然后在**操作**下选择删除 KSK。** 1. 按照指导确认删除 KSK。 # Route 53 中的 KMS 密钥和 ZSK 管理 本节介绍 Route 53 用于启用 DNSSEC 签名的区域的当前做法。 **注意** Route 53 将使用以下规则（可能更改）。未来的任何更改都不会降低您的区域或 Route 53 的安保状况。 **Route 53 如何使用与你的 KSK AWS KMS 关联的** 在 DNSSEC 中，KSK 用于为 DNSKEY 资源记录集生成资源记录签名（RRSIG)。所有这些`ACTIVE` KSKs 都用在 RRSIG 生成中。Route 53 通过在关联的 KMS 密钥上调用 `Sign` AWS KMS API 来生成 RRSIG。有关更多信息，请参阅 *AWS KMS API 参考指南*中的[签名](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html)。这些 RRSIGs不计入区域的资源记录集限制。 RRSIG 拥有过期期限。为防止过期，每隔一 RRSIGs 到 RRSIGs 七天对其进行一次再生，从而定期刷新。 每次您拨打 RRSIGs 以下任一电话时，也会刷新： APIs + [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html) + [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html) + [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) + [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html) + [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) + [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) 每次 Route 53 执行刷新时，我们都会生成 15 个刷新 RRSIGs 以覆盖接下来的几天，以防关联的 KMS 密钥无法访问。对于 KMS 密钥成本估算，您可以假设每天定期刷新一次。无意中对 KMS 密钥策略进行更改可能导致无法访问 KMS 密钥。无法访问的 KMS 密钥会将关联的 KSK 状态设置为 `ACTION_NEEDED`。我们强烈建议您在检测到`DNSSECKeySigningKeysNeedingAction`错误时通过设置 CloudWatch 警报来监控这种情况，因为验证解析器将在最后一个 RRSIG 到期后开始失败查找。有关更多信息，请参阅 [使用 Amazon 监控托管区域 CloudWatch](monitoring-hosted-zones-with-cloudwatch.md)。 **Route 53 如何管理区域的 ZSK** 每个启用 DNSSEC 签名的新托管区域都将有一个 `ACTIVE` 区域签名密钥（ZSK)。ZSK 是为每个托管区域单独生成的，为 Route 53 所有。当前的密钥算法是 ECDSAP256SHA256。 我们将在签名开启后的 7—30 天内开始在该区域进行定期 ZSK 转动。目前，Route 53 使用“发布前密钥滚动”方法。有关更多信息，请参阅[发布前区域签名密钥滚动](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.1)。这种方法将向该区域引入另一个 ZSK。转动将每 7-30 天重复一次。 如果该区域的任何一个 KSK `ACTION_NEEDED` 处于状态，Route 53 将暂停 ZSK 轮换，因为 Route 53 将无法重新生成 for DNSKEY 资源记录集以应对该区域 ZSK 的变化。 RRSIGs 清除条件后，ZSK 转动将自动恢复。 # Route 53 中的 DNSSEC 不存在证明 **注意** Route 53 将使用以下规则（可能更改）。未来的任何更改都不会降低您的区域或 Route 53 的安保状况。 DNSSEC 中有三种不存在证明： + 与查询名称匹配的记录的不存在证明。 + 与查询类型匹配的类型的不存在证明。 + 用于生成回应记录的通配符记录的存在证明。 Route 53 使用 BL 方法执行了与查询名称匹配的记录的不存在证明。有关更多信息，请参阅 [BL](https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00)。这是一种能够生成证明的紧凑表示法并防止区域步行的方式。 如果有记录与查询名称匹配但与查询类型不匹配（例如查询 web.example）。 com/AAAA but there is only web.example.com/Apresent），我们返回一个包含所有支持的资源记录类型的最小 NSEC（下一个安全）记录。 当 Route 53 从通配符记录中合成答案时，响应将不会附带通配符的下一条安全记录或 NSEC 记录。在某些实施过程（通常是执行离线签名）中会使用此类 NSEC 记录，以防止响应中的资源记录签名（RRRSIG）被重新使用来欺骗不同的响应。Route 53 对非 DNSKey 记录使用在线签名来生成 RRSIGs特定于该响应的响应，这些响应不能重复用于不同的响应。 # DNSSEC 签名的问题排查 本节中的信息可以帮助您解决 DNSSEC 签名问题，包括启用、禁用和密钥签名密钥 ()。KSKs 启用 DNSSEC 在开始启用 DNSSEC 签名之前，请确保已阅读 [在 Amazon Route 53 中配置 DNSSEC 签名](dns-configuring-dnssec.md) 中的先决条件。 禁用 DNSSEC 为了安全地禁用 DNSSEC，Route 53 将检查目标区域是否在信任链中。它检查目标区域的父区域是否有目标区域的任何 NS 记录和 DS 记录。如果目标区域无法公开解析，例如，在查询 NS 和 DS 时获得 SERVFAIL 响应，则 Route 53 无法确定禁用 DNSSEC 是否安全。您可以联系父区域来解决这些问题，并稍后重试禁用 DNSSEC。 KSK 状态为 **Action needed**（需要操作） 当 Route 53 DNSSEC 无法访问相应的（由于权限更改或`ACTION_NEEDED`删除）时，KSK 可以将其[KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)状态更改为 “**需要操作**” AWS KMS key （或 AWS KMS key 处于状态）。 如果 KSK 的状态是 **Action needed**（需要操作），这意味着最终会对使用 DNSSEC 验证解析程序的客户端造成区域中断，并且您必须迅速采取行动，防止生产区域变得无法解析。 要纠正此问题，请确保您的 KSK 所基于的客户托管式密钥已启用且具有正确的权限。有关所需权限的更多信息，请参阅 [DNSSEC 签名所需的 Route 53 客户托管密钥权限](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC)。 修复 KSK 后，使用控制台或（如所述）再次将其激活。 AWS CLI[步骤 2：启用 DNSSEC 签名并创建 KSK](dns-configuring-dnssec-enable-signing.md#dns-configuring-dnssec-enable) 为了防止将来出现此问题，请考虑按照中的建议添加一个 Amazon CloudWatch 指标来跟踪 KSK 的状态。[在 Amazon Route 53 中配置 DNSSEC 签名](dns-configuring-dnssec.md) KSK 状态为 **Internal failure**（内部故障） 当 KSK 的状态为**内部故障**（或处于[KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)状态）时，`INTERNAL_FAILURE`在问题得到解决之前，您无法使用任何其他 DNSSEC 实体。在使用 DNSSEC 签名（包括使用此 KSK 或其它 KSK）之前，您必须采取措施。 要更正问题，请重试激活或停用 KSK。 要在使用时更正问题 APIs，请尝试启用签名 ([EnableHostedZoneDNSSEC) 或禁用签名 ([DisableHostedZoneD](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) NSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html))。 重要的是要及时纠正 **Internal failure**（内部故障）这一问题。在解决问题之前，您无法对托管区域进行任何其它更改，除了为修复 **Internal failure**（内部故障）所进行的操作。