VPC Peering と DNS Peering の違いを実際の挙動から確認してみる
はじめに
こんにちは、すらぼです。
この記事は クラスメソッド 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 をそれぞれ作成していきます。

それぞれ、以下のように設定します。
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 は以下の通りです。

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

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

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

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

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 |
| プロトコルとポート | すべて許可 |


これと同じ設定のルールを Spoke VPC 用にも作成します。
合計4つのルールが以下のように表示されていればOKです。

4. VM インスタンスを作成
次に、検証用のCompute Engine VM インスタンスを作ります。
まずは Hub 用 VPC に、VMインスタンスを作ります。
基本的にはデフォルトでOKです。ただし、ネットワーク関連の項目を、以下のように設定します。
| 項目 | 値 |
|---|---|
| リージョン | asia-northeast1 (サブネットがあるリージョン) |
| ネットワークタグ | ssh-iap (ファイアウォールルールで設定した値) |
| ネットワークインターフェース | |
| - ネットワーク | dns-lab-vpc-hub |
| - サブネット | dns-lab-subnet-hub |
| - 外部IPv4アドレス | なし |


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

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 を選択 |

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

以下の値で、レコードを作成します。
| 項目 | 値 |
|---|---|
| DNS名 | db |
| リソースレコードタイプ | A |
| TTL | 300 |
| TTL単位 | 秒 |
| IPv4アドレス | Hub VMの内部IP(例: 10.1.0.2) |

6. Spoke 側で名前解決が失敗することを確認
まずこの状態で、Hub と Spoke それぞれで DNS 解決ができるかを試してみます。
それぞれのインスタンスに ssh して、以下のコマンドを実行します。
nslookup db.hub.lab
まず、Hub 側のインスタンスで nslookup を実行すると、レコードに設定した内部IPが返ってきています。
Hub 側には、正しく名前解決ができていることがわかります。

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

つまり、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 を選択 |

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

DNSピアリング設定で作成されたゾーンは、レコード追加などの操作はできず、ネットワークに対するピアリング設定のみを管理できる状態になっています。
8. もう一度 Spoke 側で名前解決を試してみる
上記の設定を行ったら、Spoke側インスタンスでもう一度 nslookup を叩いてみます。

今度は、正しく 10.1.0.2 が返ってくることが確認できました。
9. 別の VPC でも名前解決できるようにしたいとき
DNS Peering の設定が済むと、ここに設定を追加するだけで任意の VPC から名前解決ができるようになります。
試しに、 my-vpc-network というVPCを追加してみました。

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

これにより、 VPC 同士の Peering が接続されていない場合でも、名前解決を行えるようにできることがわかりました。
終わりに
VPC Peering と DNS Peering の違いを実際の挙動から確認していきました。
DNS 管理はネットワーク構成と密接に絡んでいます。様々な制約と向き合う必要があるネットワーク管理者にとっては、 DNS Peering は単体で名前解決の管理を行うことができる点が非常に便利だと思いました。
今回は検証を目的としていたため、動作確認程度にはなってしまいましたが、同じような方やネットワークに関して勉強している方の参考になれば幸いです。
以上、すらぼでした。
補足: DNSのベストプラクティス
Google Cloud における DNS のベストプラクティスは、ケースによって様々です。オンプレミスとのハイブリッドや、複数の組織が存在する場合などで最適な方法は変わっていきます。
今回は DNS Peering を使用しましたが、他の方法が適している場合もあるため、構成にお悩みの方は以下の記事もぜひ確認してみてください。








