Cloud DNS サーバー ポリシーを適用する

このページでは、Cloud DNS サーバー ポリシーを構成し、それらを Virtual Private Cloud（VPC）ネットワークで使用する方法について説明します。このページを使用する前に、DNS サーバー ポリシーの概要を確認してください。

始める前に

Cloud DNS API を使用するには、Google Cloud プロジェクトを作成し、Cloud DNS API を有効にする必要があります。

REST API を使用するアプリケーションを作成する場合は、OAuth 2.0 クライアント ID も作成する必要があります。

1. Google アカウントをまだお持ちでない場合は、Google アカウントを登録します。
2. Google Cloud コンソールで Cloud DNS API を有効にします。既存の Compute Engine または App Engine プロジェクトを選択するか、新しいプロジェクトを作成できます。
3. REST API にリクエストを行う必要がある場合は、OAuth 2.0 の ID を作成する必要があります。 OAuth 2.0 を設定
4. プロジェクトの次の情報をメモします。この情報は、後の手順で入力する必要があります。
   • クライアント ID（xxxxxx.apps.googleusercontent.com）。
   • 使用するプロジェクト ID。この ID は、Google Cloud コンソールの [概要] ページの上部で確認できます。また、ユーザーがアプリで使用するプロジェクト名を入力するように設定することも可能です。

Google Cloud CLI を実行したことがない場合は、次のコマンドを実行してプロジェクト名を指定し、Google Cloud Console で認証する必要があります。

gcloud auth login

以前に選択したプロジェクトとは異なるプロジェクトを選択するには、コマンドラインで --project オプションを指定します。

DNS サーバー ポリシーを作成する

各 DNS サーバー ポリシー オブジェクトでは、次のいずれかのサーバー ポリシーを定義できます。

• 受信転送を有効にする受信サーバー ポリシー
• 1 つ以上の代替ネームサーバーを指定する送信サーバー ポリシー
• 受信サーバー ポリシーと送信サーバー ポリシーの両方

いずれの VPC ネットワークでも、複数の DNS サーバー ポリシーを参照することはできません。VPC ネットワークに対して受信転送と送信転送の両方を定義する必要がある場合は、受信ポリシーと送信ポリシーの両方を定義するポリシーを 1 つ作成します。

注: 送信ポリシーは、VPC の名前解決の順序を完全に引き継ぎます。送信ポリシーを持つ VPC ネットワークでは、Cloud DNS 限定公開マネージド ゾーン、転送ゾーン、ピアリング ゾーン、レスポンス ポリシー、Compute Engine の内部 DNS、Google Kubernetes Engine 向け Cloud DNS を使用できません。これらの機能が必要な場合は、送信ポリシーの代わりに転送ワイルドカード（* または .）ゾーン（他すべての DNS 名）を使用します。

受信サーバー ポリシーを作成する

受信サーバー ポリシーを作成するには、次の手順を行います。Cloud DNS が、ポリシーの適用先となる各 VPC ネットワークに受信フォワーダー IP アドレスのセットを作成します。ポリシーを作成すると、Cloud DNS が作成したエントリ ポイントを一覧表示できます。

gcloud

受信サーバー ポリシーを作成するには、dns policies create コマンドを実行します。

gcloud dns policies create NAME \
    --description=DESCRIPTION \
    --networks=VPC_NETWORK_LIST \
    --enable-inbound-forwarding

次のように置き換えます。

• NAME: ポリシーの名前
• DESCRIPTION: ポリシーの説明
• VPC_NETWORK_LIST: 受信転送アドレスを作成する必要がある VPC ネットワークのカンマ区切りのリスト

Terraform

dns/policy_inbound/main.tf

GitHub で表示 フィードバック

resource "google_dns_policy" "default" {
  name                      = "example-inbound-policy"
  enable_inbound_forwarding = true

  networks {
    network_url = google_compute_network.default.id
  }
}

resource "google_compute_network" "default" {
  name                    = "network"
  auto_create_subnetworks = false
}

送信サーバー ポリシーを作成する

送信サーバー ポリシーを作成して VPC ネットワークの名前解決順序を変更するには、すべての DNS クエリを別のネームサーバーに転送します。その手順は次のとおりです。始める前に、標準ルーティングと限定公開ルーティングの違いと、代替ネームサーバーのネットワーク要件を理解しておいてください。

gcloud

送信サーバー ポリシーを作成するには、dns policies create コマンドを実行します。

gcloud dns policies create NAME \
    --description=DESCRIPTION \
    --networks=VPC_NETWORK_LIST \
    --alternative-name-servers=ALTERNATIVE_NAMESERVER_LIST \
    --private-alternative-name-servers=PRIVATE_ALTERNATIVE_NAMESERVER_LIST

次のように置き換えます。

• NAME: ポリシーの名前
• DESCRIPTION: ポリシーの説明
• VPC_NETWORK_LIST: 代替ネームサーバーにクエリを実行する VPC ネットワークのカンマ区切りのリスト
• ALTERNATIVE_NAMESERVER_LIST: 代替ネームサーバーとして使用できる IP アドレスのカンマ区切りのリスト。プライベート ルーティングは、RFC 1918 アドレスを持つ代替ネームサーバーにのみ使用されます。
• PRIVATE_ALTERNATIVE_NAMESERVER_LIST: 代替ネームサーバーとして使用できる IP アドレスのカンマ区切りのリスト。プライベート ルーティングを使用してアクセスされます。

Terraform

dns/policy_outbound/main.tf

GitHub で表示 フィードバック

resource "google_dns_policy" "default" {
  name = "example-outbound-policy"

  alternative_name_server_config {
    target_name_servers {
      ipv4_address    = "172.16.1.10"
      forwarding_path = "private"
    }
    target_name_servers {
      ipv4_address = "172.16.1.20"
    }
  }

  networks {
    network_url = google_compute_network.default.id
  }
}

resource "google_compute_network" "default" {
  name                    = "network"
  auto_create_subnetworks = false
}

両方のサーバー ポリシーを作成する

gcloud

受信転送と送信転送の両方に対応する DNS サーバー ポリシーを作成するには、dns policies create コマンドを実行します。

gcloud dns policies create NAME \
    --description=DESCRIPTION \
    --networks=VPC_NETWORK_LIST \
    --alternative-name-servers=ALTERNATIVE_NAMESERVER_LIST \
    --private-alternative-name-servers=PRIVATE_ALTERNATIVE_NAMESERVER_LIST \
    --enable-inbound-forwarding

次のように置き換えます。

• NAME: ポリシーの名前
• DESCRIPTION: ポリシーの説明
• VPC_NETWORK_LIST: 受信転送アドレスを作成し、代替ネームサーバーに対してクエリを実行する必要がある VPC ネットワークのカンマ区切りのリスト
• ALTERNATIVE_NAMESERVER_LIST: 代替ネームサーバーとして使用できる IP アドレスのカンマ区切りのリスト。限定公開ルーティングは、RFC 1918 アドレスが設定された代替ネームサーバーにのみ使用されます。
• PRIVATE_ALTERNATIVE_NAMESERVER_LIST: 代替ネームサーバーとして使用できる IP アドレスのカンマ区切りのリスト。プライベート ルーティングを使用してアクセスされます。

Terraform

dns/policy_basic/main.tf

GitHub で表示 フィードバック

resource "google_dns_policy" "example_policy" {
  name                      = "example-policy"
  enable_inbound_forwarding = true

  enable_logging = true

  alternative_name_server_config {
    target_name_servers {
      ipv4_address    = "172.16.1.10"
      forwarding_path = "private"
    }
    target_name_servers {
      ipv4_address = "172.16.1.20"
    }
  }

  networks {
    network_url = google_compute_network.network_1.id
  }
  networks {
    network_url = google_compute_network.network_2.id
  }
}

resource "google_compute_network" "network_1" {
  name                    = "network-1"
  auto_create_subnetworks = false
}

resource "google_compute_network" "network_2" {
  name                    = "network-2"
  auto_create_subnetworks = false
}

受信フォワーダーのエントリ ポイントを一覧表示する

受信サーバー ポリシーが VPC ネットワークに適用されると、Cloud DNS はオンプレミス システムまたは名前リゾルバが DNS リクエストを送信できる宛先として一連のリージョン内部 IP アドレスを作成します。これらのアドレスは、VPC ネットワークの名前解決順序へのエントリ ポイントとして機能します。

注: 受信転送を無効にしてから再度有効にした場合、または VPC ネットワークを削除してから再作成した場合、エントリ ポイントの IP アドレスが変更されます。

Google Cloud ファイアウォール ルールは、インバウンド フォワーダーのエントリ ポイントとして機能するリージョン内部アドレスに適用されません。Cloud DNS は、ポート 53 で TCP トラフィックと UDP トラフィックを自動的に受け入れます。

各受信フォワーダーは、リージョン内部 IP アドレスと同じリージョン内の Cloud VPN トンネルまたは Cloud Interconnect アタッチメント（VLAN）からクエリを受け入れます。VM インスタンスは、同じ VPC ネットワークの内部 IP アドレスを使用して受信フォワーダーにアクセスできます。受信転送にアクセスするには、ネットワーク インターフェースに外部 IP アドレスがあるか、NIC のサブネットで限定公開の Google アクセスが有効になっている必要があります。

gcloud

受信転送のエントリ ポイントとして機能する一連のリージョン内部 IP アドレスを一覧表示するには、compute addresses list コマンドを実行します。

gcloud compute addresses list \
    --filter='purpose = "DNS_RESOLVER"' \
    --format='csv(address, region, subnetwork)'

DNS ポリシーを更新する

以下のセクションでは、VPC ネットワークの変更と、受信転送の有効化と無効化について説明します。

VPC ネットワークを変更する

DNS ポリシーが適用される VPC ネットワークのリストを変更したときの動作を次に示します。

• ポリシーに受信ポリシーを指定している場合、必要に応じて受信フォワーダーのエントリ ポイントが VPC ネットワークに作成されます。

• ポリシーに送信ポリシーを指定している場合、すべてのリクエストが代替ネームサーバーに転送されるように、各 VPC ネットワークの名前解決順序が更新されます。

gcloud

DNS サーバー ポリシーが適用されるネットワークのリストを変更するには、dns policies update コマンドを実行します。

gcloud dns policies update NAME \
    --networks=VPC_NETWORK_LIST

次のように置き換えます。

• NAME: ポリシーの名前
• VPC_NETWORK_LIST: ポリシーを適用する VPC ネットワークのカンマ区切りのリスト。前のリストは、指定した VPC ネットワークのリストで置き換わります。

受信転送を有効または無効にする

送信ポリシーのみを定義する DNS サーバー ポリシー（代替ネームサーバー）の受信転送を有効にできます。既存の DNS ポリシーの受信転送を無効にすることもできます。

gcloud

DNS サーバー ポリシーの受信転送を有効にするには、dns policies update コマンドを実行します。

gcloud dns policies update NAME \
    --enable-inbound-forwarding

DNS サーバー ポリシーの受信転送を無効にするには、dns policies update コマンドを実行します。

gcloud dns policies update NAME \
    --no-enable-inbound-forwarding

NAME は、ポリシーの名前に置き換えます。

DNS ポリシーを一覧表示する

gcloud

プロジェクト内の DNS サーバー ポリシーを一覧表示するには、dns policies list コマンドを実行します。

gcloud dns policies list

DNS ポリシーを削除する

gcloud

サーバー ポリシーを削除するには、dns policies delete コマンドを実行します。

gcloud dns policies delete NAME

NAME は、削除するポリシーの名前に置き換えます。

代替ネームサーバーのネットワーク要件

Cloud DNS は、代替ネームサーバーにリクエストを送信するときに、次の表に示すソース範囲のパケットを送信します。

代替ネームサーバーのタイプ	ソース範囲
タイプ 1 ネームサーバー 送信ポリシーと同じ VPC ネットワーク内にある Google Cloud VM の内部 IP アドレス。 タイプ 2 ネームサーバー Cloud VPN または Cloud Interconnect を使用して、送信ポリシーが設定されている VPC ネットワークに接続されている、オンプレミス システムの IP アドレス。 サポートされている IP アドレスの詳細については、代替ネームサーバーとルーティング方法をご覧ください。	35.199.192.0/19 Cloud DNS は、すべてのお客様に 35.199.192.0/19 ソース範囲を使用します。この範囲には、Google Cloud VPC ネットワーク、または VPC ネットワークに接続されたオンプレミス ネットワークからのみアクセスできます。
タイプ 3 ネームサーバー インターネットからアクセス可能な DNS ネームサーバーの外部 IP アドレスまたは Google Cloud リソースの外部 IP アドレス（別の VPC ネットワークにある VM の外部 IP アドレスなど）。	Google Public DNS ソース範囲

タイプ 1 とタイプ 2 の代替ネームサーバー

Cloud DNS がタイプ 1 またはタイプ 2 の代替ネームサーバーにアクセスするには、次に挙げるものが必要です。これらの要件は、ネームサーバーが RFC 1918 の IP アドレスで標準ルーティングを使用していても、またはプライベート ルーティングを選択している場合でも変わりません。

• 35.199.192.0/19 に対するファイアウォール構成

  タイプ 1 のネームサーバーの場合、ネームサーバーを指定する送信ポリシーを使用するように構成された各 VPC ネットワーク内の代替ネームサーバーに適用できる、TCP と UDP ポート 53 に対する上り（内向き）許可ファイアウォール ルールを作成します。タイプ 2 のネームサーバーの場合、オンプレミス ネットワークのファイアウォールや同様の機器を構成して、TCP と UDP のポート 53 を許可します。

• 代替ネームサーバーへのルート

  タイプ 1 のネームサーバーの場合、Cloud DNS はサブネット ルートを使用して、ネームサーバーを指定する送信ポリシーを使用するように構成された VPC ネットワーク内のネームサーバーにアクセスします。タイプ 2 のネームサーバーの場合、Cloud DNS は、カスタム動的ルートまたはカスタム静的ルート（タグ付けされた静的ルートを除く）を使用して、ネームサーバーにアクセスします。

• 同じ VPC ネットワーク経由する 35.199.192.0/19 への戻りルート

  タイプ 1 のネームサーバーの場合、Google Cloud は、35.199.192.0/19 の宛先への特別な戻りルートを自動的に追加します。タイプ 2 のネームサーバーの場合、オンプレミス ネットワークには、35.199.192.0/19 の宛先への Cloud VPN トンネルまたは Cloud Interconnect のアタッチメント（VLAN）経由のルートが必要です。このルートのネクストホップはリクエストの送信元と同じ VPC ネットワークとリージョン内にあります。この要件を満たす方法については、タイプ 2 のネームサーバーのルート戦略をご覧ください。

• 代替ネームサーバーからの直接レスポンス

  Cloud DNS では、パケットを受信する代替ネームサーバーが、35.199.192.0/19 にレスポンスを送信する必要があります。ネームサーバーが別のネームサーバーにリクエストを送信し、そのネームサーバーが 35.199.192.0/19 に応答した場合、Cloud DNS はそのレスポンスを無視します。セキュリティ上の理由から、Google Cloud では、各代替ネームサーバーの DNS 応答の送信元アドレスが、代替ネームサーバーの IP アドレスと一致することが必要です。

タイプ 2 のネームサーバーの戻りルート戦略

タイプ 2 のネームサーバーからのレスポンスは、インターネットまたは別の VPC ネットワーク経由で送信できません。また、同じ VPC ネットワーク内にあっても別のリージョンにはレスポンスを送信できません。レスポンスは、同じリージョンと同じネットワーク内で任意の Cloud VPN トンネルまたは Cloud Interconnect のアタッチメント（VLAN）を使用できますが、同じリージョンと VPC ネットワークに返す必要があります。

• 静的ルーティングを使用する Cloud VPN トンネルの場合は、オンプレミス ネットワーク内に、宛先が 35.199.192.0/19 でネクストホップが Cloud VPN トンネルであるルートを手動で作成します。ポリシーベースのルーティングを使用する Cloud VPN トンネルの場合は、35.199.192.0/19 を含めるように、オンプレミスの VPN ゲートウェイのリモート トラフィック セレクタと Cloud VPN のローカル トラフィック セレクタを構成します。
• 動的ルーティングを使用する Cloud VPN トンネルまたは Cloud Interconnect の場合は、トンネルまたは相互接続のアタッチメント（VLAN）を管理する Cloud Router の BGP セッションの 35.199.192.0/19 にカスタムルート アドバタイズを構成します。

タイプ 3 の代替ネームサーバー

Cloud DNS が標準ルーティングを使用して外部 IP アドレスにアクセスする場合、代替ネームサーバーはインターネット上のシステム、一般公開アプリ、Google Cloud リソースの外部 IP アドレスのいずれかであるとみなされます。

たとえば、タイプ 3 の代替ネームサーバーには、別の VPC ネットワーク内にある VM の外部 IP アドレスが含まれます。

タイプ 3 の代替ネームサーバーへのプライベート ルーティングはサポートされていません。

次のステップ

• Cloud DNS の使用時に発生する可能性のある一般的な問題の解決策については、トラブルシューティングをご覧ください。
• Cloud DNS の概要については、Cloud DNS の概要をご覧ください。