レイテンシーベースのリソースレコードと Route 53 の問題のトラブルシューティング方法を教えてください。

最終更新日: 2021 年 5 月 20 日

Amazon Route 53 のレイテンシーベースルーティングにより、クライアントから地理的に離れた AWS リージョンにあるサーバーが返されます。例えば、米国のユーザーが私のウェブサイトにアクセスしようとすると、Route 53 は欧州にあるサーバーの IP アドレスを返します。クライアントが、遠く離れたリージョンにルーティングされるのを防ぐにはどうすればよいですか?

簡単な説明

Route 53 は、以下が該当する場合に、DNS クエリの場所に基づいて、最もレイテンシーが低いリージョンに解決します。

Route 53 は、以下に基づいてレイテンシーベースのルーティング決定を行います。

  • Route 53 の権威ネームサーバーにクエリを送信する再帰的な DNS リゾルバーの送信元 IP アドレス。
  • クライアントの IP アドレスの切り捨てられたバージョン (DNS リゾルバーが EDNS0-Client-Subnet 拡張機能をサポートしている場合)

Route 53 のネームサーバーは、デフォルトで EDNS0-Client-Subnet をサポートします。再帰的な DNS リゾルバーが EDNS0-Client-Subnet をサポートしている場合、DNS リゾルバーはクライアントの IP アドレスの切り捨てたバージョンを Route 53 に送信します。その後、Route 53 はその切り捨てられた IP アドレスを使用して、最もレイテンシーが低いリージョンを決定します。

レイテンシーが最も低いリージョンは、DNS リゾルバーに物理的に最も近いリージョンではない場合があります。クライアントが DNS リゾルバーと同じ場所にない場合、望ましくないルーティング動作が発生する可能性があります。リゾルバーの IP アドレスに異なるロケーション情報がある場合にも、望ましくないルーティング動作が発生する可能性があります。

サンプルシナリオ

会社には、2 つの Elastic Load Balancer のレイテンシーベースのルーティングレコードが、1 つはバージニア (us-east-1)、もう 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 リゾルバーが、出力を使用して Anycast をサポートしていることを確認します。​毎回の出力で同じ 1 つの IP アドレスが返される場合、DNS リゾルバーは Anycast をサポートしていません。コマンドを実行するたびに毎回 IP アドレスが変わる場合、DNS リゾルバーは Anycast をサポートしています。

DNS リゾルバーが Anycast をサポートする場合、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 レコードを確認します。この値は、Anycast をアドバタイズする最も近い DNS サーバーです。2 番目の TXT レコードがない場合、DNS リゾルバーは EDNS0-Client-Subnet をサポートしていません。2 番目の TXT レコードがある場合、DNS リゾルバーは EDNS0-Client-Subnet をサポートしています。リゾルバーは切り捨てられたクライアントサブネット (/24 または /32) を Route 53 の権威ネームサーバーに送信します。

(オプション) ホストゾーンで Route 53 DNS クエリログ記録を有効にした場合は、テストレコードを作成します。その後、新しいレコードの DNS ルックアップを実行します。クエリログをチェックして、Route 53 ネームサーバーに提示されたリゾルバー IP アドレスと EDNS0-Client-Subnet (存在する場合) を確認します。

6.    レスポンスの TTL 値が 60 秒であることを確認します。TTL 値が 60 秒でない場合、レスポンスはキャッシュされたレスポンスです。レスポンスの TTL 値が 60 秒になるまで dig または nslookup コマンドを繰り返します。

7.    Route 53 DNS チェックツールにアクセスできる場合は、特定の DNS リゾルバー IP アドレスまたはクライアント IP アドレスからのクエリをシミュレートします。以下のクエリを使用して、Route 53 が返すレイテンシーリソースレコードセットを検索します。

DNS リゾルバーが EDNS0-Client-Subnet をサポートしていない場合は、ツールの値としてリゾルバー IP アドレスを指定します。

DNS リゾルバーが EDNS0-Client-Subnet をサポートしている場合は、ツールの値として EDNS0 クライアントサブネット IP を指定します。[Additional configuration] (追加設定) を選択し、[Subnet] (サブネット) のマスクを指定します。

: このツールは、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 database、または任意の 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) の 2 つがあります。

11.    (オプション) レイテンシーベースのルーティングレコードが Route 53 ヘルスチェックに関連付けられているかどうか、および (エイリアスレコードに対して) [Evaluate Target Health] (ターゲットの正常性の評価) が有効になっているかどうかを確認します。一方または両方に該当する場合、Route 53 はレイテンシーが最も低い正常なエンドポイントを返します。すべてのヘルスチェックが失敗した場合は、ルーティングポリシーだけが考慮されます。

Route 53 コンソールで Route 53 ヘルスチェックのステータスを確認します。[Evaluate Target Health] (ターゲットの正常性の評価、ETH) が有効になっている場合は、レコードエンドポイントのヘルスステータスを確認します。Route 53 は、少なくとも 1 つのバックエンドインスタンスが正常であれば、ETH が有効になっている Classic Load Balancer のエンドポイントが正常であるとみなします。Application Load Balancer および Network Load Balancer の場合、ターゲットを持つすべてのターゲットグループには、正常とみなされる正常なターゲットが少なくとも 1 つ含まれている必要があります。登録済みのターゲットを持たないターゲットグループは、異常とみなされます。いずれかのターゲットグループに異常なターゲットしか含まれていない場合、ロードバランサーは異常であるとみなされます。例外: Application Load Balancer に少なくとも 1 つの正常なターゲットグループがあり、残りのすべてのターゲットグループが空の場合、Route 53 はそれを正常であるとみなします。

例えば、Route 53 ヘルスチェックが関連付けられている 2 つのレイテンシーベースのルーティングレコードがあり、1 つはオレゴンに、もう 1 つはバージニア北部にあるとします。オレゴンのエンドポイントのヘルスチェックが失敗すると、クライアントの場所に関係なく、すべてのリクエストがバージニア北部のエンドポイントにルーティングされます。