Cloud DNS のトラブルシューティング

このページでは、Cloud DNS を使用して一般公開ゾーン、限定公開ゾーン、逆引き参照ゾーン、転送ゾーン、リソース レコードを作成する際の一般的な問題の解決策を説明します。

一般公開ゾーン

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

一般公開ゾーンを作成できない

attempted action failed エラーが発生した場合は、プロジェクトで Cloud DNS API が有効になっていません。

Cloud DNS API を有効にする手順は次のとおりです。

  1. Google Cloud コンソールで、[API ライブラリ] ページに移動します。

    [API ライブラリ] に移動

  2. 最近のプロジェクトの選択画面で、API を有効にする Google Cloud プロジェクトを選択します。

  3. [API ライブラリ] ページで、[API とサービスを検索] ボックスを使用して Cloud DNS API を検索します。API を説明するページが表示されます。

  4. [有効にする] をクリックします。

限定公開ゾーン

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

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

共有 VPC で限定公開ゾーンを使用する場合の重要な情報については、共有 VPC と限定公開ゾーンをご覧ください。

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

ドメイン ネーム システム（DNS）サーバー ポリシーの一覧表示や限定公開ゾーンの作成など、限定公開ゾーンのアクションを実行するには、DNS 管理者のロールが必要です。このロールは、Identity and Access Management（IAM）ツールを使用して付与できます。

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

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

トラフィックが他のインターフェースの 1 つに接続されているサブネット宛の場合や、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 アドレスが表示されない場合は、Google Cloud サポートにチケットを提出してください。

前のコマンドで見つけたアドレスでクエリを参照する dig コマンドを実行します。同じネットワーク内の VM から実行します。このテストは、受信フォワーダが機能しているかどうか、問題が他にないかどうかを検証します。

dig DNS_NAME @10.150.0.1 # address returned by previous command

同じ dig コマンドを繰り返しますが、オンプレミス ホストから VPN に実行します。

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

CNAME 追跡で説明しているように、Cloud DNS は CNAME レコードのみを追跡します。

逆引き参照ゾーン

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

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

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

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

転送ゾーン

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

転送ゾーン（送信転送）が機能しない

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

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

DNS ピアリングを使用しているときに、コンシューマ VPC ネットワークからプロデューサー VPC ネットワーク内の VM にクエリを転送し、さらに 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 に存在している必要があります。

場合によっては、リージョン内にリソースがなくても、DNS ピアリングを使用した転送が機能することがあります。

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 リクエストを探します。regex 式で検索するには、次を使用します。

"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 レスポンスを破棄します。推奨の解決策については、ベスト プラクティス ガイドをご覧ください。

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

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

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

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

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

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

セカンダリ ネットワーク インターフェース コントローラ（NIC）が正しく設定されていることを確認してください。

追加の NIC の設定方法については、複数のネットワーク インターフェースを持つ仮想マシン インスタンスの作成をご覧ください。

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

すべてのターゲット ネームサーバーからエラーを受け取った場合、またはどのターゲット ネームサーバーからもレスポンスを受信しなかった場合、Cloud DNS は SERVFAIL エラーを返します。

この問題を解決するには、オンプレミス ネームサーバーが正しく構成されていることを確認します。次に、DNS トラフィックを許可するために Google Cloud とオンプレミス ファイアウォールを開くの説明に従って、オンプレミス ネームサーバーが Cloud DNS アドレス範囲からのクエリに 4 秒以内に応答していることを確認します。オンプレミス ネームサーバーがアップストリーム ネームサーバーにコンサルトする場合は（たとえば、キャッシュ リゾルバとして構成されているため）、アップストリーム ネームサーバーに問題がないことを確認します。

また、転送先がオンプレミス システムの場合、そのパス用に構成されたルートはカスタム動的ルートまたはカスタム静的ルートになる場合があるので注意してください。ただし、ネットワーク タグが付いたカスタム静的ルートは、DNS クエリの転送には使用できません。オンプレミス ネームサーバーに到達するために使用するルートには、ネットワーク タグが指定されていないことを確認してください。

リソース レコード

このセクションでは、リソース レコードのトラブルシューティングに関するヒントを紹介します。

ゾーン内に存在するリソース レコードセットのクエリ実行時の予期しないデータ

Cloud DNS マネージド ゾーンに存在するリソース レコード セットに対してクエリを実行する際に予期しないデータが返されるのには、いくつかの理由が考えられます。

  1. RFC 1035 で規定された @ 構文を使用して作成されたリソース レコード セットはサポートされていません。Cloud DNS は、そのようなリソース レコード セットの @ マークを文字どおりに解釈します。したがって example.com. ゾーンでは、QNAME @ 用に作成されたレコードセットは、example.com. ではなく @.example.com. として解釈されます。この問題を解決するには、レコードセットを @ マークなしで作成し、すべての名前がゾーンの apex と関連するようにします。

  2. 他のレコードと同様に、ワイルドカード CNAME レコードも RFC 4592 で規定されている存在ルールに従います。たとえば、example.com. ゾーンで次のレコードセットを定義するとします。

    *.images.example.com. IN CNAME _static.example.com.

    srv1.images.example.com. IN A 192.0.2.91

    _static.example.com. IN A 192.0.2.92

    public.srv1.images.example.com. に対するクエリは、空白の回答セクションと NOERROR を返します。CNAME と QNAME の間に存在するレコードがあると CNAME が返されることはありませんが、QNAME と完全に一致するレコードが存在しないため、Cloud DNS は空の応答を返します。これは DNS の標準的な動作です。

Google Cloud VM に誤ったポインタ（PTR）レコードが表示される

メンテナンス イベント中に VM を移行すると、PTR レコード ロジックで一部のエッジケースが正しく処理されず、DNS PTR レコードが googleusercontent.com の完全修飾ドメイン名（FQDN）に戻されます。機能を元に戻すには、PTR レコードをもう一度適用してください。

VM に PTR レコードを適用する方法の詳細については、VM インスタンスの PTR レコードの作成をご覧ください。

順不同で返される Cloud DNS リソース レコードセット

DNS の業界慣例に合わせて、Cloud DNS ネームサーバーでは、リソース レコード セットの順番をランダム化し、権威サーバーによって提供される順番は無視します。これは正常な DNS の動作で、公開および限定公開 Cloud DNS ゾーンの両方に適用されます。

サポートされていないゾーンリソースの種類

別の Cloud DNS ゾーンをターゲットとする機能の gcloud コマンドまたは API リクエストに --location フラグを指定すると、そのリクエストは拒否されます。たとえば、ゾーンのみの機能リクエストをグローバル サーバーに送信したり、グローバルのみの機能リクエストをゾーンサーバーに送信したりすると、サーバーはリクエストを拒否し、_UNSUPPORTED_ZONAL_RESOURCETYPE エラーが返されます。

ゾーン Cloud DNS がサポートするリソースと機能の一覧については、ゾーン Cloud DNS のサポートをご覧ください。

次のステップ