トラブルシューティング

このトラブルシューティングのページでは、限定公開ゾーン転送ゾーン逆引き参照ゾーン の作成時に、Cloud DNS の使用で発生する可能性がある一般的な問題とその対処方法について説明します。

限定公開ゾーン

このセクションでは、限定公開ゾーンに関する問題について説明します。

共有 VPC サービス プロジェクトでの限定公開ゾーンに関する問題

限定公開ゾーンと共有 VPC ネットワークの併用に関する重要な情報については、概要ページの限定公開ゾーンと共有 VPC をご覧ください。

限定公開ゾーンを作成できない、ポリシーを一覧表示、作成することもできない

DNS サーバー ポリシーの一覧表示や限定公開ゾーンの作成など、限定公開ゾーンのアクションを実行するには、DNS 管理者の役割が必要です。このロールは、IAM ツールで付与できます。

限定公開ゾーンが同じ VPC ネットワークで解決されない

作成した限定公開ゾーンと同じネットワーク上にプライマリ インターフェースがあるVM インスタンスのテストを行っていることを確認します。

トラフィックの宛先が他のインターフェースのサブネットの場合や、VM でポリシーベースのルーティングが構成されている場合を除き、VM はプライマリ インターフェースからすべてのトラフィックを送信します。テスト対象の限定公開ゾーンと同じネットワーク上のプライマリ インターフェースがテストVMに設定されていることを確認します。

VM が次を使用していることを確認します。

gcloud compute instances describe ${vm_name} \
     --zone=${gce_zone} \
     --format="csv[no-heading](networkInterfaces['network'])"

限定公開ゾーンの検索が許可されているネットワークのリストに登録されていることを確認します。

gcloud dns managed-zones describe ${private-zone-name} \
     --format="csv(privateVisibilityConfig['networks'])"

クエリの DNS 名がゾーンに一致することを確認する

Google Cloud は、最長サフィックス マッチングを使用して、指定された DNS 名を照会するゾーンを決定します。クエリで取得するレコードのサフィックスが、VPC ネットワークでアクセス可能な限定公開ゾーンの 1 つと一致していることを確認します。たとえば、Google Cloud はまず、gcp.example.lan にサービスを提供するゾーンの前に、dev.gcp.example.lan にサービスを提供するゾーンで myapp.dev.gcp.example.lan を検索します。

次のコマンドの出力には、特定の限定公開ゾーンの DNS サフィックスが表示されます。

gcloud dns managed-zones describe ${private-zone-name} \
--format="csv[no-heading](dnsName)"

メタデータ サーバーを使用して DNS 名を照会する

dig を使用して、DNS 名のクエリを Google Cloud メタデータ サーバー 169.254.169.254 に直接送信します。

dig ${dns-name} @169.254.169.254

dig を使用して、VM のデフォルトのネームサーバーにクエリを送信します。

dig ${dns-name}

2 つの dig コマンドの出力が異なる場合は、2 番目のコマンドの ;; SERVER: セクションを確認します。応答側のサーバーはメタデータ サーバー 169.254.169.254 のはずです。異なる場合は、デフォルトの Google Cloud メタデータ サーバーではなく、カスタム DNS ネームサーバーを使用するようにゲスト オペレーティング システムが構成されています。Cloud DNS の限定公開ゾーンでは、名前解決にメタデータ サーバーを使用する必要があります。Linux ゲスト環境Windows ゲスト環境では、この処理が自動的に行われます。VM に使用しているイメージをインポートした場合は、適切なゲスト環境がインストールされていることを確認します。

Cloud VPN または Cloud Interconnect を介して限定公開ゾーンが解決されない

まず、承認された VPC ネットワークから DNS 名を正しく照会し、解決できることを確認します。

Cloud VPN または Cloud Interconnect 経由での接続を確認する

オンプレミス システムから VPC ネットワークへの接続が機能していることを確認します。具体的には、ポート 53 の TCP トラフィックと UDP トラフィックをオンプレミス ネットワークから VPC ネットワークに配信できるかどうか確認します。このような下り(外向き)トラフィックが許可されるかどうか、オンプレミス ファイアウォールの構成を確認します。

オンプレミスから VPC ネットワーク内のサンプル VM への接続テストでは、ping(ICMP)などの任意のプロトコルを使用できます。Cloud DNS のリクエストは Google Cloud VM に送信されませんが、サンプル VM への接続テストを行うことで、Cloud VPN トンネルまたは Cloud Interconnect 経由で接続を確認できます。暗黙の上り(内向き)拒否ルールは受信トラフィックをすべてブロックするため、接続できない場合は、サンプルの Google Cloud VM に対して適切な受信許可ファイアウォール ルールを構成してください。

承認された VPC ネットワークで受信転送が有効になっていることを確認する

Cloud DNS 限定公開ゾーンにクエリを送信できる VPC ネットワークに対して、送信転送を有効にする必要があります。すべてのポリシーを一覧表示するには、次のコマンドを使用します。

gcloud dns policies list

出力テーブルでネットワークを特定して、Forwarding フィールドで転送が有効になっていることを確認します。

承認済みネットワークが VPC ネットワークであることを確認する

DNS 転送を使用するにはサブネットが必要です。DNS 転送は VPC ネットワークでのみ使用でき、レガシー ネットワークでは使用できません

gcloud compute networks list \
     --format="csv[no-heading](name, SUBNET_MODE)"

レガシー ネットワークは、出力で LEGACY として識別されます。

ネットワークに有効な DNS 転送アドレスが予約されていることを確認する

次のコマンドは、プロジェクト内のすべての予約済み DNS 転送元 IP アドレスを表示します。

gcloud compute addresses list \
     --filter="purpose=DNS_RESOLVER" \
     --format='csv[no-heading](address, subnetwork)'

フィルタに AND 句を追加して、出力を対象のサブネットワークのみに限定できます。

例: --filter="name ~ ^dns-forwarding AND subnetwork ${subnetwork-name}"

予期したネットワーク / リージョンに IP アドレスが表示されない場合は、Cloud サポートからチケットを提出してください。

上のアドレスでクエリを参照する dig コマンドを実行します。同じネットワーク内の VM から実行します。このテストでは、受信フォワーダが機能していることと、問題が他にあることを確認します。

dig ${dns-name} @10.150.0.1 # - address returned by command above.

同じ dig コマンドを繰り返しますが、VM から VPN に実行します。

限定公開ゾーンで定義された CNAME レコードが機能していない

CNAME レコードは、同じ限定公開ゾーン内の他のレコードを参照することはできますが、他の限定公開ゾーン、内部ゾーン、インターネットで定義されたドメイン名を指すことはできません。

逆引き参照ゾーン

このセクションでは、逆引き参照ゾーンのトラブルシューティングのヒントを紹介します。限定公開ゾーンに関する問題の中には、逆引き参照ゾーンに当てはまるものもあります。他のヒントについては、限定公開ゾーンのトラブルシューティングのセクションをご覧ください。

RFC 1918 以外のアドレスを持つ VM が解決されない

RFC 1918 以外のアドレスを持つ VM の調整

Cloud DNS サポートがリリースされる前の非 RFC 1918 アルファ版の時点で作成された VM は、名前が正しく解決されない場合があります。この問題を解決するには、VM を一時停止して再起動します。

転送ゾーン

このセクションでは、転送ゾーンに関するトラブルシューティングのヒントを紹介します。限定公開ゾーンに関する問題の中には、転送ゾーンに当てはまるものもあります。他のヒントについては、限定公開ゾーンのトラブルシューティングのセクションをご覧ください。

転送ゾーン(送信転送)が機能しない

まず、承認された VPC ネットワークから DNS 名を正しく照会し、解決できることを確認します。

コンシューマ VPC ネットワーク内の VM からプロデューサー VPC ネットワークへのクエリ転送が機能しない

DNS ピアリングを使用しているときに、コンシューマ VPC ネットワークからプロデューサー VPC ネットワークにクエリを転送し、さらに 1 つ以上のオンプレミス ネームサーバーに転送する場合は、プロデューサー VPC ネットワークの VM または VPN トンネルが、クライアント VM のサブネットワークと同じリージョンに存在している必要があります。たとえば、VPC1 がピアリング ゾーンを使用して example.com. のクエリを VPC2 に送信するとします。また、VPC2 に example.com. の限定公開転送ゾーンがあり、Cloud VPN トンネルまたは Cloud Interconnect を使用して、オンプレミス ネームサーバーにクエリを転送するとします。VPC1 の us-east1 にある VM が example.com. を照会できるようにするには、VPC2 の VM または VPN トンネルも us-east1 に存在している必要があります。

Cloud VPN または Cloud Interconnect 経由での接続を確認する

オンプレミスから VPC ネットワーク内のサンプル VM への接続テストでは、ping(ICMP)などの任意のプロトコルを使用できます。また、dig などのツールを使用して、サンプルの Google Cloud VM から直接オンプレミス ネームサーバーにクエリを直接送信する必要があります。

dig ${dns-name} @192.168.x.x # - address of the onprem DNS server.

VPC ネットワークのファイアウォール ルールを確認する

暗黙の下り(外向き)許可ファイアウォール ルールでは、下り(外向き)トラフィックを拒否するカスタムルールを作成していない限り、送信接続を行い、VPC ネットワーク内の VM からのレスポンスを処理できます。カスタム拒否の下りルールを作成した場合は、少なくともオンプレミスのネームサーバーに下りを許可する優先度の高い許可ルールを作成する必要があります。

オンプレミスのファイアウォールを確認する

35.199.192.0/19 で送受信されるトラフィックを許可するように、オンプレミス ファイアウォールが構成されていることを確認してください。

オンプレミス ファイアウォールのログを調べ、35.199.192.0/19 からの DNS リクエストを探します。正規表現で検索するには、"35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*" のような式を使用します。

オンプレミス ネームサーバーを確認する

オンプレミス ネームサーバーで 35.199.192.0/19 からのクエリをブロックする ACL が構成されていないことを確認します。

オンプレミス ネームサーバーを調べて、35.199.192.0/19 からパケットを受信しているかどうか確認します。シェルアクセスが可能な場合、tcpdump などのツールを使用して、35.199.192.0/19 との受信パケットと送信パケットの両方を調査します。

sudo tcpdump port 53 and tcp -vv

戻りルートを確認する

転送ゾーンの作成で説明したように、オンプレミス ネットワークには宛先 35.199.192.0/19 へのルートが必要であり、このルートの次のホップは、DNS リクエストを送信したのと同じ VPC ネットワークの VPN トンネルである必要があります。

複数の VPN トンネルを使用して同じ VPC ネットワークをオンプレミス ネットワークに接続する場合、レスポンスを送信したトンネルを使用してレスポンスを配信する必要はありません。ただし、リクエストが発生したのと同じ VPC ネットワークで、ネクストホップを含む VPN トンネルを使用して、レスポンスを配信する必要があります。

オンプレミス ネットワークに複数の VPC ネットワークを接続している場合、DNS が間違った宛先に返信を返さないように確認する必要があります。Google Cloud は、間違った VPC ネットワークに送信された DNS レスポンスを破棄します。

限定公開ゾーンで定義された CNAME レコードが機能していない

Cloud DNS では、別の限定公開マネージド ゾーンの A レコードを指す CNAME を介した IP アドレスの再帰的解決(CNAME 追跡)をサポートしていません。たとえば、2 つの限定公開マネージド ゾーン zone-a.privatezone-b.private があり、次のようなレコードを作成するとします。

  • target.zone-b.private を参照する CNAME cname.zone-a.private
  • 192.168.1.9 を参照するレコード target.zone-b.private

これらの 2 つのレコードは同じゾーンにない(zone-a.privatezone-b.private は異なっている)ため、Cloud DNS は cname.zone-a.private192.168.1.9 として解決しません。

Cloud DNS は、限定公開マネージド ゾーン内で CNAME を追跡します。

RFC 1918 以外の IP アドレスを使用するネームサーバーへの送信転送が失敗する

デフォルトでは、Cloud DNS は標準ルーティングを使用します。つまり、転送先のネームサーバーに RFC 1918 以外の IP アドレスが設定されている場合、Cloud DNS は公共のインターネット経由でクエリを転送します。標準ルーティングでは、公共のインターネットから到達できない RFC 1918 以外のアドレスを持つネームサーバーは、転送先として使用できません。

VPC ネットワーク経由で RFC 1918 以外の IP アドレスを使用するネームサーバーにクエリを転送するには、Cloud DNS 転送ゾーンまたはサーバー ポリシーを構成して、転送先ネームサーバーに限定公開ルーティングを使用します。

標準ルーティングと限定公開ルーティングの違いについては、転送先とルーティング方法をご覧ください。

この制限は、転送先のネームサーバーへの VPC ルートがあり、標準ルーティングが構成されているときに RFC 1918 以外のアドレスへのルートが Cloud DNS の送信転送動作で無効になっていても適用されます。

セカンダリ NIC への送信転送に失敗する

Cloud DNS は現在、Compute Engine VM のセカンダリ NIC への転送をサポートしていません。

送信転送クエリが SERVFAIL エラーを受け取る

Cloud DNS コントロール プレーンは、アルゴリズムを使用して転送先の応答性を判断します。応答性スコアは、SERVFAIL エラーの数と受信したレスポンスのレイテンシに基づきます。SERVFAIL エラーは、レイテンシよりもスコアに大きく影響します。スコアは 1 時間ごとにリセットされます。

ゾーンのすべてのターゲットのスコアが低い場合、Cloud DNS はそれらのターゲットにクエリを送信しません。次のような現象が見られることがあります。

  • Cloud DNS 転送を使用すると、すぐに(最大 2 ミリ秒)SERVFAIL エラーが発生する
  • クエリの Cloud Logging ログで、destinationIPegressIPegressError の各フィールドに値が入力されない
  • DNS サーバーでクエリの試行が表示されない
  • 転送先に直接送信したクエリ(dig @<TARGET> <QNAME> など)が失敗しない

この問題を解決するには、オンプレミス ネームサーバーが正しく構成されていることを確認します。さらに、オンプレミス ネームサーバーが 4 秒以内にクエリに応答することを確認します。オンプレミス ネームサーバーがアップストリーム ネームサーバーにコンサルトする場合は(たとえば、キャッシュ リゾルバとして構成されているため)、アップストリーム ネームサーバーに問題がないことを確認します。

VPC で RFC 1918 以外のアドレス範囲を使用した受信転送が失敗する

VPC が RFC 1918 以外のアドレス範囲を使用している場合、Cloud DNS で受信転送を使用できません。

次のステップ

  • 概要では、機能に関するより詳しい情報を提供しています。
  • サポートエリアのリンクから、その他のサポート情報をご覧ください。