レイテンシーベースのリソースレコードと Route 53 の問題をトラブルシューティングするにはどうすればいいですか？

簡単な説明

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

• 同じリソースレコードを持つ複数の AWS リージョンでエンドポイントを関連付けた。
• レイテンシーベースのルーティングポリシーを使用している。

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

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

Route 53 ネームサーバーはデフォルトで edns0-client-subne をサポートします。再帰的 DNS リゾルバーが edns0-client-subnet をサポートしている場合、DNS リゾルバーは Route 53 にクライアントの IP アドレスの切り捨てられたバージョンを送信します。次に、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 リゾルバーがエニーキャストをサポートしていることを確認します。毎回の出力で同じ 1 つの 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 サーバーです。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 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 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 ヘルスチェックに関連付けられているかどうかを判断します。また、(エイリアスレコードの) ターゲットヘルス評価 (ETH) がオンになっているかどうかを確認します。一方または両方に該当する場合、Route 53 はレイテンシーが最も低い正常なエンドポイントを返します。すべてのヘルスチェックに失敗した場合は、ルーティングポリシーのみが考慮されます。

Route 53 コンソールで Route 53 ヘルスチェックのステータスを確認します。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 つはバージニア北部にあります。オレゴンのエンドポイントのヘルスチェックが失敗すると、クライアントの場所に関係なく、すべてのリクエストがバージニア北部のエンドポイントにルーティングされます。

関連情報

Route 53 からの DNS レスポンスのチェック

パブリック DNS リゾルバーが EDNS Client Subnet 拡張機能をサポートしているかどうかを確認するには、どうすればよいですか?

異常な Route 53 ヘルスチェックをトラブルシューティングするにはどうすればよいですか?

[Evaluate Target Health] (ターゲットの正常性の評価) の使用時に Application Load Balancer を参照するエイリアスレコードが異常とマークされるのはなぜですか?