Check the project and managed-zone identity before recreating a DNS zone that looks missing in PD Google Cloud DNS. A zone listed in an account and a publicly delegated domain are separate facts.

Compare the project and connection

1. Open Google Cloud DNS → Providers and identify the selected connection.
2. Compare its intended project ID with the project holding the zone.
3. Confirm that the service-account credential has the required access in that project and the Cloud DNS API is enabled.
4. Select that provider in Zones and search for the domain.
5. Open a known record set and compare it with the intended zone.

Do not confuse the project ID with the display name or project number. A separate project needs its own deliberately configured connection and access; changing a zone’s client binding does not grant Google Cloud project permissions.

Distinguish the two zone names

Google Cloud has a managed-zone resource name and a DNS name/suffix. They are not necessarily the same text. Record both when investigating a zone that appears in a list but returns a missing-zone or records error when opened.

Google’s managed-zone reference describes those fields. Keep the actual project and native zone identity available to the administrator and support team, without exporting credentials or unrelated zone contents.

Investigate a listed-but-unavailable zone

The module lists a managed zone’s DNS name but derives the managed-zone resource name when opening its records. An existing zone with a different native resource name may therefore appear in the list but fail when opened. Have your Google Cloud administrator compare the actual project, native managed-zone name and DNS suffix before further module writes. This is a source-based limitation, not a finding that your installation has reproduced it. Do not rename, delete or recreate working DNS to fit a guessed name.

The module reads the target project from project_id in the saved service-account JSON. Its provider form has a Service account JSON credential field, not a separate project-ID override. Use a provider credential prepared for the intended project; changing a connection label or customer binding does not select another project. Do not edit a downloaded key file to guess a different target.

A zone that opens normally but supplies different public answers needs a delegation check. Compare the registrar’s nameservers with this zone’s assigned set before editing records. Use the public-zone delegation guide for that separate step.

Check the project and zone identity

Your hosting team and Google Cloud administrator should compare the credential’s project, actual native managed-zone name, DNS suffix and original read error. Separate a missing resource or denied permission from the module’s derived-name lookup. A zone visible in Google Cloud is not proof that the module can address it correctly, and public answers depend on delegation as well. Preserve the working provider zone while that evidence is investigated.

See the PD Google Cloud DNS Blesta guide for related tasks, or explore the module.