パケットはどこで迷うのか：VPC内部DNS解決の深層と、そのネットワーク最適化
クラウドネイティブなインフラを設計する際、我々はしばしば「プライベートサブネットからの通信」をブラックボックスとして扱いがちだ。特に、AmazonProvidedDNS（VPCのDNSリゾルバ）への問い合わせは、インフラエンジニアにとって「動いて当たり前」のインフラ層として認識されている。
だが、パケットレベルの視点に立てば、そこには極めて巧妙に設計されたルーティングと、我々が避けては通れない「レイテンシとセキュリティの境界線」が存在する。今回は、プライベートサブネット内でのDNS名前解決の挙動を解剖し、高負荷環境におけるパフォーマンスチューニングまでを深掘りする。
—
1. VPC DNSリゾルバへの論理パスとパケットの挙動
プライベートサブネット内のインスタンスが 169.254.169.253 へDNSクエリを投げる際、パケットはインターネットへ出る必要はない。AWSの仮想ルーターがこのリクエストをインターセプトし、VPCリゾルバへと転送する。
ここで重要なのは、「パブリックIPを持たないインスタンスであっても、この通信にはNATゲートウェイは関与しない」という点だ。DNSリクエストはVPC内の閉じたネットワークパスを通るため、NATゲートウェイのコストやスループット制限の影響を受けない。
しかし、大規模なマイクロサービス構成では、この「標準リゾルバ」への依存がボトルネックになることがある。特に、短時間に数万もの名前解決を行う場合、リゾルバの負荷分散よりも、クライアント側の glibc の挙動や、UDP パケットのドロップが問題となる。
—
2. ネットワークパフォーマンスの極限：TCPバッファとRTT削減
DNSは伝統的に UDP/53 を使用するが、レスポンスサイズが 512 bytes を超える場合や、DNSSEC を利用する場合は TCP にフォールバックする。この際、デフォルトのTCP設定では、ハンドシェイクのオーバーヘッドや Slow Start アルゴリズムが、ミリ秒単位のレスポンスを求めているアプリにとって足枷となる。
カーネルレベルでこの挙動を最適化するには、sysctl でTCPスタックをチューニングし、名前解決のためのコネクション保持を強化する必要がある。
# /etc/sysctl.conf に以下の設定を追加し、TCPの再利用性を高める
# TIME_WAIT 状態のソケットを高速に再利用する
net.ipv4.tcp_tw_reuse = 1
# TCPウィンドウサイズを調整し、大量の名前解決時のバッファ枯渇を防ぐ
# 最小値、デフォルト値、最大値をそれぞれ数MB単位で設定
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216これらの設定は、DNSクエリが頻発する環境（例：サイドカープロキシが頻繁にサービスディスカバリを行うKubernetesノード）において、ソケットの枯渇を防ぎ、RTT（Round Trip Time）を安定させる。
—
3. セキュリティとTLSハンドシェイクの最適化
現代のクラウドインフラでは、単なるDNS解決にとどまらず、DoH（DNS over HTTPS）や DoT（DNS over TLS）を検討するケースが増えている。しかし、AWS VPCリゾルバに対しては、標準の UDP/53 が最も効率的だ。
セキュリティを担保しつつパフォーマンスを損なわないためのベストプラクティスは、「ローカルでのDNSキャッシュ」の導入にある。CoreDNS や unbound をノードのサイドカーとして配置し、169.254.169.253 への問い合わせ回数を物理的に削減する。
ノードローカルDNSキャッシュの有効性
Kubernetes環境であれば、NodeLocal DNSCache を導入し、Ready な状態のキャッシュをローカルで完結させることで、VPCリゾルバへのパスをバイパス（あるいは最小化）し、ネットワークホップ数を物理的な限界まで減らすことが可能だ。
# ノードローカルキャッシュの定義例（一部抜粋）
apiVersion: v1
kind: ConfigMap
metadata:
name: nodelocaldns
data:
Corefile: |
.:53 {
errors
cache 30 # キャッシュ期間を適切に設定し、VPCリゾルバへのクエリを削減
forward . 169.254.169.253 # 上流は引き続きVPCリゾルバへ
}—
4. ネットワーク脆弱性の回避：境界線の意識
最後に、セキュリティの専門家として警鐘を鳴らしておきたい。パブリックIPを持たないインスタンスであっても、VPC内のリゾルバは「特権的なアクセスポイント」である。
- DNSハイジャック対策: VPC内の
DNS ResolutionとDNS Hostnamesをtrueに設定し、Private Hosted Zonesを利用して名前解決の権限を制御せよ。 - パケットの可視化:
VPC Flow Logsを単なる監査ログとして使うのではなく、packet-levelの分析を行い、異常なDNS Queryパターン（特定ドメインへの大量のNXDOMAIN応答など）を検出するパイプラインを構築せよ。
結びに代えて
ネットワークは魔法ではない。すべては電気信号とパケットの積み重ねだ。パブリックサブネットにNATゲートウェイを設置し、プライベートサブネットとの境界を引くだけがアーキテクトの仕事ではない。その境界線上で、パケットがどのように振る舞い、どのようなカーネルパラメータによって最適化されるのか。その「泥臭い理解」こそが、大規模なクラウドインフラを堅牢に保つ唯一の道である。
次に dig コマンドを叩くとき、あなたは背後の広大なVPCの網を想像できるはずだ。それが、真のクラウドエンジニアの視点である。
コメント