Route 53 ルールとアウトバウンドエンドポイントで逆引き DNS の問題をトラブルシューティングする方法を教えてください。

最終更新日: 2020 年 7 月 16 日

Amazon Route 53 Resolver のルールとアウトバウンドエンドポイントを設定しました。これらのルールとエンドポイントは、オンプレミスの DNS サーバーで仮想プライベートクラウド (VPC) の逆引き DNS を管理するためのものです。しかし、意図したとおりに機能しません。この問題を解決するには、どうすればよいですか?

簡単な説明

逆引き DNS 参照を使用して、IP アドレスのドメイン名を返すことができます。逆引き DNS レコードの形式は、名前空間「in-addr.arpa.」に該当します。ここで、サブドメインは IP アドレスのオクテットで逆順に表されます。レコードタイプはポインタ (PTR) です。

たとえば、CIDR 範囲 172.31.0.0/16 の仮想プライベートクラウド (VPC) があるとします。VPC に、IP アドレスが 172.31.2.23 のインスタンスがあります。この VPC の逆引きゾーンは 31.172.in-addr.arpa. です。このインスタンスの IP アドレスの逆引きレコードは 23.2.31.172.in-addr.arpa. です。

DNS レスポンスを確認するには、dig または nslookup を実行します。これらのツールを使用すると、IP アドレスに直接テストし、ユーザーに代わって逆引き参照を実行できます。次の出力例では、クエリが IP アドレス 172.31.2.23 に直接送信されることに注意してください。dig と nslookup はどちらも 23.2.31.172.in-addr.arpa. という名前に対して解決を実行します。

dig で -x パラメータを使用すると、逆引き DNS 解決を実行できます。このパラメータを使用すると、dig は自動的に名前、クラス、および種類の引数を追加します。dig で正しい名前 (23.2.31.172.in-addr.arpa.)、クラス (IN)、およびレコードの種類 (PTR) が自動的にクエリされたことを確認するには、QUESTION SECTION を参照してください。

dig -x 172.31.2.23:

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.2 <<>> -x 172.31.2.23
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58812
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; 
OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;23.2.31.172.in-addr.arpa.    IN    PTR

;; 
ANSWER SECTION:
23.2.31.172.in-addr.arpa. 60    IN    PTR    testresolution.com.

IP アドレスの nslookup は、逆引き参照を実行します。

nslookup 172.31.2.23
23.2.31.172.in-addr.arpa    name = testresolution.com.

解決方法

クエリフローを理解する

VPC およびアウトバウンドエンドポイントでリゾルバールールを使用するときは、クエリフローを理解することが重要です。フローを理解すると、潜在的な問題が発生する可能性がある場所を特定し、採用するトラブルシューティングの手法を判断するうえで役立ちます。フローは次のとおりです。

  1. VPC 内のクライアントは、同じ VPC 内のアドレスに対して逆引き DNS 解決を実行します。
  2. クエリは VPC DNS リゾルバー (VPC CIDR 範囲 + 2) に到達します。
  3. クエリは、VPC のリゾルバールールに一致します。
  4. クエリは、アウトバウンドエンドポイントによって、VPN または AWS Direct Connect 接続経由でターゲット IP アドレスに送信されます。
    注意: ターゲット IP アドレスは、VPC の CIDR 範囲の逆引き DNS を管理するオンプレミスの DNS サーバーです。

予想される DNS 応答と実際の DNS 応答を特定する

dig と nslookup を使用して、オンプレミス DNS サーバーの IP アドレスに直接クエリを実行します。これらのツールは、正しいレコード名を解決しようとします。返される実際の DNS 応答コードをメモしておきます。予期しない応答コードは、ルールまたはエンドポイント設定の問題を示していない可能性があることに注意してください。たとえば、以下のようになります。

  • NXDOMAIN は、予期しない有効な DNS 応答である可能性があります。この応答は、クエリ対象のサーバーにリクエストされたレコードが含まれていないことを示します。
  • SERVFAIL は、クエリのパスにタイムアウトなどの問題があることを示します。この記事で後述するように、この応答についてはさらに調査が必要です。
  • ANSWER SECTION の予期しない回答は、別のルールが使用されたことを示している可能性があります。

クエリが VPC DNS リゾルバーに到達するかどうかを確認する

クエリが VPC のルールと一致するには、クエリが VPC DNS リゾルバーに到達する必要があります。VPC 設定をチェックして、[DNS Support] (DNS サポート) が有効になっていることを確認します。

リゾルバーの IP アドレスを確認するには、dig と nslookup の両方のサーバーフィールドを参照してください。

dig:

;; SERVER: 172.31.0.2#53(172.31.0.2)

nslookup:

Server:		172.31.0.2

一致する最も具体的なルールを見つける

クエリが VPC DNS リゾルバーに到着すると、その VPC のルールと一致する必要があります。ルールが評価されると、最も具体的なルールが一致します。内部的には、ソース VPC と接続された VPC のあらゆる IP アドレスのすべての逆引き参照をカバーするルールが作成されます。これらのルールは AWS マネジメントコンソールに表示されません。これらのルールは、自動定義ルールと呼ばれ、Route 53 Resolver によって作成されます。

  1. VPC および接続された VPC で自動定義ルールを特定します。ピアリング接続された VPC または Transit Gateway 経由で接続している VPC をがある場合 (かつ、DNS サポートが有効である場合)、接続された各 CIDR の逆解決のために作成されたすべてのルールを書き留めます。
    注意: Resolver は、[DNS Hostnames] (DNS ホスト名) が true に設定されている場合、これらの自動定義ルールを作成します。自動定義ルールを上書きする場合は、同じドメイン名に対して条件付き転送ルールを作成できます。
  2. DNSSupport と DNSHostnames が有効になっている場合は、VPC に関連付けられているプライベートホストゾーンを書き留めます。
    注意: リゾルバーフォワーダールールとプライベートホストゾーンが重複している場合、リゾルバールールが優先されます。その後、クエリはオンプレミスサーバーに転送されます。
  3. ルールと関連するプライベートホストゾーンのリストをクエリと比較して、どのルールが選択されているか、およびどこでクエリが実行されるかを判断します。

アウトバウンドエンドポイントのトラブルシューティング

  • アウトバウンドエンドポイントが、ルールで指定されたターゲット IP アドレスにクエリを送信するように設定されていることを確認します。
  • アウトバウンドエンドポイントで使用されるセキュリティグループで、オンプレミス DNS サーバーの IP アドレスとポートへのアウトバウンド TCP および UDP トラフィックが許可されていることを確認します。
  • アクセスコントロールリスト (ACL) で、オンプレミス DNS サーバーの IP アドレスとポートへの TCP および UDP トラフィックが許可されていることを確認します。また、ACL は、一時ポート (1024-65535) へのトラフィックも許可している必要があります。
  • アウトバウンドエンドポイントのルートテーブルに、オンプレミスサーバーの IP アドレスから VPN または Direct Connect 接続へのルートがあることを確認します。

アウトバウンドエンドポイントが、ルートテーブルで指定された接続を介してクエリを送信できるかどうかを確認する

オンプレミス DNS リゾルバーの IP アドレスに対して dig または nslookup を直接実行して、VPN または Direct Connect 接続で通信が許可されていることを確認できます。また、インターネットコントロールメッセージプロトコル (ICMP) が接続の問題を除外できるようにするオンプレミスホストに ping を送信することもできます。


この記事はお役に立ちましたか?


請求に関するサポートまたは技術的なサポートが必要ですか?