【入門編】 Cloud DNSの転送ゾーン(Forwarding Zones)とインバウンドDNSサーバー – クラウドインフラと仮想化ネットワーク実践ガイド

クラウドとオンプレの「架け橋」を作る！Cloud DNSの転送設定を徹底解説

こんにちは！SRE兼クラウドアーキテクトとして、日々インフラの現場を駆け回っている筆者です。

皆さんは、クラウド（GCP）へ移行を進める中で、「オンプレミスにある社内サーバーの名前が、GCPから引けない！」あるいは「その逆で、オンプレからGCP上のサービスが見えない！」という壁にぶつかったことはありませんか？

ネットワークエンジニアにとって、DNSは「住所録」のようなもの。この住所録が正しく共有されていないと、システム同士は「どこに誰がいるのか」分からず、迷子になってしまいます。

今回は、GCPの「Cloud DNS」を使って、オンプレミスとクラウド間でDNSの橋渡しをする方法を、身近な例えを交えて紐解いていきましょう。一歩ずつ、丁寧に解説しますね。

—

1. なぜ「DNSの橋渡し」が必要なの？

まず、なぜわざわざ設定が必要なのかを想像してみましょう。

例えば、皆さんが海外（GCP）へ引っ越したとします。でも、日本（オンプレミス）の家族や友人の電話番号を知りたいときは、海外の電話帳（GCPのDNS）を開いても載っていませんよね。

これと同じで、GCPには「GCPの住所録」、オンプレには「オンプレの住所録」というように、お互いに独立した名簿を持っています。Cloud DNSの「転送ゾーン」と「インバウンドDNSサーバー」は、いわば「海外の電話帳に載っていない番号は、日本の実家に電話して聞いてくれる専用の取次センター」のような仕組みです。

—

2. オンプレからGCPを引く：インバウンドDNSサーバー

まずは、オンプレミスのサーバーがGCP上のリソース（*.internalなど）を名前解決したいケースです。ここで登場するのがインバウンドDNSサーバー（Inbound DNS Forwarding）です。

仕組みのイメージ

オンプレミスのDNSサーバーが「gcp.example.comってどこ？」と問い合わせてきたとき、GCPのインバウンドエンドポイントがその問いを受け取り、Cloud DNSが代わりに答えを返してくれます。

設定のポイント

GCPのコンソール画面（またはgcloudコマンド）で、以下の設定を行います。

# インバウンドDNS転送用のエンドポイントを作成するコマンド例
gcloud dns policies create my-inbound-policy \
    --description="オンプレからの問い合わせを受け付けるポリシー" \
    --enable-inbound-forwarding \
    --network=default  # どのVPCネットワークで待ち受けるか指定

これを設定すると、GCP内に「DNSの受付窓口」がオープンします。オンプレ側のDNSサーバー（BindやWindows Serverなど）で「*.gcp.example.com への問い合わせは、このGCPのIPアドレスに送ってね！」とフォワーダー設定を追加すれば完了です。

—

3. GCPからオンプレを引く：転送ゾーン（Forwarding Zones）

次は逆のパターンです。GCP上のインスタンスが、オンプレミスの社内システム（corp.localなど）へアクセスしたいケースですね。ここで使うのが転送ゾーン（Forwarding Zones）です。

仕組みのイメージ

GCPのCloud DNSに「corp.local宛ての問い合わせが来たら、オンプレミスのDNSサーバーへ聞きに行ってね」というルールを書き込んでおきます。いわば「転送指示書」です。

設定のポイント

gcloudコマンドを使うと、スマートに設定できます。

# corp.local への問い合わせをオンプレミスのDNSサーバー（例: 10.0.0.5）へ転送する設定
gcloud dns managed-zones create corp-local-zone \
    --dns-name="corp.local." \
    --description="オンプレミス名前解決用ゾーン" \
    --forwarding-targets=10.0.0.5  # ここにオンプレミスDNSのIPを指定

この設定により、GCP上のVMが web.corp.local を引こうとすると、Cloud DNSが自動的にオンプレミスのDNSサーバーへパケットを転送し、解決結果を持って帰ってきてくれます。

—

4. 現場で役立つチェックリスト

最後に、構築やトラブルシューティングで必ず確認すべきポイントをまとめておきます。ここさえ押さえておけば怖くありません！

ファイアウォールの穴あけは大丈夫？
DNSは基本的に UDP/53 を使います。GCPのファイアウォールルールと、オンプレ側の境界ファイアウォールで、ポート 53 の通信が許可されているか必ず確認してください。
VPNやInterconnectの疎通確認
DNSの設定以前に、そもそもオンプレとGCP間でIPレベルでの疎通（pingなど）ができている必要があります。
名前解決の経路を確認する
トラブル時は、dig コマンドで「どのサーバーが答えているか」を確認しましょう。

# 特定のDNSサーバーを指定して問い合わせるコマンド
    dig @<GCPのインバウンドIP> internal.gcp.example.com

—

まとめ：ネットワークは「郵便」と一緒

DNSの仕組みを難しく考えすぎないでください。「宛先（ドメイン）」を見て、「誰に聞けばいいか（フォワーダー）」を判断する。この流れは、郵便局が住所を見て、管轄の配達員に荷物を回す仕組みと全く同じです。

今回紹介した「インバウンドDNSサーバー」と「転送ゾーン」は、クラウドとオンプレを繋ぐための「確実な連絡ルート」です。この橋が完成すれば、皆さんのシステムはより柔軟で、かつ強固なものになるはずです。

もし設定中に迷ったら、まずは「パケットが今、どこで止まっているのか？」を一つずつ追いかけてみてくださいね。応援しています！