GCP Private DNS Zones | Internal DNS Resolution in Google Cloud

What is a private DNS zone?

In public DNS, anyone in the world can look up a hostname and get an answer. A private DNS zone works differently: it is only visible inside the VPCs you authorise. Queries from outside those networks get no response.

You define records just like you would in a public zone. For example, you might create an A record for postgres.internal.example.com that points to a Cloud SQL private IP, or a record for redis.cache.internal that points to a Memorystore instance. Apps inside the VPC resolve those names through the VPC resolver without any extra configuration. Nothing outside the VPC sees the records.

Private zones are managed through Cloud DNS and attach to one or more VPCs. The VPC resolver at 169.254.169.254 handles the lookup for any name that matches the zone’s domain suffix.

Why private DNS zones matter

Without a private zone, you have two options for internal service connectivity: hardcode IP addresses in your application config, or maintain manual hosts files on every VM. Both create operational problems.

Private zones eliminate those problems by giving you a single place to manage internal name-to-IP mappings. The practical benefits are real:

• No hardcoded IPs. Apps connect to db.internal.example.com rather than 10.10.0.5. When the database is migrated or recreated, you update one DNS record rather than every app that connects to it.
• Easier service discovery. Services can find each other by stable, meaningful names rather than IPs that change when resources are replaced.
• Cleaner access control. You can give a name only to VMs in the VPCs that need it, keeping internal services invisible to everything else.
• Simpler migrations. Moving a service to a new IP becomes a DNS update with a short TTL rather than a coordinated app deployment.

Private zones also let you override public DNS names inside the VPC, which is the key mechanism for routing Google API traffic through private endpoints when you are using Private Google Access or VPC Service Controls.

How private DNS zones work in GCP

When you create a private zone in Cloud DNS, you attach it to one or more VPCs. These are called authorised networks. VMs in those VPCs send DNS queries to the VPC resolver at 169.254.169.254. The resolver checks whether any private zone matches the query name and, if so, returns the answer from that zone. Public DNS is only consulted if no private zone matches.

A few details that matter in practice:

• Private zones take precedence over public DNS for names that match. This is how overriding googleapis.com works: you create a private zone for that suffix, and the VPC resolver serves your records instead of the public ones.
• Custom DNS servers you run yourself (such as BIND on a VM) do not automatically inherit private Cloud DNS zones. If you use custom DNS servers, configure them to forward unmatched queries to the VPC resolver so they can still reach your private zones.
• A private zone can be attached to multiple VPCs. VMs in any of the authorised VPCs can resolve names from the same zone without you duplicating records.

This resolver behaviour is covered in more depth on the DNS in GCP page.

When to use private DNS zones

Private zones are the right tool in these situations:

• Internal app-to-database connectivity. Give Cloud SQL, Memorystore, or self-managed databases a stable DNS name that apps can use regardless of the underlying IP.
• Internal service discovery. Microservices that communicate inside a VPC can find each other by name rather than by IP or service registries.
• Shared services VPCs. A zone attached to a shared services VPC lets other VPCs resolve those names via DNS peering, without duplicating records. This is a common pattern in Shared VPC setups.
• Hybrid connectivity. On-premises services can be given names in a private zone, or GCP names can be forwarded to on-premises DNS when the on-premises DNS system is authoritative. See Cloud VPN and Cloud Interconnect for the connectivity layer.
• Private Google Access. Override googleapis.com inside the VPC to route API traffic through private VIPs. Required when enforcing VPC Service Controls.

Private DNS zones vs forwarding zones

Both are private in the sense that they only apply inside authorised VPCs. The difference is where the records live.

Choose a private managed zone when Cloud DNS should be the authoritative source for those names. Choose a forwarding zone when another DNS server already owns those names and Cloud DNS should delegate to it. In hybrid environments, you often have both: a private zone for GCP-native names and a forwarding zone to reach on-premises hostnames.

# Forwarding zone that sends corp.internal queries to an on-premises DNS server
# Use --private-forwarding-targets for servers behind VPN or Interconnect
gcloud dns managed-zones create corp-internal-fwd \
  --dns-name=corp.internal. \
  --description="Forward corp.internal to on-premises DNS" \
  --visibility=private \
  --networks=my-vpc \
  --private-forwarding-targets=10.0.0.53

Private DNS zones vs DNS peering

DNS peering is a separate Cloud DNS feature that lets one VPC resolve names from private zones attached to another VPC. It often gets confused with VPC network peering because both involve two VPCs, but they are independent features.

VPC network peering connects networks at the routing level so that traffic can flow between them. It does not share DNS. A VM in a peered VPC still cannot resolve names from the other VPC’s private zones unless you configure DNS peering explicitly.

DNS peering is useful when you have a private zone in one VPC and want VMs in another VPC to resolve names from it, without duplicating the records. A common setup is a shared services VPC that owns the DNS zone, with application VPCs using DNS peering to read from it. You configure a peering zone in the consumer VPC that delegates queries for the relevant suffix to the producer VPC’s Cloud DNS server.

# DNS peering zone in vpc-a that delegates shared.internal
# queries to the Cloud DNS server of the shared-services project
gcloud dns managed-zones create shared-internal-peering \
  --dns-name=shared.internal. \
  --description="DNS peering to shared services VPC" \
  --visibility=private \
  --networks=vpc-a \
  --dns-peer-project=shared-services-project \
  --dns-peer-managed-zone=shared-internal-zone

Common setup patterns

Internal names for a single VPC

The simplest case: you have one VPC and want internal names for databases, caches, or APIs. Create a private zone for a domain like internal.example.com, attach it to your VPC, and add records. Apps in the VPC resolve those names through the VPC resolver without any additional configuration.

Shared services VPC

In a Shared VPC architecture, a shared services VPC often hosts central infrastructure like databases, monitoring agents, or build systems. Create the private zone in the shared services VPC and configure DNS peering in each application VPC so their VMs can resolve the shared service names without duplicating the zone everywhere.

Hybrid on-premises and GCP

In hybrid environments connected over Cloud VPN or Interconnect, you typically need name resolution to work in both directions:

• GCP VMs resolving on-premises names: create a forwarding zone in Cloud DNS that forwards queries for the on-premises domain to your on-premises DNS servers.
• On-premises VMs resolving GCP names: configure your on-premises DNS servers to forward queries for the GCP domain to the inbound DNS policy IP in your VPC.

See the DNS in GCP page for how inbound forwarding policies work.

Overriding googleapis.com for Private Google Access

This is an advanced pattern, but a required one when you are using Private Google Access with VPC Service Controls. VMs with no external IP need to reach Google APIs through private VIPs. Without a DNS override, the VPC resolver returns public Google API IPs and traffic goes over the internet rather than staying inside the VPC perimeter.

You fix this by creating a private zone for googleapis.com that returns the private VIP addresses instead. Which VIP depends on your setup:

• private.googleapis.com (199.36.153.4/30): for Private Google Access without VPC Service Controls enforcement
• restricted.googleapis.com (199.36.153.8/30): required when enforcing VPC Service Controls, as it ensures perimeter checks are applied

See the Private Google Access page for the full setup including firewall rules and routes.

Step-by-step: creating a private zone and adding a record

This example creates a private zone for internal.example.com, attaches it to a VPC, and adds an A record for a database.

# 1. Create the private zone attached to my-vpc
gcloud dns managed-zones create internal-example \
  --dns-name=internal.example.com. \
  --description="Private zone for internal services" \
  --visibility=private \
  --networks=my-vpc

# 2. Verify the zone was created correctly
gcloud dns managed-zones describe internal-example

# 3. Add an A record pointing postgres to a Cloud SQL private IP
gcloud dns record-sets create postgres.internal.example.com. \
  --zone=internal-example \
  --type=A \
  --ttl=300 \
  --rrdatas=10.10.0.5

# 4. Confirm the record exists
gcloud dns record-sets list --zone=internal-example

After this, any VM inside my-vpc can resolve postgres.internal.example.com and get back 10.10.0.5. VMs outside the VPC get no answer. If the database IP changes, update the A record and the change propagates on the next TTL expiry. No application config changes needed.

If you run into DNS resolution problems after creating a zone, the troubleshooting network issues guide covers how to diagnose DNS failures from inside a VM.