Cloud DNS: Public Zones, Private Zones, and DNS Policy on GCP

DNS is the kind of foundational infrastructure that’s invisible when it works and catastrophic when it doesn’t — a misconfigured record or a slow propagation can take down an application that’s otherwise running perfectly. Cloud DNS is Google’s managed authoritative DNS service, built on the same low-latency, high-availability infrastructure Google uses for its own public DNS resolution, and it handles both the public-facing DNS records the entire internet queries and the private, internal-only DNS resolution your VPC resources use to find each other.

The distinction between public and private zones — and how they interact in a hybrid environment with on-prem DNS — is where most of the real design decisions live, more than the basic record-management mechanics, which are close to identical to any DNS provider.

Public vs Private Managed Zones

# Public zone — resolvable by anyone on the internet
gcloud dns managed-zones create my-public-zone \
  --dns-name="example.com." \
  --description="Public DNS for example.com" \
  --visibility=public

# Private zone — resolvable only within specified VPCs
gcloud dns managed-zones create my-internal-zone \
  --dns-name="internal.example.com." \
  --description="Internal service discovery" \
  --visibility=private \
  --networks=my-vpc

A public zone is authoritative for a domain the entire internet can query — this is what makes example.com resolve to your load balancer’s IP for anyone, anywhere. A private zone is scoped to specific VPCs and simply doesn’t exist from the perspective of anything outside those networks — querying internal.example.com from outside the associated VPCs returns nothing, by design, which is exactly the isolation you want for internal service names that shouldn’t be discoverable or resolvable externally.

Split-Horizon DNS: The Same Name, Different Answers

A common enterprise pattern is split-horizon DNS — the same domain name resolving to different IPs depending on whether the query comes from inside or outside your network:

Query for "api.example.com" from the public internet
         │
         ▼
Public zone answers: 34.120.45.67 (public load balancer IP)

Query for "api.example.com" from inside the VPC
         │
         ▼
Private zone answers: 10.0.5.20 (internal load balancer IP)

This is genuinely useful for internal services that also need a public-facing presence — internal traffic gets routed to an internal load balancer (lower latency, no public internet round trip, no Cloud Armor/CDN overhead needed for trusted internal callers) while external traffic hits the public-facing endpoint with its full security stack. Setting this up correctly means creating both a public and a private zone for the same domain, each with different record values, and being deliberate about which VPCs the private zone is visible to.

How Cloud DNS Decides Which Zone Answers a Query

With public zones, private zones, and forwarding zones potentially all configured for overlapping domains, it’s worth understanding the actual resolution logic Cloud DNS applies.

The “most specific zone wins” principle matters in practice: if you have both internal.example.com and db.internal.example.com as separate private zones, a query for db.internal.example.com resolves against the more specific zone, not the broader parent zone — this lets you delegate authority for a subdomain to a different zone (potentially managed by a different team) without the parent zone’s configuration interfering.

DNS Forwarding for Hybrid Environments

For organizations with existing on-prem DNS infrastructure that needs to resolve GCP-hosted private zones, and GCP resources that need to resolve on-prem internal names, Cloud DNS supports forwarding in both directions:

# Forward specific on-prem domain queries from GCP to an on-prem DNS server
gcloud dns managed-zones create onprem-forward-zone \
  --dns-name="corp.internal." \
  --visibility=private \
  --networks=my-vpc \
  --forwarding-targets=192.168.1.10,192.168.1.11

GCP resource queries "server1.corp.internal"
         │
         ▼
Cloud DNS forwarding zone recognizes the domain
         │
         ▼
Forwards query to on-prem DNS servers via
Cloud VPN or Interconnect
         │
         ▼
On-prem DNS resolves and returns the answer

This forwarding requires private connectivity (VPN or Interconnect) between GCP and on-prem, since DNS queries containing internal hostnames obviously shouldn’t traverse the public internet — the forwarding zone is essentially telling Cloud DNS “for this specific domain, don’t try to answer yourself, ask this other DNS server instead,” which composes cleanly with Cloud DNS’s own authoritative zones for everything else.

DNS Policies: Controlling Resolution Behavior for a VPC

Beyond individual zones, a DNS policy controls broader VPC-wide DNS behavior — whether to use Cloud DNS’s default resolution, forward to alternate DNS servers, or enable inbound forwarding so on-prem systems can query GCP-hosted private zones:

gcloud dns policies create my-dns-policy \
  --networks=my-vpc \
  --enable-inbound-forwarding \
  --alternative-name-servers=8.8.8.8,8.8.4.4

--enable-inbound-forwarding reserves an internal IP that on-prem DNS servers can forward queries to, letting on-prem systems resolve GCP private zone names — the reverse direction of the forwarding zone example above, completing a genuinely bidirectional hybrid DNS setup rather than only solving resolution in one direction.

DNSSEC: Protecting Against DNS Spoofing

DNS Security Extensions add cryptographic signatures to DNS responses, letting resolvers verify a response genuinely came from the authoritative source rather than being spoofed or tampered with in transit:

gcloud dns managed-zones update my-public-zone \
  --dnssec-state=on

Enabling DNSSEC on a public zone is close to a one-line change on Cloud DNS’s side, but it requires a coordinated step at your domain registrar — publishing a DS (Delegation Signer) record that chains the trust from the parent zone (the registrar) down to your zone. Skipping this registrar-side step means DNSSEC is enabled but not actually validated by resolvers that check the chain of trust, which is a common “we enabled it but it’s not really protecting anything” gap.

Monitoring DNS Query Health

Cloud DNS exports query volume and response metrics to Cloud Monitoring, which is worth wiring into an alert for the specific failure mode that’s easy to miss otherwise: a sudden spike in NXDOMAIN responses for a domain that should always resolve. This usually signals either a genuine misconfiguration (a deleted record that something still depends on) or a downstream client bug generating malformed queries — either way, it’s a signal worth catching proactively rather than waiting for a user-facing report to surface it first.

Real-World Use Case: Multi-Environment Service Discovery

A company running separate development, staging, and production environments, each needing services to discover each other by name without hardcoded IPs, is a natural private-zone use case. A private zone per environment (dev.internal.example.com, staging.internal.example.com, prod.internal.example.com), each scoped to its environment’s VPC, gives every environment consistent internal service naming without any risk of a staging service accidentally resolving to (or being resolvable from) a production VPC — the zone visibility scoping is itself an isolation boundary, not just a naming convenience.

Best Practices

Use private zones for anything that doesn’t need public resolution, rather than relying on hardcoded internal IPs — DNS-based service discovery survives IP changes that hardcoded references don’t.
Enable DNSSEC on public zones for domains where spoofing risk is a genuine concern, and don’t forget the registrar-side DS record step — enabling it on Cloud DNS alone is incomplete.
Set deliberate, conservative TTLs on records likely to change (like a load balancer IP during a migration), and only lower them shortly before a planned change — very low TTLs on stable records add unnecessary query volume without benefit.
Document split-horizon DNS setups explicitly. A team debugging “why does this resolve differently from my laptop vs from a GCP VM” needs to know split-horizon DNS is intentional, not assume it’s a bug.
Name subdomains with delegation in mind if different teams will manage different parts of the namespace. Splitting db.internal.example.com into its own zone, managed independently by the database team, is cleaner long-term than one team owning an ever-growing monolithic zone for the entire internal namespace.

Common Mistakes

Forgetting the registrar-side DS record when enabling DNSSEC. This is the single most common reason DNSSEC “doesn’t seem to be working” despite being enabled in Cloud DNS — the chain of trust is incomplete without it.

Not scoping private zones to the correct VPCs. A private zone accidentally associated with more VPCs than intended defeats the isolation private zones are meant to provide, and it’s a mistake that’s easy to make silently — nothing errors, the zone just resolves in more places than the design intended.

Setting TTLs too high on records that might need to change quickly during an incident. A 24-hour TTL on a record you might need to repoint during an emergency migration means that emergency takes up to 24 hours to actually propagate for cached resolvers — lowering TTLs proactively before a planned change, not reactively during an incident, avoids this.

Frequently Asked Questions

Does Cloud DNS support domain registration, or only DNS hosting? Cloud DNS itself hosts DNS records; Google Domains (or a third-party registrar) handles the actual domain registration. You can use Cloud DNS to host records for a domain registered anywhere, as long as you update the domain’s nameservers to point to Cloud DNS.

Can a private zone be shared across multiple projects? Yes, particularly relevant with Shared VPC — a private zone can be associated with VPCs across different projects, giving consistent internal DNS resolution across an organization’s shared network without every project needing to duplicate the same zone configuration independently.

What happens if Cloud DNS forwarding to on-prem DNS servers fails? The query fails to resolve for that specific forwarded domain, which is why redundant on-prem DNS server targets (as shown in the forwarding example with two IPs) and monitoring the connectivity path (VPN/Interconnect) the forwarding depends on are both worth planning for deliberately.

Is Cloud DNS globally distributed like Cloud CDN? Yes — as an anycast-based service, DNS queries are answered from the nearest Google point of presence globally, contributing to Cloud DNS’s consistently low query latency regardless of where a query originates.

What happens if I have overlapping private zones for the same domain in the same VPC? Cloud DNS resolves against the most specific matching zone, similar to how longest-prefix matching works in routing — a more specific subdomain zone takes precedence over a broader parent zone covering the same namespace.

Can Cloud DNS answer queries for a domain it’s not authoritative for? Only through explicit forwarding configuration (a forwarding zone or DNS policy alternative name servers) — without that, Cloud DNS returns NXDOMAIN for domains it has no zone or forwarding rule covering, the same as any authoritative-only DNS server would.

Summary

Cloud DNS’s basic record management is unremarkable by design — DNS is a mature, well-understood protocol, and that’s a feature, not a limitation. The real architectural decisions are in how public and private zones are scoped and combined: split-horizon setups for services needing both internal and external presence, forwarding configurations for genuine hybrid environments, and DNSSEC for domains where response integrity matters enough to justify the registrar coordination it requires. Getting these scoping decisions right up front avoids the kind of DNS confusion that’s disproportionately hard to debug precisely because DNS usually just works, right up until a scoping decision made months earlier, by someone who’s since moved to a different team, turns into the reason it doesn’t.