ハイブリッドDNSの深淵：Cloud DNS転送ゾーンとインバウンド・エンドポイントを極める
クラウドネイティブな環境へ移行する際、多くのエンジニアが「オンプレミスとの名前解決」という古くて新しい壁に突き当たります。特にGCPとオンプレミスをInterconnectやVPNで繋いだ瞬間、DNSのクエリはネットワーク境界を越え、レイテンシとセキュリティの荒波に揉まれることになります。
本稿では、Cloud DNSの「転送ゾーン（Forwarding Zones）」と「インバウンドDNSサーバー（Inbound DNS Forwarding）」という、ハイブリッドネットワークの要所を、パケットレベルの挙動からチューニングまで解剖していきます。
—
1. パケットの行方：名前解決のトポロジーを可視化する
オンプレミスのサーバーがGCP上のPrivate Service Connect（PSC）エンドポイントやGKEのサービスを名前解決しようとする時、あるいはその逆の時、パケットはどのように移動するのでしょうか。
インバウンドDNS転送の仕組み
インバウンドDNSサーバーは、VPC内に配置された「仮想的なDNSリゾルバ」です。オンプレミスからこのエンドポイントに向けてUDP/53（またはTCP/53）でクエリを投げると、GCPの内部ネットワーク経由でCloud DNSへと吸い込まれます。
ここでのポイントは、「オンプレミスから見えるのは、GCPが払い出したエンドポイントのIPアドレスである」という点です。内部的にはGoogleの分散システムがクエリをハンドリングしていますが、ネットワーク層では、パケットはInterconnect等のルーターを通過し、VPCのルーティングテーブルに従ってエンドポイントへと到達します。
—
2. RTT削減とトランスポート層の最適化
DNSといえばUDPというイメージが強いですが、現代のハイブリッド構成ではTCPの重要性が増しています。
TCP/53の重要性とハンドシェイクの最適化
DNSSECの普及や、大きな応答サイズ（EDNS0）を伴うクエリが増える中、UDPの断片化やドロップを防ぐためにTCPフォールバックが多用されます。
- RTT削減: オンプレミスとGCP間は物理的な距離が離れていることが多いため、TCPの3ウェイハンドシェイクだけで数ミリ秒のロスが発生します。
- TCP Fast Open (TFO): もしクライアント側のOSカーネルが対応していれば、
sysctlでnet.ipv4.tcp_fastopenを有効にし、ハンドシェイクのRTTを削り取る検討が必要です。
# クライアント側（オンプレミス）のOS設定例
# TCP Fast Openを有効化し、ハンドシェイクの初期パケットにデータを載せる
sysctl -w net.ipv4.tcp_fastopen=3バッファチューニングの泥臭い事実
高トラフィックな環境では、DNSクエリのスパイク時に listen キューやソケットバッファが溢れます。オンプレ側のリゾルバ（UnboundやBindなど）において、以下のカーネルパラメータを見直してください。
# ソケット受信バッファの拡大
sysctl -w net.core.rmem_max=26214400
# TCPの接続バックログ（同時接続数）の引き上げ
sysctl -w net.core.somaxconn=65535—
3. 条件付き転送ゾーン（Forwarding Zones）の戦略的運用
Cloud DNSの転送ゾーン設定は、単なる「条件分け」ではありません。これは、トラフィックを「どのパスでルーティングするか」のスイッチングを定義するものです。
設定のベストプラクティス
オンプレミスのドメイン（例: corp.example.com）に対する解決を、社内のDNSサーバーへ送る場合、ターゲットIPアドレスは冗長性を考慮し、最低2つ以上の転送先を指定する必要があります。
# gcloudコマンドによる転送ゾーン設定例
gcloud dns managed-zones create forward-zone \
--dns-name="corp.example.com." \
--description="オンプレミス向け条件付き転送" \
--networks=my-vpc \
--visibility=private \
--forwarding-targets=10.0.0.5,10.0.0.6 # オンプレミス側のDNSサーバーIP—
4. セキュリティ：DNSハイジャックと内部脅威への備え
DNSは最も脆弱な攻撃ベクトルのひとつです。クラウドとオンプレミスを繋ぐ場合、以下のセキュリティ対策は「必須」です。
DNS over TLS (DoT) の検討
残念ながら、標準的なインバウンド・エンドポイントはクリアテキストのDNS通信が前提です。ミドルボックスでの盗聴や改ざんを防ぐため、必要に応じてクラウド側の手前にDoTをサポートしたプロキシを配置し、HTTPS/TLSで暗号化するアーキテクチャも検討の俎上に載せるべきです。
セキュリティグループとFWルールによる「最小権限」
DNSのエンドポイントは、VPCの全域からアクセス可能にするのではなく、必要なサブネットからのトラフィックのみを許可するべきです。
# Cloud DNSへのアクセスを制限するファイアウォールルール（概念図）
- direction: INGRESS
priority: 1000
allowed:
- protocol: tcp
ports: ['53']
- protocol: udp
ports: ['53']
source_ranges: ['10.10.0.0/24'] # 特定のオンプレミス接続用サブネットのみ許可—
最後に：SREとして監視すべきメトリクス
最後に、技術者として忘れてはならないのが可観測性です。Cloud DNSの転送は、GCPの Cloud Monitoring に詳細なメトリクスが露出されています。
dns.googleapis.com/query/request_count: 転送先ごとのクエリ数。スパイクが発生していないか。dns.googleapis.com/query/latency: Cloud DNSが転送先から応答を受け取るまでの時間。ここが上昇している場合、Interconnectの輻輳か、オンプレミス側のDNSサーバーの過負荷が疑われます。
DNSは、ネットワークの「血管」です。ここが詰まれば、どんなに堅牢なマイクロサービスも機能しません。パケットがどこで躓いているのか、カーネルのスタックからCloud DNSのマネージドな裏側まで、想像力を働かせてアーキテクチャを設計してください。
現場からは以上です。次回は、PSC（Private Service Connect）を利用したよりセキュアな名前解決の深層に切り込みます。
コメント