如何解决基于延迟的资源记录和 Route 53 的问题？

简短描述

如果以下情况属实，Route 53 会根据 DNS 查询的位置解析到延迟最低的区域：

• 您已将多个 AWS 区域中的端点与相同的资源记录相关联。
• 您使用的是基于延迟的路由策略。

Route 53 基于以下各项做出基于延迟的路由决策：

• 将查询发送到 Route 53 权威名称服务器的递归 DNS 解析器的源 IP 地址。
• 客户端 IP 地址的截断版本（如果 DNS 解析器支持扩展 edns00-client-subnet）。

Route 53 名称服务器默认支持 edns0-client-subnet。如果递归 DNS 解析器支持 edns0-client-subnet，则 DNS 解析器会向 Route 53 发送客户端 IP 地址的截断版本。然后，Route 53 使用该截断的 IP 地址来确定延迟最低的区域。

延迟最低的区域在物理上可能并不最接近 DNS 解析器。如果客户端与 DNS 解析器不在同一位置，您可能会遇到不需要的路由行为。如果解析器的 IP 地址具有不同的位置信息，您可能也会遇到不需要的路由行为。

示例场景

一家公司有两个弹性负载均衡器的基于延迟的路由记录，一个位于弗吉尼亚州 (us-east-1)，另一个位于爱尔兰 (eu-west-1)。美国的用户使用位于欧洲的公司 DNS 解析器，或者通过 VPN 连接到欧洲的公司办公室。

企业 DNS 解析器无法将 edns0-client-subnet 数据发送到权威名称服务器。因此，Route 53 将欧洲的 DNS 解析器 IP 地址视为查询的源。然后，Route 53 在其延迟数据库中执行查找，错误地认定爱尔兰的负载均衡器延迟最低。

如果企业 DNS 解析器可以发送 edns0-client-subnet 数据，则 Route 53 会将美国截断的客户端 IP 地址视为查询的源。然后，Route 53 在其延迟数据库中执行查找，并正确认定弗吉尼亚州的负载均衡器延迟最低。

解决方法

请按照以下步骤对不需要的基于延迟的路由行为进行故障排除：

1.检查 DNS 解析器使用的 IP 地址范围。在 Linux 和 macOS 上，循环运行 dig 命令。在 Windows 上，多次运行 nslookup 命令。请务必记下每次的输出。

在 Linux 或 macOS 上，循环运行 dig 命令。

for i in {1..10}; do dig TXT o-o.myaddr.l.google.com +short; sleep 61; done;

在 Windows 上，多次运行 nslookup 命令。请务必记下每次的输出。

nslookup -type=txt o-o.myaddr.l.google.com

2.通过上述命令的输出确认 DNS 解析器支持任播。如果输出始终包含相同的单个 IP 地址，则表示 DNS 解析器不支持任播。如果您多次运行命令时 IP 地址发生变化，则表示 DNS 解析器支持任播。

当 DNS 解析器支持任播时，DNS 解析器会有多个边缘站点。用户的边缘站点是根据最佳延迟选择的，这可能会导致解析器 IP 地址处于非预期位置。

3.找到客户端 IP 地址。在客户端计算机上，打开互联网浏览器，然后导航到 https://checkip.amazonaws.com/。

或者，使用 curl：

curl https://checkip.amazonaws.com/

4.使用以下命令之一检查 DNS 解析器是否支持 edns0-client-subnet。请务必记下输出。

在 Linux 或 macOS 上，请使用 dig：

dig +nocl TXT o-o.myaddr.l.google.com @<DNS Resolver>

在 Windows 上，请使用 nslookup：

nslookup -type=txt o-o.myaddr.l.google.com <DNS Resolver>

5.查看输出的 Answer 部分返回的第一条 TXT 记录。此值是最接近的公告任播的 DNS 服务器。如果没有第二条 TXT 记录，则表示 DNS 解析器不支持 edns0-client-subnet。如果有第二条 TXT 记录，则表示 DNS 解析器支持 edns0-client-subnet。解析器向 Route 53 权威名称服务器发送截断的客户端子网 IP 地址（/24 或 /32）。

（可选）如果您在托管区上启用了 Route 53 DNS 查询日志记录，则创建测试记录。对新记录执行 DNS 查找。查看查询日志，确认提供给 Route 53 名称服务器的解析器 IP 地址和 edns0-client-subnet（如果有）。

6.检查响应的 TTL 值是否为 60 秒。如果 TTL 不是 60 秒，则该响应是缓存的响应。重复 dig 或 nslookup 命令，直到响应 TTL 值为 60 秒。

7.如果您可以使用 Route 53 DNS 检查工具，则模拟来自特定 DNS 解析器或客户端 IP 地址的查询。请使用这些查询来查找 Route 53 返回的延迟资源记录集。

如果 DNS 解析器不支持 edns0-client-subnet，则在工具中指定解析器 IP 地址作为您的值。

如果 DNS 解析器支持 edns0-client-subnet，则在工具中指定 EDNS0 客户端子网 IP 作为您的值。选择其他配置，然后指定子网掩码。

**注意：**Route 53 DNS 检查工具会直接查询 Route 53 延迟测量数据库。该查询确定 AWS 区域与基于互联网的网络之间预先计算的延迟。该工具不通过互联网或向 DNS 解析器发送 DNS 查询。该工具不检查 DNS 解析器是否支持 edns0-client-subnet。该工具的结果和实际 DNS 查询的结果可能不同。

8.（可选）如果您无法使用 Route 53 DNS 检查工具，请使用 dig。使用 dig，通过 edns0-client-subnet 查询您的托管区的 Route 53 权威名称服务器。通过输出根据您的源 IP 地址确定延迟最低的区域。

dig lbr.example.com +subnet=<Client IP>/24 @ns-xx.awsdns-xxx.com +short

**注意：**由于网络连接和路由的变化，互联网上主机之间的延迟可能会随着时间的推移而变化。例如，本周发送到俄勒冈地区的请求可能会在下周路由到俄亥俄地区。

9.**对于不支持 edns0-client-subnet 的解析器：**将客户端的 DNS 解析器更改为地理位置更靠近客户端的其他递归 DNS 解析器。如果解析器不支持 edns0-client-subnet，则客户端 DNS 查询可能会使用地理位置与客户端不同的 DNS 解析器。这种情况下就会导致非预期的路由行为。

如果您管理 DNS 解析器，请检查转发配置。确认您未将 DNS 查询转发到距离客户地理位置更远的其他解析器。

**对于支持 edns0-client-subnet 的解析器：**检查客户端子网 IP 地址的地理位置。要检查位置，请使用 MaxMind 网站上的 GeoIP 数据库或您的首选 GeoIP 数据库。如果客户端子网 IP 地址的位置位于与客户端不同的地理位置，则您可能会遇到非预期的路由行为。

10.（可选）如果 DNS 解析器不支持 edns0-client-subnet，请切换到支持 edns0-client-subnet 的公共递归 DNS 解析器。然后，将来自 Route 53 的旧延迟路由响应结果与新结果进行比较。例如，当前支持 edns0-client-subnet 的两个公共 DNS 解析器是 GoogleDNS（8.8.8.8 和 8.8.4.4）和 OpenDNS（208.67.222.222 和 208.67.220.220）。

11.（可选）确定基于延迟的路由记录是否与 Route 53 运行状况检查相关联。并且，确定评估目标运行状况 (ETH) 是否已启用（用于别名记录）。如果至少满足其中一个条件，则 Route 53 会返回延迟最低、运行正常的端点。如果所有运行状况检查都失败，则仅考虑路由策略。

在 Route 53 控制台中查看 Route 53 运行状况检查的状态。如果 ETH 已启用，请检查记录端点的运行状况。如果至少一个后端实例运行正常，Route 53 会将启用了 ETH 的经典负载均衡器的端点视为运行正常。对于应用程序负载均衡器和网络负载均衡器，每个具有目标的目标组都必须包含至少一个运行正常的目标才能被视为运行正常。没有注册目标的目标组被视为运行不正常。如果任何目标组仅包含运行不正常的目标，则负载均衡器会被视为运行不正常。

**例外：**如果应用程序负载均衡器至少有一个运行正常的目标组，而其余所有目标组均为空，则 Route 53 认为其运行正常。

示例

您有两条基于延迟的路由记录与 Route 53 运行状况检查相关联，一条在俄勒冈州，另一条在北弗吉尼亚州。当俄勒冈端点的运行状况检查失败时，无论客户端位于何处，所有请求都将路由到北弗吉尼亚端点。

相关信息

检查来自 Route 53 的 DNS 响应

如何确定公共 DNS 解析器是否支持 EDNS 客户端子网扩展？

如何解决 Route 53 运行状况检查显示运行不正常的问题？

当我使用“评估目标运行状况”时，为什么指向应用程序负载均衡器的别名记录被标记为运行不正常？