トラブルシューティング

このページでは、Cloud DNS の使用時に発生する可能性のあるエラーとその処理方法について説明します。

マネージド ゾーン

このセクションでは、マネージド ゾーンに関連するエラーの一覧を示します。

invalidFieldValue

'entity.managedZone.name' に指定した値が無効です。

マネージド ゾーン名が文字で始まっていない場合、文字または数字で終わっていない場合、小文字、数字、ダッシュ以外の文字が使われている場合には、マネージド ゾーンの作成オペレーションが、このエラーで失敗する可能性があります。

managedZoneDnsNameNotAvailable

指定されたマネージド ゾーンは作成できません。

次の理由で、マネージド ゾーンの作成オペレーションが、このエラーで失敗する可能性があります。

  • 指定されたゾーンの DNS 名が予約されている(例: ドット(.)、.com.co.uk など)。
  • ゾーンの DNS 名をホストするために利用可能なネームサーバーが他にない。Cloud DNS では、ネームサーバーのプールを使用しており、そのプールには限りがあります。どのネームサーバーでも、各 DNS クエリは 1 つのマネージド ゾーンに明確にマッピングする必要があります。

推奨される対応策: 対象 DNS 名の登録オーナーの場合、ゾーンが重複していないかご確認ください。ドメインとそのサブドメイン向けに DNS をセットアップする場合、単一のルートゾーンを作成して、すべてのサブドメインのレコードをそのゾーンに追加する方法をおすすめします。

verifyManagedZoneDnsNameOwnership

http://www.google.com/webmasters/verification/ でドメイン「EXAMPLE.COM」(または親)の所有権を確認してから、もう一度お試しください。

推奨される対応策: このエラーが表示された場合は、ドメインの所有権を確認してから、もう一度試す必要があります。

レコード

このセクションのエラーは、レコードに関するものです。

containerNotEmpty

指定されたリソースは空ではないため、削除することはできません。

推奨される対応策: リソースを削除するには、最初にそのリソースを空にする必要があります。

invalidZoneApex

ゾーンには、apex で特定の型のリソース レコードセットが 1 つだけ含まれている必要があるため、指定したリソース レコードセットは無効です。

DNS における「apex」は、ゾーンで許可されているラベル数が最も少ない DNS 名を意味します。ゾーンの apex は、ManagedZone.dnsName で表される DNS 名となります。

このエラーは、zone apex の DNS ルール違反となる変更を試みたことを意味します。次の操作は、このエラーを引き起こす可能性があります。

  • apex で必要な NS リソース レコードセットの削除を試みた場合。
  • apex で必要な SOA リソース レコードセットの削除を試みた場合。
  • apex 以外で SOA 型のリソース レコードセットの作成を試みた場合。

推奨される対応策: このエラーが表示された場合は、DNS のルールで許可されていない操作を行おうとしています。リクエストに誤りがないか確認してください。これらの必要なリソース レコードセットを削除する必要はありません。

invalidRecordCount

リソース レコードセット 'entity.change.additions[XX]' は、'<SOA_OR_CNAME>' の型であるため、許可されるレコードは 1 つだけです。

DNS のルールでは、特定のリソース レコードセットを構成できるのは、1 つのリソース レコードのみと規定されています。現在、使用可能な型は SOA または CNAME のいずれかです。これらのルールに違反する変更を作成しようとすると、このエラーが表示されます。次に例を示します。

{
  kind: "dns#rrset"
  name: "blog.foo.com.",
  type: "CNAME",
  rrdata: [ "www.foo.com.", "www2.foo.com." ],
  ...
}

推奨される対応策: このエラーが表示された場合は、リクエストをチェックしてください。許可されていない操作を行おうとしています。

cnameResourceRecordSetConflict

DNS 名 'EXAMPLE.COM' は 1 つの CNAME リソース レコードセットまたは他のタイプのリソース レコードセットのいずれかしか持つことができないため、リソース レコードセット 'entity.change.additions[XX]' は無効です。

このエラーは、同じ DNS 名に対し A レコードと CNAME レコードなど、2 つの型のリソース レコードセットを作成した場合に発生します。このエラーが多く発生するのは、zone apex で CNAME レコードを作成しようとした場合です。同じ名前を持つ必須の SOA レコードや NS レコードと競合するため、このようなレコードを作成することはできません。

推奨される対応策: いずれかのレコードを選択します。

wildcardNotAllowed

指定されたリソース レコードセットに、ワイルドカードにできない型があります。

DNS では、ワイルドカードは存在しないドメイン名のリクエストと一致するリソース レコードセットの特殊な型です。Cloud DNS の制限の 1 つとして、型 NS のワイルドカード リソース レコードセットは作成できません。

推奨される対応策: ワイルドカード NS リソース レコードセットは、現時点ではサポートされていません。サポートにお問い合わせいただくか cloud-dns-discuss に参加して、実現したい機能についてお知らせください。

invalidValue

これは一般的なエラーで、サーバーの状態とは関係なく、リクエストに関する何かが無効であったことを意味します。エラー メッセージには、リクエストの問題のある箇所へのパスと、無効な値が含まれています。このエラーは、次のようなさまざまな理由により発生する可能性があります。

  • 無効な名前でリソース レコードセットを指定した場合。たとえば、「foo..bar」は有効な DNS 名ではありません(中央のラベルが空白)。
  • 無効な型でリソース レコードセットを指定した場合。たとえば、ACNAME は有効な型ですが、「XXX」は有効な型ではありません。
  • レコードが含まれていないリソース レコードセットを指定した場合。
  • 無効なリソース レコードデータを指定した場合。たとえば、「1.1.1.1」は型 A の有効なリソース レコードデータですが、「XXX」は型 A では無効なリソース レコードデータです。
  • 無効な TTL でリソース レコードセットを指定した場合。TTL は正の整数である必要があります。
  • 長すぎるリソース名を指定した場合。

推奨される対応策: リクエストを修正します。

一般的なエラー

このセクションでは、一般的なエラーについて説明します。

alreadyExists

指定されたリソースはすでに存在します。複製を行うことはできません。

推奨される対応策: リソースの作成時に、適切な get/list API を使用して、すでに存在しているリソースを検出します。

accessNotConfigured

アクセスが構成されていません。

このエラーを解決するには、プロジェクトに対して Cloud DNS API を有効にする必要があります。

inactiveBillingState

有効なお支払いが設定されていない間は、プロジェクト EXAMPLE_PROJECT はリクエストを受け入れることはできません。お支払い情報の更新には、数分かかることがあります。

推奨される対応策: GCP Console で、プロジェクトの [設定] セクションからプロジェクトの課金を有効にします。

preconditionFailed

これは一般的なエラーで、リクエストに関する何かが、サーバー リソースの現在の状態に適合していないことを意味します。クライアントはなんらかの修正を行ってから、もう一度試す必要があります。これは、すでに存在している(同じ名前と型の)リソース レコードセットと一致しないリソース レコードセットの削除を試みる、create 変更リクエストを送信する場合に発生することがあります。

ゾーンの現在の状態を再度読み込んで、削除するものを決めます。最後に確認したときとは、状態が異なる可能性があります。

エラー メッセージには、リクエストの問題のある箇所へのパスが含まれています。たとえば、entity.change.deletions[6] は、リクエストの POST 本文内の変更オブジェクトの「deletions」配列内の 7 番目の要素を参照します。

推奨される対応策: 問題として報告されたリクエストの部分を修正します。

required

これは一般的なエラーで、リクエストの必要な部分が一部欠落していることを意味します。たとえば、マネージド ゾーンを作成するリクエストには、名前、DNS 名、説明が必要ですが、これらのいずれかが欠けている場合、そのリクエストはこのエラーにより失敗します。

推奨される対応策: 必要なパラメータを入力して、もう一度お試しください。

notFound

指定されたリソースが存在しません。

推奨される対応策: 既存のリソースの名前を使用していることを確認します。

quotaExceeded

行おうとしている変更により現在の割り当てを超過すると、このエラーが表示されます。たとえば、各ゾーンで特定の数のリソース レコードセットのみを許可されている場合、割り当てがプロジェクトに関連付けられています。この割り当てを増やす必要がある場合は、Google カスタマー サービスにリクエストを行う必要があります。新規プロジェクトにはデフォルトで割り当てが設定されています。DNS で制限される各種サイズについては、Projects.get オペレーションをご覧ください。

推奨される対応策: プロジェクトをチェックして、すでにそのリソースの大半を使用している原因を理解します。使用量が想定していたとおりで、さらに割り当てが必要な場合は、Cloud DNS 割り当ての追加リクエスト フォームで割り当ての追加をリクエストします。

限定公開ゾーン

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

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

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

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

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

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

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

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

VM が使用しているネットワークを確認します。

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

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

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

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

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

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

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

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

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

dig ${dns-name} @169.254.169.254

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

dig ${dns-name}

2 つの dig コマンドの出力が異なる場合は、2 番目のコマンドの ;; SERVER: セクションを確認します。応答側のサーバーはメタデータ サーバー 169.254.169.254 のはずです。異なる場合は、デフォルトの GCP メタデータ サーバーではなく、カスタム 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 のリクエストは GCP VM に送信されませんが、サンプル VM への接続テストを行うことで、Cloud VPN トンネルまたは Cloud Interconnect 経由で接続を確認できます。暗黙の上り拒否ルールは受信トラフィックをすべてブロックするため、接続できない場合は、サンプルの GCP VM に対して適切な受信許可ファイアウォール ルールを構成してください。

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

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

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

転送ゾーン

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

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

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

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

ping(ICMP)などの任意のプロトコルを使用して、オンプレミスから VPC ネットワーク内のサンプル VM への接続テストを行います。また、dig などのツールを使用して、サンプルの GCP 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]|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 が間違った宛先に返信を返さないように確認する必要があります。GCP は、間違った 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 アドレスを使用せずにネームサーバーで転送を行うと、失敗する

オンプレミス DNS ネームサーバーが、一般公開されたルーティング(RFC 1918 以外の)IP アドレスを使用する場合、Cloud DNS は転送をサポートしません。

次のステップ

  • 概要では、機能に関するより詳しい情報を提供しています。
  • サポートエリアのリンクから、その他のサポート情報をご覧ください。
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud DNS のドキュメント