A private DNS answer depends on where the question comes from
DNS translates a name into information such as an IP address. A private Cloud DNS zone is visible through a configured network scope rather than to every internet resolver. A successful query from an administrator's laptop may be unrelated to the private query path used by a workload. Start with the failing client's network and resolver.
Google's troubleshooting guidance explains checking the authorized network, matching DNS suffix and the resolver used by the VM. More specific matching private zones can affect which zone is consulted. A missing record in that scope should not be treated as proof that a public record is missing.
Build an explicit naming design
- Document the private suffix, zone owner, authorized VPC networks and the teams allowed to change records. In Shared VPC environments, make project ownership visible to operators.
- Identify the resolver path for cloud workloads and any on-premises clients. Record forwarding requirements separately from ordinary application connectivity.
- Create non-sensitive test names and validate both an authorized client and a client outside the intended scope. Keep change history and expiry expectations with the DNS configuration.
For beginners, the record's time to live influences cache behavior, but it does not repair a client using the wrong resolver. Lowering TTL after an incident starts also does not instantly remove all previously cached answers.
Illustrative incident: a migrated VM uses a custom resolver
A VM imported from another environment retains an old resolver configuration. The private zone is correctly associated with its intended VPC, but application lookups still go elsewhere. This is an illustrative scenario. Recreating the private zone would introduce risk without changing where the guest sends its questions.
Compare answers from the same failing client
On a supported Compute Engine VM, the diagnostic pattern below compares the configured resolver with the provider metadata resolver. Replace the sample name with an approved internal test name. A private name can reveal infrastructure details, so keep its output within the authorized operating team.
dig internal-test.example
dig internal-test.example @169.254.169.254
| Observation | Evidence | Investigation boundary |
|---|---|---|
| Different answers from the two queries | Responding resolver and guest configuration | Client resolver path |
| Expected resolver returns no matching record | Query suffix and private-zone selection | Zone or record scope |
| Cloud client works, on-premises client fails | Forwarding path and connectivity | Hybrid DNS design |
| Name resolves but application still fails | Returned address and application connection | Network or application layer |
Check the precise fully qualified name, including any search-domain behavior. Use the linked documentation to review network authorization and forwarding prerequisites; do not assume that an established VPN automatically supplies name resolution.
Correct the resolver or scope deliberately
For the illustrative VM, review why its resolver differs from the approved image configuration. Correct that setting through the normal guest-management process and retain the prior value for reversal. If the evidence identifies an incorrect zone scope, have the DNS owner approve the specific network association. Avoid publishing private host records publicly as a shortcut.
Verify the test name and actual application name from the original failing client. Check that the resulting application connection reaches the intended endpoint. Repeat from another authorized network and confirm an out-of-scope client does not gain unintended visibility. Allow documented cache behavior when judging the transition.
SLOs and a practical DNS SOP
Measure successful expected lookups from representative client locations and the application's resulting transactions. An illustrative internal objective could require each approved network to pass a private-name smoke test after a DNS change. This is a change-acceptance rule, not a provider SLA or a promise of universal resolver behavior.
The SOP should retain suffix, zone, authorized network, resolver, expected answer, TTL and owning team. Escalate overlapping-zone or hybrid-forwarding changes because they can affect more than the reported application. Treat resolution and reachability as separate evidence in incident handover.
Clouvenix can scope network management around a documented private and hybrid naming design.
Technical reference
Google Cloud: troubleshoot Cloud DNS. Reviewed 19 October 2026; confirm the network and forwarding design applicable to the client.