Managed forwarding uses a different source
A Cloud DNS forwarding zone sends matching DNS queries to configured target name servers. For supported internal and on-premises targets, Cloud DNS uses its documented forwarding source range, 35.199.192.0/19. The target resolver therefore sees a different source from the original VM that asked the question.
This explains a common misleading test: a VM can query an on-premises resolver directly, yet the same name times out through Cloud DNS. The direct query proves the VM's route and firewall path, not the managed forwarding service's source allowance and return route. Both directions of the actual forwarding flow must work.
Prepare a test VM in an authorized VPC, forwarding-zone configuration, target resolver address, connectivity diagram, and read access to VPN or Interconnect routing and resolver logs. Identify the exact DNS suffix and a harmless record expected to exist. Keep the investigation scoped to that suffix instead of changing global DNS behavior.
Trace the forwarded query
- Inspect
gcloud dns managed-zones describe ZONE_NAME --project=PROJECT_ID. Confirm the zone's DNS suffix, authorized networks, forwarding target addresses, and applicable target routing method. Check whether another more-specific zone or policy changes which destination handles the name. - Query the name through the VM's intended resolver path and record the result and timestamp. Compare a direct query to the on-premises target only as a separate test. Preserve the distinction between a timeout, an authoritative negative response, and an unexpected answer.
- Inspect firewall and resolver access controls for the documented Cloud DNS forwarding source range. Check both UDP and TCP DNS behavior where required. A large response may need TCP fallback, so a small successful query does not establish every response path.
- Verify that the on-premises network returns traffic for the forwarding source range through the correct connection to the authorized VPC. Review route advertisements, static routes, and asymmetric paths. Use resolver logs or packet evidence to determine whether a request arrives and whether a response leaves on the expected path.
Illustrative scenario
A fictional hybrid application resolves erp.corp.example directly from its VM when pointed at an on-premises resolver, but ordinary system resolution times out. The on-premises firewall allows the VM subnet and denies the Cloud DNS proxy source range. A narrowly reviewed DNS rule and matching return route restore managed forwarding. Changing the private zone's record data would not fix the missing network path.
| Evidence | Likely boundary | Next action |
|---|---|---|
| Direct query works, forwarded query times out | Proxy source allowance or return route | Inspect actual forwarding traffic |
| Resolver logs show no request | Zone selection, routing, or firewall | Trace before the target |
| Request arrives, reply never returns | Return routing or asymmetric filtering | Correct the response path |
| Small answers work, larger answers fail | TCP fallback or packet handling | Test the full DNS transport behavior |
Verify from the intended VPC
Repeat the normal application resolution path from the authorized network, including a short name only if the application's search-domain behavior requires it. Test a known positive record and a known negative response. Confirm no unrelated suffix is accidentally forwarded. Account for DNS caching when interpreting immediate results after a correction. Verify the actual application can reach the resolved destination separately from name resolution.
Operating procedure
Document forwarding suffix, target resolver owner, source-range requirements, and return-route owner. Monitor query failures and hybrid connectivity changes together. Revalidate after VPN, Interconnect, firewall, or on-premises resolver migrations. Keep a small set of representative DNS checks so future operators can distinguish managed forwarding from direct resolver reachability.
Explore Clouvenix managed infrastructure for implementation and operational handover.