Route 53 の位置情報ルーティングの問題をトラブルシューティングする方法を教えてください。

解決策

Route 53 の位置情報ルーティングの問題は、以下の問題が原因で発生します。

• 位置情報のルーティング設定にデフォルトの場所がありません。
• DNS リゾルバーは EDNS0 の edns0 クライアントサブネット拡張をサポートしていません。これにより、位置の特定が不正確になります。
• DNS リゾルバーは地理的に多様です。
• リソースレコードの DNS 変更がグローバルに伝播されていません。

これらの問題を解決するには、次の操作を行います。

1.    Route 53 ホストゾーンのリソースレコードがユースケースに合わせて適切に設定されていることを確認します。また、デフォルトのリソースレコードセットがあることも確認してください。Route 53 コンソールから、Route 53 ホストゾーン設定で指定されているデフォルトの場所を確認します。

**例:**次のサンプル出力を考えてみましょう。

>> dig images.example.com

; <<>> DiG
9.8.2rc1-RedHat-9.8.2-0.37.rc1.45.amzn1 <<>> images.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR,
id: 51385
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
ADDITIONAL: 0

;; QUESTION SECTION
;images.example.com.    IN            A

;; AUTHORITY SECTION:
images.example.com.    60          IN           SOA        ns-1875.awsdns-42.co.uk.awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 65 msec
;; SERVER: 172.31.0.2#53(172.31.0.2)
;; WHEN: Tue Feb  7 22:02:30 2017
;; MSG SIZE  rcvd: 124

前の例では、位置情報ルーティング設定にデフォルトの場所が指定されていません。そのため、位置情報が一致しない場合、DNS 応答は [rcode] フィールドに [NOERROR] を返し、[ANSWER] セクションには結果がありません。この問題を解決するには、位置情報ルーティング設定にデフォルトの場所を追加します。

2.    DNS リゾルバーの IP アドレス範囲を確認するには、次のコマンドを実行し、出力を書き留めます。

Linux または macOS では、[dig] を使用します。

for i in {1..10}; do dig +short resolver-identity.cloudfront.net; sleep 11; done;

Windows では、[nslookup] を使用します。

for /l %i in (1,1,10) do (nslookup resolver-identity.cloudfront.net && timeout /t 11 /nobreak)

3.    以下のいずれかのコマンドを使用して、DNS リゾルバーが [edns0-Client-Subnet] をサポートしているかどうかを確認し、出力を書き留めておきます。

Linux または macOS では、[dig] を使用します。

dig +nocl TXT o-o.myaddr.l.google.com

Windows では、[nslookup] を使用します。

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

出力の Answer セクションに返された最初の TXT レコードを確認します。最初の TXT レコード値は DNS リゾルバーの IP アドレスです。2 つ目の TXT レコードがない場合、DNS リゾルバーは edns0-client-subnet をサポートしていません。2 つ目の TXT レコードがある場合、DNS リゾルバーは edns0-client-subnet をサポートします。リゾルバーは、切り捨てられたクライアントサブネット IP アドレス (/24 または /32) を Route 53 の権限のあるネームサーバーに提供します。詳細については、パブリック DNS リゾルバーが EDNS クライアントサブネット (ECS) 拡張をサポートしているかどうかを確認する方法を参照してください。

4.    チェックツールの Route 53 テストレコードセットを使用して、特定のリクエストに対して返されるリソースレコードを決定します。詳細については、チェックツールを使用して Amazon Route 53 が DNS クエリにどのように応答するかを確認する を参照してください。

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

DNS リゾルバーが edns0-client-subnet をサポートしている場合は、ツールの値として [EDNS0 クライアントサブネット IP アドレス] を指定します。[その他のオプション] を選択し、[サブネット] マスクを指定します。[リゾルバーの IP アドレス] は指定しないでください。

5.    (オプション) チェックツールにアクセスできない場合は、[dig] を使用して、EDNS0-Client-Subnet でホストゾーンの Route 53 権限のあるネームサーバーにクエリを実行します。この出力を使用して、送信元 IP アドレスに対する信頼できる位置情報レコードの応答を判断してください。

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

6.    Route 53 ネームサーバーは、EDNS0 の edns0-client-subnet 拡張をサポートします。リゾルバーまたはローカル DNS サーバーは、クライアントのソース IP サブネットに基づいて DNS 検索を行うために、DNS クエリに edns0-client-subnet を追加します。このデータがリクエストとともに渡されない場合、Route 53 は DNS リゾルバーのソース IP アドレスを使用してクライアントのロケーションを概算します。次に、Route 53 は位置情報クエリに応答し、リゾルバーの場所の DNS レコードを返します。EDNS0 データを Route 53 に渡し、クライアントは地理的に近い再帰型ネームサーバーを使用する必要があります。そうでない場合、結果として DNS クエリに誤ったリソースレコードを提供する最適な場所とは言えません。

この構成を修正するには、edns0-client-subnet をサポートする再帰的 DNS サーバーを変更してください。DNS 解決を実行して、出力を共有します。再帰的 DNS サーバーが edns0-client-subnet をサポートしていない場合は、サポートしているサーバーを使用してみてください。edns0-client-subnet をサポートするオプションには、Google DNS リゾルバーと OpenDNS リゾルバーが含まれます。

7.    MaxMind ウェブサイトにある MaxMind の GeoIP データベース、またはお使いの GeoIP データベースを使用して、クライアントのサブネット IP アドレスの地理的位置を確認します。DNS リゾルバーがクライアントのパブリック IP アドレスに地理的に近いことを確認します。MaxMind ウェブサイトの回答または国が Route 53 の回答と一致しない場合、Route 53 の生産地域データが古くなっている可能性があります。古いルーティングがある場合は、AWS サポートにお問い合わせください。

8.    OpenDNS サイトの CacheCheck などのツールを使用して、DNS プロパゲーションの問題がないか確認してください。

9.    (オプション) 地理ベースのルーティングレコードが Route 53 ヘルスチェックに関連付けられているかどうかを判断します。また、エイリアスレコードの [Evaluate Target Health (ETH)] がオンになっているかどうかを確認します。どちらかが当てはまる場合、Route 53 はソースロケーションに最も一致する正常なエンドポイントを返します。

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

**例:**米国テキサス州、米国、北米、およびすべての場所 (場所はデフォルト) のレコードがあります。また、テキサス州から発信されたクエリで、エンドポイントが正常ではありません。Route 53 は、正常なエンドポイントのレコードが見つかるまで、米国、北米、そしてすべての場所をこの順序でチェックします。米国のレコードが正常であれば、Route 53 はこのエンドポイントを返します。それ以外の場合、Route 53 はデフォルトレコードを返します。該当するすべてのレコードに異常がある場合、Route 53 は地理的に最も小さい地域のレコードの値を使用して DNS クエリに応答します。

**注:**エイリアス化された位置情報リソースレコードへの変更は、反映されるまでに最大 60 秒かかる場合があります。

関連情報

異常な Route 53 ヘルスチェックをトラブルシューティングする方法を教えてください。

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

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