【テクニカル・上級編】 VPC内部のDNS解決とAmazonProvidedDNS(AmazonDNS)の役割 – クラウドインフラと仮想化ネットワーク実践ガイド

VPCの静寂を支配する「AmazonProvidedDNS」の深淵 —— 169.254.169.253が隠すレイテンシと最適化の哲学

クラウドインフラの設計において、我々アーキテクトが最も神経を尖らせる場所の一つが、VPC内の「名前解決」です。何気なく使っている 169.254.169.253。このIPアドレスは単なるリゾルバーではありません。AWSのSDN（Software Defined Networking）の心臓部であり、マイクロ秒単位の応答速度を競う現代の分散システムにおいて、避けては通れない「最初の関門」です。

本稿では、この AmazonProvidedDNS の内部挙動を、Linuxカーネルのネットワークスタックとパケットレベルの観点から解剖し、高負荷環境におけるボトルネックの解消法を論じます。

1. 169.254.169.253：VPCネットワークの「特異点」

多くのエンジニアは「VPCのCIDRの先頭＋2」という教科書的な説明で満足しますが、現場のSREにとって重要なのは、これが「仮想ネットワーク上のエニーキャストアドレス」として機能している事実です。

EC2インスタンスがDNSクエリを投げた際、パケットはローカルの eth0 から物理ネットワーク層へ送られるのではなく、ハイパーバイザー（Nitro System）によってインターセプトされます。ここで重要なのは、この通信がVPC内の物理的なルーティングテーブルを介さないという点です。

RTT削減のためのDNS最適化

名前解決のレイテンシは、アプリケーションのレスポンス時間に直結します。特に TCP を利用した再帰的問い合わせが増加する環境では、以下のチューニングが有効です。

# LinuxカーネルのDNSキャッシュを最適化し、無駄な再検索を抑制する
# /etc/nsswitch.conf で hosts の解決順序を調整
# files (hostsファイル) を優先し、DNSへの無駄なクエリを減らす
hosts:          files dns

# TCPタイムアウトと再送回数の調整 (sysctl.conf)
# DNSクエリの失敗時に即座に再試行するためのパラメータ
net.ipv4.tcp_retries2 = 5
net.ipv4.tcp_syn_retries = 2

2. パケットレベルで紐解くDNS解決のリアリティ

DNSクエリが UDP (ポート53) で発生する場合、パケットのペイロードサイズが MTU を超えると、断片化が発生し、パケットロスによる再送という「最悪のシナリオ」を招きます。

特に、EDNS0 (Extension Mechanisms for DNS) を使用して大きなレスポンスを受け取る場合、1500 bytes の標準的な MTU を意識しなければなりません。Nitro環境下では MTU を 9001 (ジャンボフレーム) に設定することが一般的ですが、DNSリゾルバーとの通信においては、UDP パケットのサイズと Conntrack テーブルの状態がボトルネックとなります。

セキュリティの深層：DNS SpoofingとVPC

AmazonProvidedDNS は、VPC内のプライベートホスト名に対して権威DNSとして振る舞います。ここで注意すべきは、DNS Rebinding 攻撃です。VPC DNS Support を有効にしている場合、外部からのリクエストが VPC 内部のメタデータサービスや内部リソースを解決しないよう、セキュリティグループと NACL で適切にセグメント化する必要があります。

3. 高負荷環境におけるパフォーマンス・チューニング

大規模なマイクロサービス構成では、各ノードからのDNS問い合わせが AmazonProvidedDNS に殺到し、Throttling（帯域制限）が発生することがあります。これを回避する標準的なプラクティスは、ノード内に CoreDNS や Unbound をローカルキャッシュとして配置することです。

CoreDNSの「StubDomain」設定例

# CoreDNSのCorefile構成例
# VPC外への問い合わせはキャッシュさせ、VPC内解決を高速化する
.:53 {
    errors
    health
    cache 30  # キャッシュ期間を延ばし、リゾルバーへの負荷を軽減
    forward . 169.254.169.253 {
        prefer_udp # TCPオーバーヘッドを避けるためUDPを優先
    }
    loop
    reload
}

4. トランスポート層の最適化：TLSとヘッダー圧縮

最近のトレンドである DNS-over-TLS (DoT) や DNS-over-HTTPS (DoH) を導入する場合、TCPハンドシェイクのオーバーヘッドが無視できません。

TCP Fast Open (TFO): net.ipv4.tcp_fastopen = 3 を有効にすることで、2回目の通信からハンドシェイクのRTTを削減可能です。
HPACK圧縮: もしDoHを利用するならば、HTTP/2のヘッダー圧縮（HPACK）により、繰り返し発生するDNSクエリのヘッダー情報を劇的に軽量化できます。

結びに代えて：SREとしての矜持

VPCのDNSを「ただ動くもの」としてブラックボックス化してはいけません。169.254.169.253 は、AWSの広大なネットワークの中で、あなたのアプリケーションが外部と対話するための「最初の言語」です。

カーネルの sysctl パラメータ、CoreDNS のキャッシュ戦略、そしてパケットの断片化一つひとつに目を向けることで、インフラは「なんとなく安定している」状態から、「意図的に設計された堅牢なシステム」へと進化します。

次回の障害対応では、tcpdump でパケットのヘッダーを眺めてみてください。そこには、AWSのエンジニアたちが築き上げた、美しくも冷徹なネットワークの論理が刻まれているはずです。