Dev Study
AWSサービスの内部原理 コース

113. VPCのDNSは+2番地に住んでいる — Route 53 Resolverと『VPCの中だけの名前』

VPCの中でホスト名がどうやってIPアドレスに変わるのか、その問い合わせがどこに届いて誰が答えているのかを、住所と流れの図で追っていきます。

① Resolverの住所 — +2番地の正体

EC2インスタンス「db.internal を教えて」
3つの住所で待ち受ける
Route 53 Resolver= Amazon DNS server = AmazonProvidedDNS
リージョンの各AZに組み込まれたDNSサービス
169.254.169.253IPv4リンクローカル
fd00:ec2::253IPv6
CIDR +2番地例: 10.0.0.0/16 → 10.0.0.2
  • 公式: 「The Route 53 Resolver ... is located at 169.254.169.253 (IPv4), fd00:ec2::253 (IPv6), and at the primary private IPV4 CIDR range provisioned to your VPC plus two.」例として 10.0.0.0/16 なら 10.0.0.2
  • 公式: 「Resources within a VPC use a link local address for DNS queries. These queries are transported to the Route 53 Resolver privately and are not visible on the network.」
  • 169.254.169.253 は、コンテナ編で登場したIMDSの 169.254.169.254 の隣人。同じリンクローカル空間(169.254.0.0/16)に住む別サービス
  • IPv6のみのサブネットでも、DHCPオプションセットのネームサーバーが AmazonProvidedDNS である限り、IPv4リンクローカル 169.254.169.253 は到達可能

レッスン2で「VPCのCIDRの先頭から+2番地は予約」とだけ述べていたが、その 10.0.0.2 の正体がこれ——AZに組み込まれたRoute 53 Resolverの玄関だった。DNSクエリはリンクローカルアドレス経由で私的に運ばれ、ネットワーク上のパケットとしては観測できない。

② SGでもNACLでも止められない — 例外リストの回収

EC2インスタンスDNSクエリを送信
どちらの検査も経由せず素通り
Security Group適用されない ✗
Network ACL適用されない ✗
Route 53 Resolver再帰クエリのみサポート
  • 公式: 「You cannot filter traffic to or from the Amazon DNS server using network ACLs or security groups.」
  • 公式: 「The Amazon Route 53 Resolver only supports recursive DNS queries.」— インスタンスは「最終的な答えをちょうだい」と頼み、Resolverが階層をたどる委任の連鎖を代行する

前レッスン群でSGとNACLをフィルタの二層として学んだとき、「ただしResolver宛は例外」と保留していた——それがここで回収される。DNSトラフィックはリンクローカルの私道を通り、SGもNACLも検査に関与しない。Resolverは再帰クエリ専門で、階層的な名前の委任をたどる仕事(基礎編のリゾルバの役割)を丸ごと引き受ける。

③ 1024 PPSの壁 — リンクローカルは合算で課金される

Resolver (DNS)169.254.169.253
IMDSメタデータ 169.254.169.254
NTP時刻同期
WindowsライセンスWindowsのみ
超過すると Resolver が拒否
1024 PPS上限aggregate・引き上げ不可
対策: DNSキャッシュアプリ側でTTLの範囲内の問い合わせ回数を削減
  • 公式: 「There is a 1024 packet per second (PPS) limit to services that use link-local addresses. This limit includes the aggregate of Route 53 Resolver DNS queries, Instance Metadata Service (IMDS) requests, ... NTP ... requests, and Windows Licensing Service ... requests. This quota cannot be increased.」
  • 公式: 「If you reach the quota, the Route 53 Resolver rejects traffic.」

DNSだけで1024ではなく、IMDS・NTP・Windowsライセンスと合算で1024 PPS——しかも引き上げ不可。これが「DNSキャッシュをアプリ側に持て」という実務指針の数字的な根拠になる。可観測性編で扱ったクォータとバックプレッシャーの議論そのままの再演で、上限に達したパケットは黙って消えるのではなくResolverに拒否される。

④ 2つのDNS属性 — 両方trueにして初めて動くもの

enableDnsSupportAmazon提供DNS(Resolver)による解決を有効化。true ならResolverへのクエリが成功する
デフォルト true
enableDnsHostnamesパブリックIPを持つインスタンスへのパブリックDNSホスト名の付与
デフォルト false(デフォルトVPCを除く)
パブリックDNS名パブリックIPのインスタンスに付く
プライベートDNS名Amazon提供の名前をResolverが解決
プライベートホストゾーンカスタムDNSドメイン名
エンドポイントのDNSインターフェイスVPCエンドポイントのプライベートDNS (PrivateLink)
  • enableDnsHostnames の公式: 「The default for this attribute is false unless the VPC is a default VPC.」
  • enableDnsSupport の公式: 「The default for this attribute is true.」「If this attribute is true, queries to the Amazon provided DNS server succeed.」
  • 公式: 「If you use custom DNS domain names defined in a private hosted zone in Amazon Route 53, or use private DNS with interface VPC endpoints (AWS PrivateLink), you must set both the enableDnsHostnames and enableDnsSupport attributes to true.」
  • どちらか一方でも false なら、パブリックDNSホスト名は付かず、Amazon提供プライベートDNSホスト名も解決できない

デフォルトVPCでは両方trueだが、自分で切ったVPCでは enableDnsHostnames がデフォルト false——ここがハマりどころ。前レッスンで載せたインターフェイスエンドポイントのプライベートDNSも、プライベートホストゾーンも、両方trueが前提条件として下敷きになっている。

⑤ プライベートホストゾーン — 『関連付けたVPCの中でだけ』返る名前

プライベートホストゾーンexample.com(db.example.com → 10.0.1.5)
VPC-A に関連付け済み
問い合わせ元の文脈で答えが分かれる
EC2 (VPC-A内)db.example.com? — Resolverは「VPC-Aはこのゾーンに関連付いている」と知っている
外部クライアントインターネットからNSに直接問い合わせ
10.0.1.5私道で解決される
中身は返らないインターネットで再帰解決されるだけ
  • Route 53開発者ガイドの定義: 「A private hosted zone is a container that holds information about how you want Amazon Route 53 to respond to DNS queries for a domain and its subdomains within one or more VPCs that you create with the Amazon VPC service.」VPCユーザーガイド側では同じ概念を「... how you want to route traffic for a domain and its subdomains within one or more VPCs without exposing your resources to the internet」と表現している
  • 公式: 「If you try to query a private hosted zone from outside the VPCs or your hybrid setup, the query will be recursively resolved on the internet.」
  • 公式: 「the private hosted zone information is not returned if you directly query the name servers over the internet. Instead, the VPC Resolver detects that queries are within a private namespace based on VPC to hosted zone associations and uses direct, private connectivity to reach the private DNS servers.」
  • ゾーンには ns-0.awsdns-00.com 等のNSレコードが付くが、これはDNSプロトコルが全ホストゾーンにNSレコードを要求するために置かれた予約済みの名前(Route 53のパブリックホストゾーンには決して使われない)で、「VPC Resolver doesn't connect to the name server addresses.」——Resolverは委任の形式だけ整えて、実際は関連付けの対応表で私道を通る
  • 名前空間が重なる場合(example.com と accounting.example.com 等)、Resolverは最も具体的な一致のゾーンへ振り分ける。一致するプライベートゾーンはあるがレコードがない場合、パブリックDNSへはフォールバックせず NXDOMAIN を返す——これも実務のハマりどころ

プライベートホストゾーンは「関連付けたVPCの中でだけ」名前を解決させる容れ物。外からネームサーバーを直接叩いても中身は返らない——Resolverが「このVPCはこのゾーンに関連付いている」という対応表を持っていて、その文脈を見て私道で答えるからだ。

⑥ どこから聞くかで答えが変わる — スプリットホライズンは仕様

shop.example.com同じ名前への問い合わせ
返るIPが変わる
VPC内からプライベートホストゾーンが応答
インターネットからパブリックホストゾーンが応答
10.0.1.5内部IP
203.0.113.10公開IP
  • スプリットホライズンは公式に一級の構成として記載: 「You can use Route 53 to configure split-view DNS, also known as split-horizon DNS.」同名のパブリック/プライベートホストゾーンを作り、パブリック側がインターネットの経路を、プライベート側が関連付けたVPC内の経路を決める。パブリック側を別のDNSサービスで運用していても動作する(根拠: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-considerations.html)
  • 同じ仕組みの別の例——パブリックDNSホスト名の公式: 「The public IPv4 DNS hostname of an instance resolves to its public IPv4 address (outside the network of the instance) or its private IPv4 address (inside the network of the instance).」外から引くとパブリックIP、中から引くとプライベートIP

同じ名前が中と外で違うIPを返すのはDNSの仕様違反ではなく設計。これはキャッシュ編で問うた「何をもって同じ問い合わせとみなすか(キャッシュキー)」のDNS版で、問い合わせ元のVPCがキーの一部になっている。締めれば——DNSは「名前→番号」の分散データベースであると同時に、『問い合わせ元の文脈』を使って答えを変えるルーティング層でもある。キャッシュ編で「DNSがユーザーを最寄りのPOPへ導く」と述べた仕組みの、VPC側の実体がこれだ。

公式ドキュメントで詳しく ↗