本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
启用DNSSEC签名并建立信任链
递增步骤适用于托管区域拥有者和父区域维护者。这二者可以是同一个人,但如果不是,区域拥有者应该通知父区域维护者并与其合作。
我们建议按照本文中的步骤对区域进行签名并将其纳入信任链中。以下步骤将最大限度地降低入DNSSEC职风险。
注意
在 在 Amazon Route 53 中配置DNSSEC登录 中开始之前,请务必阅读先决条件。
要启用DNSSEC签名,需要执行三个步骤,如以下各节所述。
步骤 1:为启用DNSSEC签名做好准备
准备步骤DNSSEC通过监控区域的可用性并缩短从启用签名到插入委托签名者 (DS) 记录之间的等待时间,帮助您最大限度地降低入职风险。
为启用DNSSEC签名做准备
-
监控区域可用性。
您可以监控区域以了解域名的可用性。这可以帮助您解决在启用DNSSEC签名后可能需要回退的任何问题。您可以使用查询日志记录来监控流量最多的域名。有关设置查询日志记录的更多信息,请参阅 监控 Amazon Route 53。
可以通过 Shell 脚本或第三方服务来完成监控。但是,其不应作为确定是否需要回滚的唯一信号。由于域名不可用,您也可能会从客户处获得反馈。
-
降低区域的最大值TTL。
该区域的最大值TTL是该区域中最长的TTL记录。在以下示例区域中,该区域的最大值TTL为 1 天(86400 秒)。
名称 TTL 记录类 记录类型 记录数据 example.com。
900
IN
SOA
ns1.example.com. hostmaster.example.com。2002022401 10800 15 604800 300
example.com。
900
IN
NS
ns1.example.com。
route53.example.com。
86400
IN
TXT
some txt record
降低区域的最大值TTL将有助于缩短从启用签名到插入委托签名者 (DS) 记录之间的等待时间。我们建议将该区域的最大值降低TTL到 1 小时(3600 秒)。如果任何解析程序在缓存已签名记录时遇到问题,您可以在一个小时后回滚。
回滚:撤消TTL更改。
-
降低SOATTL和SOA最小字段。
SOA最小字段是SOA记录数据中的最后一个字段。在以下示例SOA记录中,最小值字段的值为 5 分钟(300 秒)。
名称 TTL 记录类 记录类型 记录数据 example.com。
900
IN
SOA
ns1.example.com. hostmaster.example.com。2002022401 10800 15 604800 300
SOATTL和SOA最小值字段决定解析者记住否定答案的时间长度。启用签名后,Route 53 域名服务器开始返回否定答案的NSEC记录。NSEC包含解析器可能用来合成否定答案的信息。如果由于NSEC信息导致解析器假设名称的答案是否定而必须回滚,那么您只需要等待最大值和最小值字段的最大值SOATTL和SOA最小值字段即可让解析器停止假设。
回滚:撤消SOA更改。
-
确保TTL和SOA最小字段更改有效。
用于确保您GetChange到目前为止所做的更改已传播到所有 Rout DNS e 53 服务器。
第 2 步:启用DNSSEC签名并创建 KSK
您可以在 Route 53 控制台上使用 AWS CLI 或启用DNSSEC签名并创建密钥签名密钥 (KSK)。
当您提供或创建客户托管KMS密钥时,有几个要求。有关更多信息,请参阅 使用客户托管的密钥 DNSSEC。
启用区域签名后,请完成以下步骤(无论您使用的是控制台还是CLI):
-
确保区域签名有效。
如果您使用了 AWS CLI,则可以使用
EnableHostedZoneDNSSEC()
调用输出中的操作 ID 来运行 get-change 或GetChange确保所有 Route 53 DNS 服务器都在签署响应(status =INSYNC
)。 -
至少等待前一个区域的最大值TTL。
等待解析程序清除其缓存中的所有未签名记录。要实现这一点,你应该至少等待前一个区域的最大值TTL。在上面的
example.com
区域,等待时间为 1 天。 -
监控客户问题报告。
启用区域签名后,客户可能会开始看到与网络设备和解析程序相关的问题。建议的监控周期为 2 周。
下面是可能会看到的问题示例:
-
某些网络设备可以将DNS响应大小限制在 512 字节以下,对于某些已签名的响应来说,这太小了。应重新配置这些网络设备以允许更大的DNS响应大小。
-
一些网络设备会对DNS响应进行深入检查,并删除某些它不理解的记录,例如用于记录的记录DNSSEC。应该重新配置这些设备。
-
一些客户的解析人员声称,他们可以接受比其网络支持的更大的UDP响应。您可以测试网络功能并适当配置解析程序。有关更多信息,请参阅 “DNS回复大小测试服务器
”。
-
回滚:调用DisableHostedZoneDNSSEC然后回滚中的步骤。步骤 1:为启用DNSSEC签名做好准备
步骤 3:建立信任链
在 Route 53 中为托管区域启用DNSSEC签名后,请为托管区域建立信任链以完成DNSSEC签名设置。您可以通过在父托管区域创建 Delegation Signer (DS) 记录,并使用 Route 53 提供的信息,以完成此操作。根据域注册的位置,您可以将记录添加到 Route 53 中的父托管区域或其它域注册商。
建立用于DNSSEC签署的信任链
登录 AWS Management Console 并打开 Route 53 控制台,网址为https://console.aws.amazon.com/route53/
。 -
在导航窗格中,选择托管区域,然后选择要为其建立信任DNSSEC链的托管区域。必须先启用DNSSEC签名。
-
在 “DNSSEC签名” 选项卡上的 “DNSSEC签名” 下,选择 “查看信息” 以创建 DS 记录。
注意
如果您在本节中看不到用于创建 DS 记录的查看信息,则必须先启用DNSSEC签名,然后才能建立信任链。选择 “启用DNSSEC签名” 并完成中所述的步骤第 2 步:启用DNSSEC签名并创建 KSK,然后返回到这些步骤以建立信任链。
-
在 Establish a chain of trust(建立信任链)中,选择 Route 53 registrar(Route 53 注册商)或者 Another domain registrar(另一域注册商),具体取决于您的域注册位置。
-
使用步骤 3 提供的值以在 Route 53 中为父托管区域创建 DS 记录。如果您的域未托管在 Route 53,请使用提供的值在域注册商网站上创建 DS 记录。
要建立父区域的信任链:
-
如果通过 Route 53 管理您的域,请执行以下步骤:
确保配置正确的签名算法(ECDSAP256SHA256以及类型 13)和摘要算法(SHA-256 和类型 2)。
如果 Route 53 是您的注册商,请在 Route 53 控制台中执行以下操作:
-
请注意 Key type(密钥类型)、Signing algorithm(签名算法)和 Public key(公有密钥)的值。在导航窗格中,选择 Registered domains。
-
选择一个域,然后在DNSSEC状态旁边选择管理密钥。
-
在 “管理DNSSEC密钥” 对话框中,从下拉菜单中为 Route 53 注册商选择相应的密钥类型和算法。
-
为 Route 53 注册商复制 Public key(公有密钥)。在管理DNSSEC密钥对话框中,将值粘贴到公钥框中。
-
选择 添加。
Route 53 会将 DS 记录从公有密钥添加到父区域。例如,如果您的域名是
example.com
,则会将 DS 记录添加到.com DNS 区域。
-
-
如果您的域托管在其他注册机构处,请按照其他域名注册商部分中的说明进行操作。
为确保以下步骤顺利进行,请在父区域中引入低 DS TTL。如果您需要回滚更改,我们建议TTL将 DS 设置为 5 分钟(300 秒),以便更快地恢复。
-
要建立子区域的信任链:
如果您的父区域由其他注册表管理,请联系注册商以引入区域的 DS 记录。通常,您将无法调整 DS 记录的。TTL
-
如果您的父区域托管在 Route 53 上,请联系父区域拥有者以引入区域的 DS 记录。
将
$ds_record_value
提供给父区域拥有者。您可以通过单击 “查看信息” 在控制台中创建 DS 记录并复制 DS 记录字段,或者调用 Get DNSSEC 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/
。 在导航窗格中,选择 Hosted zones(托管区域)、托管区域的名称,然后选择 Create record(创建记录)按钮。确保为 Routing policy(路由策略)选择简单路由。
在 Record name(记录名称)字段中输入与
$zone_name
相同的名称,从 Record type(记录类型)下拉菜单中选择 DS,并在 Value(值)字段中输入$ds_record_value
的值,然后选择 Create records(创建记录)。
-
回滚:从父区域中删除 DS,等待 DSTTL,然后回滚建立信任的步骤。如果父区域托管在 Route 53 上,则父区域所有者可以在JSON文件
Action
DELETE
中UPSERT
将 from 更改为,然后重新运行CLI上面的示例。 -
-
根据您的域名记录,等待更新传播。TTL
如果父区域在 Route 53 DNS 服务上,则父区域所有者可以通过确认完全传播GetChangeAPI。
否则,您可以定期检查 DS 记录的父区域,然后再等 10 分钟,以提高完整传播 DS 记录插入的可能性。请注意,一些注册商计划了 DS 插入,例如,每天一次。
在父区域中引入委派签名者 (DS) 记录时,已获取 DS 的经验证的解析程序将开始验证来自该区域的响应。
为了确保建立信任的步骤顺利进行,请完成以下操作:
-
找出最大的 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的最大值。
-
-
等待最大 NS TTL。
在 DS 插入之前,解析程序获得签名响应,但未验证签名。插入 DS 记录后,在区域的 NS 记录到期之前,解析程序无法看到该记录。当解析程序重新获取 NS 记录时,也将会返回 DS 记录。
如果您的客户在时钟不同步的主机上运行解析程序,请确保时钟与正确时间相差 1 小时以内。
完成此步骤后,所有有DNSSEC意识的解析器都将验证您的区域。
-
注意名称解析。
应注意解析程序验证您的区域时没有出现问题。确保同时考虑到客户向您报告问题所需的时间。
我们建议监控最长 2 周时间。
-
(可选)加长 DS 和 N TTLs S 的长度。
如果您对设置感到满意,则可以保存TTL和所做的SOA更改。请注意,Route 53 TTL 将签名区域的有效期限制在 1 周以内。有关更多信息,请参阅 在 Amazon Route 53 中配置DNSSEC登录。
如果可以更改 DSTTL,我们建议将其设置为 1 小时。