Route 53 プライベートホストゾーンの DNS 解決の問題をトラブルシューティングする方法を教えてください。
Amazon Route 53 プライベートホストゾーンの DNS 解決の問題をトラブルシューティングしたいと考えています。
解決策
注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、最新バージョンの AWS CLI を使用していることを確認してください。。
VPC で DNS サポートをアクティブ化していることを確認する
プライベートホストゾーンのレコード解決を許可するには、仮想プライベートクラウド (VPC) で DNS サポートを有効にする必要があります。VPC で DNSSupport と DNSHostnames が True に設定されていることを確認します。
正しい VPC ID がプライベートホストゾーンに関連付けられていることを確認する
プライベートホストゾーンを VPC に関連付けると、Route 53 Resolver は自動定義ルールを作成し、それを VPC に関連付けます。その VPC 内のリソースは、リゾルバーにクエリを実行して、プライベートホストゾーンの DNS レコードを解決できます。
正しい VPC ID がプライベートホストゾーンに関連付けられていることを確認します。また、同じ VPC 内からドメインのリソースレコードをクエリしていることを確認してください。
ホストゾーンに関連付けられた VPC のリストを取得するには、AWS CLI で次のコマンドを実行します。
aws route53 list-hosted-zones-by-vpc --vpc-id VPC_ID --vpc-region REGION_ID
注: VPC_ID と REGION_ID を適切な値に置き換えてください。
特定の VPC に関連付けられているプライベートホストゾーンのリストを取得するには、AWS CLI で次のコマンドを実行します。
aws route53 get-hosted-zone --id VPC_ID
注: VPC_ID を適切な値に置き換えてください。
カスタム DNS サーバーのプライベートホストゾーンドメインを Amazon が提供する DNS サーバー (CIDR+2) に転送するルールを設定したことを確認します。
VPC の DNS の DHCP オプションでカスタム DNS サーバーまたは Active Directory サーバーを設定した場合は、次の設定を確認してください。
- 転送ルールで、サーバーがプライベートドメインの DNS クエリを Amazon が提供する VPC の DNS サーバーの IP アドレスに転送することを確認します。たとえば、VPC のプライマリ CIDR 範囲が 172.31.0.0/16 の場合、VPC DNS サーバーの IP アドレスは 172.31.0.2 になります。これは VPC ネットワークの範囲に 2 を加えたものです。
- カスタムサーバーで設定したドメインがプライベートホストゾーンと異なることを確認します。ドメインがプライベートホストゾーンと同じ場合、サーバーはそのドメインに対して権限があります。この場合、サーバーはプライベートホストゾーンドメインの Amazon 提供の DNS サーバーに接続しません。
resolv.conf でカスタム設定を確認する
DNS 解決または応答が断続的に発生する場合は、resolv.conf でソースインスタンスの設定を確認してください。
たとえば、rotate オプションを resolv.conf で設定して、Amazon DNS サーバーとパブリック Google リゾルバーサーバー (8.8.8.8) の間で DNS クエリの負荷を分散します。この場合、resolv.conf の設定は次のとおりです。
options rotate; generated by /usr/sbin/dhclient-script nameserver 8.8.8.8 nameserver 172.31.0.2
公開されている Google リゾルバー (8.8.8.8) への最初のクエリでは、期待どおりの NxDomain 応答が返されます。リゾルバーがプライベートホストゾーンではなくパブリックホストゾーンでレスポンスを見つけようとしているため、この応答が返されます。
Private hosted Zone Record - resolvconf.local\[ec2-user@ip-172-31-253-89 etc\]$ curl -vks http://resolvconf.local \* Rebuilt URL to: http://resolvconf.local/ \* Could not resolve host: resolvconf.local 15:24:58.553320 IP ip-172-31-253-89.ap-southeast-2.compute.internal.40043 > dns.google.domain: 65053+ A? resolvconf.local. (34) 15:24:58.554814 IP dns.google.domain > ip-172-31-253-89.ap-southeast-2.compute.internal.40043: 65053 NXDomain 0/1/0 (109)
ただし、2 番目のクエリは正常に解決されます。2 番目のクエリは、プライベートホストゾーンに関連付けられた VPC DNS リゾルバーに到達することから成功します。
[ec2-user@ip-172-31-253-89 etc]$ curl -vks http://resolvconf.local* Rebuilt URL to: http://resolvconf.local/ * Trying 1.1.1.1... * TCP_NODELAY set * Connected to resolvconf.local (1.1.1.1) port 80 (#0) 15:25:00.224761 IP ip-172-31-253-89.ap-southeast-2.compute.internal.51578 > 172.31.0.2.domain: 7806+ A? resolvconf.local. (34) 15:25:00.226527 IP 172.31.0.2.domain > ip-172-31-253-89.ap-southeast-2.compute.internal.51578: 7806 1/0/0 A 1.1.1.1 (50)
プライベートホストゾーンの名前空間が重複していないことを確認する
複数のゾーンに重複する名前空間 (example.com と test.example.com など) がある場合、リゾルバーは最も限定的な一致に基づいてトラフィックをホストゾーンにルーティングします。一致するゾーンはあるが、リクエストのドメイン名とタイプに一致するレコードがない場合、レゾルバーはリクエストを転送しません。代わりに、リゾルバーは NXDOMAIN (存在しないドメイン) をクライアントに返します。
DNS を正常に解決するには、最も限定的なプライベートホストゾーンで正しいレコードを設定したことを確認してください。
たとえば、以下のレコードを持つプライベートホストゾーンが 2 つあるとします。
| プライベートホストゾーン名 | レコード名 | 値 |
| local | overlap.privatevpc.local | 60.1.1.1 |
| privatevpc.local | overlap.privatevpc.local | 50.1.1.1 |
リクエストには、一致する最も限定的なプライベートホストゾーンから次の応答が返されます。
[ec2-user@IAD-BAS-INSTANCE ~]$ dig overlap.privatevpc.local +short50.1.1.1
プライベートホストゾーンにゾーン委任が設定されていないことを確認する
プライベートホストゾーンはゾーン委任をサポートしていません。委任が設定されている場合、クライアントは VPC リゾルバーから「Servfail」レスポンスコードを取得します。
AWS CLI を使用して、次の例のように、プライベートホストゾーンにゾーン委任が設定されていないことを確認します。
プライベートホストゾーン:abc.com デリゲーション NS レコード:kc.abc.com リソースレコード:test.kc.abc.com
[ec2-user@ip-172-31-0-8 ~]$ dig test.kc.abc.com;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63414 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;test.kc.abc.com IN A ;; Query time: 15 msec ;; SERVER: 172.31.0.2#53(172.31.0.2) ;; WHEN: Fri Apr 16 15:57:37 2021 ;; MSG SIZE rcvd: 48
リソースレコードのルーティングポリシーがプライベートホストゾーンでサポートされていることを確認します。
プライベートホストゾーンでサポートされているルーティングポリシーがリソースレコードに設定されていることを確認します。
- シンプルなルーティング
- フェイルオーバールーティング
- 複数値回答ルーティング
- 加重ルーティング
- レイテンシーベースのルーティング
- 位置情報ルーティング
リゾルバールールとそのインバウンドエンドポイントが別の VPC に解決されることを確認する
レゾルバールール内のアウトバウンドエンドポイントが、ルールと VPC を共有するインバウンドエンドポイントを指している場合、結果はループになります。このループでは、クエリはインバウンドエンドポイントとアウトバウンドエンドポイントの間を継続的に通過します。
転送ルールを他のアカウントと共有されている他の VPC に関連付けることはできます。これを行うには、AWS Resource Access Manager (AWS RAM) を使用します。ハブまたはセントラル VPC に関連付けられているプライベートホストゾーンは、インバウンドエンドポイントへのクエリから解決されます。次の例のように、転送リゾルバールールを使用してもこの解決は変わりません。
ハブ VPC: VPC A-CIDR 172.31.0.0/16 スポーク VPC: VPC B-CIDR 172.32.0.0/16 インバウンド IP アドレス: 転送ルール内の 172.31.253.100 および 172.31.2.100 ターゲット IP アドレス: VPC に関連付けられている 172.31.253.100 と 172.31.2.100 ルール: VPC A および VPC B クライアント: 172-32-254-37
ubuntu@ip-172-32-254-37:~$ dig overlap.privatevpc.local;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9007 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;overlap.privatevpc.local. IN A ;; Query time: 2941 msec ;; SERVER: 172.32.0.2#53(172.32.0.2)
この出力では、DNS 要求はアウトバウンドエンドポイントとインバウンドエンドポイントの間を継続的にホップします。リクエストは VPC A に関連付けられているルールをチェックし、クエリをアウトバウンドエンドポイントに送り返します。何度か試行すると、クエリはタイムアウトし、Servfail 応答コードで応答します。
この問題を解決してループを中断するには、ルールとのハブ VPC のアソシエーション (VPC A) を削除します。次に、プライベートホストゾーンから成功の応答が返されます。
ubuntu@ip-172-32-254-37:~$ dig overlap.privatevpc.local;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58606 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;overlap.privatevpc.local. IN A ;; ANSWER SECTION: overlap.privatevpc.local. 0 IN A 50.1.1.1 ;; Query time: 5 msec ;; SERVER: 172.32.0.2#53(172.32.0.2)
オンプレミスリゾルバーが再帰リクエストを送信することを確認する
オンプレミスから Route 53 Resolver へのクエリを使用する場合、DNS クエリをネットワーク上のリゾルバーから VPC リゾルバーに転送できます。これを行うには、リゾルバーインバウンドエンドポイントを使用します。このアクションにより、プライベートホストゾーンのレコードなどの AWS リソースのドメイン名を解決できます。
場合によっては、プライベートホストゾーンがオンプレミスリゾルバーから正常に解決されないことがあります。この現象は、オンプレミスのリゾルバーが再帰リクエストではなく反復クエリを送信しているために発生します。インバウンドエンドポイントは、DNS 解決を成功させるための再帰クエリをサポートしています。
解決タイプを確認するには、DNS リゾルバー (オンプレミス) でパケットキャプチャを使用します。次に、DNS フラグを確認します (再帰が必要 = 0)。解決をテストするには、+norecurse dig コマンドで繰り返しリクエストを送信するか、nslookup で norecurse を設定します。
インバウンドエンドポイント IP アドレス: 172.31.253.150
オンプレミスリゾルバー IP アドレス: 10.0.4.210
インバウンド IP アドレスへの再帰クエリが失敗すると、次の出力が返されます。
[ec2-user@IAD-BAS-INSTANCE ~]$ dig @172.31.253.150 overlap.privatevpc.local +norecurse; <<>> DiG 9.11.0rc1 <<>> @172.31.253.150 overlap.privatevpc.local +norecurse ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
再帰クエリが成功すると、次の出力が返されます。
[ec2-user@IAD-BAS-INSTANCE ~]$ dig @172.31.253.150 overlap.privatevpc.local;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19051 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;overlap.privatevpc.local. IN A ;; ANSWER SECTION: overlap.privatevpc.local. 0 IN A 50.1.1.1 ;; Query time: 200 msec ;; SERVER: 172.31.253.150#53(172.31.253.150)
Amazon が提供する DNS に正しいルール優先度を設定したことを確認する
クライアントインスタンスがリゾルバー (AWS 提供の DNS サーバー) にクエリを送信すると、リゾルバーはリクエストのルーティング先に関するインスタンスのルールを検証します。
一般的には、最も限定的なルールが優先されます。test.example.com リゾルバールールと longest.test.example.com プライベートホストゾーンがある場合は、longest.test.example.com ドメインのルックアップがプライベートホストゾーンと一致します。
ルールが同じドメインレベルにある場合、次の優先順位が付けられます。
- リゾルバールール
- プライベートホストゾーンルール
- 内部ルール
たとえば、test.example.com リゾルバールールと test.example.com プライベートホストゾーンがある場合、リゾルバールールが優先されます。クエリは、ルールに設定されているサーバーまたはターゲット IP アドレスに転送されます。
関連情報
関連するコンテンツ
- 質問済み 15日前
- AWS公式更新しました 1年前
- AWS公式更新しました 1年前
