VPC Peering と DNS Peering の違いを実際の挙動から確認してみる

VPC Peering と DNS Peering の違いを実際の挙動から確認してみる

2025.12.21

はじめに

こんにちは、すらぼです。

この記事は クラスメソッド Google Cloud Advent Calendar 2025 21日目の記事です。

Google Cloud のネットワークに関する勉強を行う中で、Cloud DNS の DNS Peering という機能に出会いました。VPC Peering と名前がよく似ているものの、どのような動きをするものなのかがいまいち理解しきれていなかったため、今回は実際に手を動かしながら動作の違いを見ていきたいと思います。

今回やること

今回は、 Hub and Spoke 型の VPC で、 Private Zone への名前解決の方法を以下のポイントで確認していきます。

  • VPC Peering で経路が確立された VPC 同士でも、DNS の解決には VPC ごとに個別の設定が必要なこと
  • DNS Peering を使った具体的な設定と動作確認

確認に必要なリソースを1から作っているため、Cloud DNS Private Zone の設定だけ知りたい方は、 5. から読んでください。

1. VPC を作成

まず、VPC を作成していきます。
以下の画面から、Hub と Spoke VPC をそれぞれ作成していきます。

CleanShot 2025-12-21 at 13.19.39.png

それぞれ、以下のように設定します。

Hub VPC

項目
名前 dns-lab-vpc-hub
説明 Hub VPC for DNS Peering Lab
サブネット作成モード カスタム
新しいサブネット:
- 名前 dns-lab-subnet-hub
- リージョン asia-northeast1
- IPアドレス範囲 10.1.0.0/24
- プライベートGoogleアクセス オフ
- フローログ オフ

Spoke VPC

項目
名前 dns-lab-vpc-spoke
説明 Spoke VPC for DNS Peering Lab
サブネット作成モード カスタム
新しいサブネット:
- 名前 dns-lab-subnet-spoke
- リージョン asia-northeast1
- IPアドレス範囲 10.2.0.0/24
- プライベートGoogleアクセス オフ
- フローログ オフ

作成された VPC は以下の通りです。

CleanShot 2025-12-21 at 13.25.47.png

2. ピアリングを作成

次に、ピアリングを作成してきます。

CleanShot 2025-12-21 at 14.28.54.png

以下のように、Hub VPC から Spoke VPC にピアリングを作成します。

CleanShot 2025-12-21 at 14.30.55.png

同じように、逆方向も作成します。

CleanShot 2025-12-21 at 14.41.27.png

双方のピアリング設定が完了し、それぞれが「有効」になったらOKです。

CleanShot 2025-12-21 at 14.43.33.png

3. ファイアウォールルールを作成

まずは Hub 用に2つ作成します。

SSH 用

項目
名前 dns-lab-fw-hub-iap-ssh
説明 Allow SSH from IAP
ネットワーク dns-lab-vpc-hub
優先度 1000
トラフィックの方向 Ingress
アクション 許可
ターゲット 指定されたターゲットタグ
ターゲットタグ ssh-iap
ソースフィルタ IPv4範囲
ソースIPv4範囲 35.235.240.0/20
プロトコルとポート 指定したプロトコルとポート
- TCP 22

内部通信用

項目
名前 dns-lab-fw-hub-internal
説明 Allow internal communication
ネットワーク dns-lab-vpc-hub
優先度 1000
トラフィックの方向 Ingress
アクション 許可
ターゲット ネットワーク内のすべてのインスタンス
ソースフィルタ IPv4範囲
ソースIPv4範囲 10.0.0.0/8
プロトコルとポート すべて許可

CleanShot 2025-12-21 at 14.50.25.png

CleanShot 2025-12-21 at 14.53.14.png

これと同じ設定のルールを Spoke VPC 用にも作成します。

合計4つのルールが以下のように表示されていればOKです。

CleanShot 2025-12-21 at 15.00.29.png

4. VM インスタンスを作成

次に、検証用のCompute Engine VM インスタンスを作ります。

まずは Hub 用 VPC に、VMインスタンスを作ります。
基本的にはデフォルトでOKです。ただし、ネットワーク関連の項目を、以下のように設定します。

項目
リージョン asia-northeast1 (サブネットがあるリージョン)
ネットワークタグ ssh-iap (ファイアウォールルールで設定した値)
ネットワークインターフェース
- ネットワーク dns-lab-vpc-hub
- サブネット dns-lab-subnet-hub
- 外部IPv4アドレス なし

CleanShot 2025-12-21 at 15.25.42.png
CleanShot 2025-12-21 at 15.25.15.png

Spoke VPC でも同様に VM インスタンスを作ります。ネットワークインターフェースのみ Spoke 用のもので設定し、作成します。

CleanShot 2025-12-21 at 15.14.09.png

5. Cloud DNS Private Zone の作成

Cloud DNS 画面から、 Private Zone を作成します。

項目
ゾーンのタイプ 非公開
ゾーン名 dns-lab-zone-hub
DNS名 hub.lab
説明 Private DNS Zone for Hub VPC
ネットワーク dns-lab-vpc-hub を選択

CleanShot 2025-12-21 at 16.22.59.png

ゾーンが作成されたら、次は「標準を追加します」からレコード追加を行います。

CleanShot 2025-12-21 at 15.33.38.png

以下の値で、レコードを作成します。

項目
DNS名 db
リソースレコードタイプ A
TTL 300
TTL単位
IPv4アドレス Hub VMの内部IP(例: 10.1.0.2

CleanShot 2025-12-21 at 16.24.52.png

6. Spoke 側で名前解決が失敗することを確認

まずこの状態で、Hub と Spoke それぞれで DNS 解決ができるかを試してみます。
それぞれのインスタンスに ssh して、以下のコマンドを実行します。

nslookup db.hub.lab

まず、Hub 側のインスタンスで nslookup を実行すると、レコードに設定した内部IPが返ってきています。
Hub 側には、正しく名前解決ができていることがわかります。

CleanShot 2025-12-21 at 16.27.53.png

同じように Spoke 側でもコマンドを実行してみると、こちらでは名前解決に失敗しています。
ただ、VPC Peering は正しく設定されているため、内部IPに対する ping リクエストは返ってきています。

CleanShot 2025-12-21 at 16.33.58.png

つまり、VPC Peering だけでは、相手側(今回は Hub)の Private DNS Zone は参照できないことがわかりました。

7. DNS Peering Zone の設定する

Spoke 側での名前解決ができるようにするために、DNS Peering Zone 設定を行っていきます。

「ゾーンを作成」から、以下のように新しいゾーンを作成します。

項目
ゾーンのタイプ 非公開
ゾーン名 dns-lab-peering-zone
DNS名 hub.lab
説明 DNS Peering from Spoke to Hub for hub.lab
オプション DNS ピアリング を選択
ピアネットワーク dns-lab-vpc-hub
ネットワーク dns-lab-vpc-spoke を選択

CleanShot 2025-12-21 at 17.14.52.png

作成が完了すると、以下のような表示が確認できます。

CleanShot 2025-12-21 at 17.15.49.png

DNSピアリング設定で作成されたゾーンは、レコード追加などの操作はできず、ネットワークに対するピアリング設定のみを管理できる状態になっています。

8. もう一度 Spoke 側で名前解決を試してみる

上記の設定を行ったら、Spoke側インスタンスでもう一度 nslookup を叩いてみます。

CleanShot 2025-12-21 at 17.17.17.png

今度は、正しく 10.1.0.2 が返ってくることが確認できました。

9. 別の VPC でも名前解決できるようにしたいとき

DNS Peering の設定が済むと、ここに設定を追加するだけで任意の VPC から名前解決ができるようになります。

試しに、 my-vpc-network というVPCを追加してみました。

CleanShot 2025-12-21 at 17.35.44.png

この VPC に新しく作成したインスタンスから、同じように nslookup を叩いてみると、先ほどと同じように名前解決ができました。

CleanShot 2025-12-21 at 17.37.13.png

これにより、 VPC 同士の Peering が接続されていない場合でも、名前解決を行えるようにできることがわかりました。

終わりに

VPC Peering と DNS Peering の違いを実際の挙動から確認していきました。
DNS 管理はネットワーク構成と密接に絡んでいます。様々な制約と向き合う必要があるネットワーク管理者にとっては、 DNS Peering は単体で名前解決の管理を行うことができる点が非常に便利だと思いました。
今回は検証を目的としていたため、動作確認程度にはなってしまいましたが、同じような方やネットワークに関して勉強している方の参考になれば幸いです。
以上、すらぼでした。

補足: DNSのベストプラクティス

Google Cloud における DNS のベストプラクティスは、ケースによって様々です。オンプレミスとのハイブリッドや、複数の組織が存在する場合などで最適な方法は変わっていきます。
今回は DNS Peering を使用しましたが、他の方法が適している場合もあるため、構成にお悩みの方は以下の記事もぜひ確認してみてください。

https://docs.cloud.google.com/dns/docs/best-practices?hl=ja

この記事をシェアする

FacebookHatena blogX

関連記事