プライベート DNS は VPC 内では機能するが VPN 経由では機能しない
EC2 の内部では解決できるのに VPN 経由では解決できないプライベート名は、リゾルバ経路の問題です。ゾーン レコードを編集する前に、失敗の形を読み取ってください。
プライベート名は EC2 インスタンスからは解決できるのに VPN 経由で接続したラップトップからは解決できませんが、コンソールではゾーンは正しく見えます。最初にしたくなるのはレコードの編集ですが、それはほとんどの場合問題ではありません。レコードは誰かには応答しており、ただ、あなたのラップトップには応答していないだけです。二人の呼び出し元の違いは、どのリゾルバに問い合わせるか、そしてそのリゾルバに VPC の DNS ビューへのサポートされた経路があるかどうかです。
まずレコードが存在することを証明し、残りの時間はクエリ経路に費やします。これらは別のシステムであり、失敗の仕方も異なります。
何かを変更する前に失敗の形を読む
三つの結果は 三つの異なる意味を持ち、クライアントが実際に使っているリゾルバに対してその名前の dig を実行すれば 一回のクエリでそれらを区別できます。
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
タイムアウトはネットワークについての表明です。NXDOMAIN は DNS ビューについての表明です。公開アドレスの応答はポリシーについての表明です。タイムアウトがある状態でゾーン レコードを編集すると、この件で唯一役に立つ証拠を捨てることになります。
VPC のプラス二アドレスがリモート リゾルバではない理由
CIDR プラス二アドレスは VPC 内部のリソース向けのローカル サービスです。オンプレミス ネットワークや別の VPC の DNS サーバーからそのアドレスへ直接クエリを転送することはサポートされておらず、不安定な結果になり得ると AWS は文書化しています。
だからといって実験が決して動いているように見えないわけではなく、振る舞いがヘルプデスクのスクリプトに書ける契約ではないというだけです。サポートされる方向はインバウンド Resolver エンドポイントです。VPC 内にあり、あなたが制御するネットワークから到達でき、AWS の外から来るクエリを受け付けるアドレスの組です。
きれいに失敗する順序で経路を組み立てる
三つのホップが存在する必要があり、それぞれに独自の失敗の仕方があります。
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesフォワーダーは VPN 経由でエンドポイントのアドレスへの経路を必要とし、戻りの経路も機能する必要があります。ポート 53 の従来の DNS では、エンドポイントは UDP と TCP で応答するため、両方のプロトコルを許可し、両方が途中のステートフル検査を通過できるようにする必要があります。
次に DNS ビューを別に確認します。プライベート ホストゾーンは関連付けられた VPC からしか見えず、明示的に共有を設定した場合を除いて他の VPC からは見えません。到達可能なエンドポイントがあっても、それだけで全てのプライベート ゾーンがその解決コンテキストで解決できるようにはなりません。
アウトバウンド エンドポイントは逆方向に提供するもので、あなたのラップトップから来るクエリには応答しません。
両端から検証する
クライアントからフォワーダーへ、次にフォワーダーからエンドポイントへ問い合わせます。クライアントが失敗してフォワーダーが成功するなら、隙間はその二者の間にあります。
両方が失敗する場合は、エンドポイントのセキュリティ ポリシーと、実際に見えている送信元アドレスを確認します。NAT の背後にあるフォワーダーはラップトップの VPN アドレスではなく NAT アドレスを示すため、その違いだけでクエリが落ちます。両方が成功してもアプリケーションが失敗するなら、アプリケーションはテストしたものとは別のリゾルバを使っている可能性があります。
パブリックとプライベートの名前空間は意図的に分けておきます。Split DNS は設定するポリシーであり、一回の検索がたまたまデータを返した副作用ではありません。
私ならやらないこと
一回の検索を通すためだけの NAT ルールを追加して、それを設計と呼ぶことはしません。
一回のテストでレコードが返ったからといって、すべてのリモート クライアントをプラス二アドレスに向けることはしません。また、一台のフォワーダーにアクセスが必要なだけで、エンドポイントのセキュリティ ポリシーを VPN プール全体に広げることはしません。ポリシーを広げる前に、VPC 内に承認済みのフォワーダーが既にあるかを確認するのも同じ理由です。