如何疑難排解以延遲為基礎的資源記錄和 Route 53 發生的問題？

簡短說明

如果下列為 True，Route 53 即會根據 DNS 查詢的位置以最低延遲解析到區域：

• 您已將多個 AWS 區域中的端點關聯到相同的資源記錄。
• 您正在使用 Latency Based Routing 原則。

Route 53 根據以下情況做出 Latency Based Routing 決策：

• 遞迴 DNS 解析器的來源 IP 位址將查詢傳送至 Route 53 授權名稱伺服器。
• 用戶端 IP 位址的截斷版本（如果 DNS 解析器支援延伸功能 edns00-client-subnet）。

Route 53 名稱伺服器預設支援 edns0-client-subnet。如果遞迴 DNS 解析器支援 edns0-client-subnet，DNS 解析器即會向 Route 53 傳送用戶端 IP 位址的截斷版本。然後，Route 53 會使用該截斷的 IP 位址以判斷最低延遲的區域。

最低延遲的區域實際上可能最不接近 DNS 解析器。如果用戶端與 DNS 解析器的位置不同，您可能會遇到不需要的路由行為。如果解析器的 IP 位址位置資訊不同，您可能也會遇到不需要的路由行為。

範例案例

某家公司具有兩個彈性負載平衡器的 Latency Based Routing 記錄，一個位於維吉尼亞 (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 會在其延遲資料庫中執行查詢，並正確判斷維吉尼亞的負載平衡器具有最低延遲。

解決方法

請使用下列步驟來疑難排解不需要的 Latency Based Routing 行為：

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。解析器會將截斷的用戶端子網路（/24 或 /32）傳送至 Route 53 授權名稱伺服器。

（選用）如果您在託管區域上開啟 Route 53 DNS 查詢記錄，請建立測試記錄。對新記錄執行 DNS 查詢。檢查查詢記錄以確認解析器 IP 位址和 edns0-client-subnet（如有）呈現給 Route 53 名稱伺服器。

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.    （選用）確定 Latency Based Routing 記錄是否與 Route 53 運作狀態檢查相關聯。然後確定「評估目標運作狀態」(ETH) 已開啟（用於別名記錄）。如果其中一個或兩者皆為 True，Route 53 即會傳回最低延遲的良好端點。如果所有運作狀態檢查都失敗，則只會考慮路由原則。

在 Route 53 主控台中，檢查 Route 53 運作狀態檢查的狀態。如果 ETH 已開啟，請檢查記錄端點的運作狀態。如果至少有一個後端執行個體的運作狀態良好，Route 53 即會將開啟 ETH 的 Classic Load Balancer 端點視為良好。對於 Application Load Balancer 和 Network Load Balancer，每個具有目標的目標群組都必須至少包含一個運作狀態良好的目標，才能視為良好。沒有註冊目標的目標群組會被視為運作狀態不良。如果任何目標群組只包含運作狀態不良的目標，負載平衡器即會被視為不良。

**例外狀況：**如果 Application Load Balancer 至少有一個運作狀態良好的目標群組，且剩餘的所有目標群組都是空的，Route 53 即會將其視為良好。

範例

您有兩個 Latency Based Routing 記錄和相關的 Route 53 運作狀態檢查，一個在奧勒岡，另一個在維吉尼亞北部。當奧勒岡端點的運作狀態檢查失敗時，無論用戶端的位置為何，所有要求都會路由到維吉尼亞北部的端點。

相關資訊

檢查 Route 53 的 DNS 回應

如何確定我的公共 DNS 解析器是否支援 EDNS 用戶端子網路延伸功能？

如何疑難排解不良的 Route 53 運作狀態檢查？

當我使用「評估目標運作狀態」時，為什麼別名記錄指向標記為不良的 Application Load Balancer？