Cloud DNS Private Zones and Forwarding

Cloud DNS private zones are DNS zones that are only accessible from within one or more Google Cloud VPC networks. Unlike public zones, which are globally resolvable over the internet, private zones are invisible to the internet and only respond to queries originating from authorized VPC networks. This is essential for internal service discovery, such as resolving a backend service by its internal hostname (e.g., db.internal.example.com) without exposing that name to the public internet.

Private zones are associated with one or more VPC networks at creation time. A single private zone can be attached to multiple VPC networks, enabling cross-network name resolution. However, the zone is not automatically visible to peered networks — you must explicitly attach the zone to each VPC network that needs to resolve names in that zone.

When a VM in a VPC network sends a DNS query for a name that matches a private zone attached to that network, Cloud DNS intercepts the query and returns the authoritative answer from the zone. The resolution hierarchy is:

Private zones support standard DNS record types: A, AAAA, CNAME, MX, NS, PTR, SOA, SPF, SRV, and TXT. They also support wildcard records.

Forwarding allows you to redirect DNS queries for specific domains to a custom DNS server (e.g., an on-premises DNS server) instead of using the public internet. There are two types:

#### Outbound DNS Forwarding (DNS Server Policy)

An outbound DNS server policy tells Cloud DNS to forward queries for certain domains to one or more target DNS servers. This is typically used when you have a hybrid cloud environment where on-premises DNS servers are authoritative for internal domains (e.g., corp.example.com).

#### Inbound DNS Forwarding (Inbound Server Policy)

An inbound DNS server policy allows DNS queries from external networks (e.g., on-premises) to be resolved by Cloud DNS private zones. This is achieved by creating a VPC-internal IP address that acts as a DNS forwarding endpoint. On-premises DNS servers can then send queries to this IP, and Cloud DNS will resolve them using the private zones attached to the VPC network.

#### Create a Private Zone using gcloud:

gcloud dns managed-zones create my-private-zone \
    --dns-name=internal.example.com. \
    --description="Private zone for internal services" \
    --visibility=private \
    --networks=my-vpc-network

#### Add a DNS Record:

gcloud dns record-sets create db.internal.example.com. \
    --zone=my-private-zone \
    --type=A \
    --ttl=300 \
    --rrdatas=10.0.0.5

#### Create an Outbound DNS Server Policy:

gcloud dns policies create my-forwarding-policy \
    --description="Forward corp.example.com to on-prem" \
    --networks=my-vpc-network \
    --alternative-name-servers=10.1.0.1,10.1.0.2

Note: The --alternative-name-servers flag specifies the target DNS servers. This policy will forward all queries that do not match a private zone to these servers. To forward only specific domains, you need to create a routing policy (see below).

#### Create a Routing Policy for Domain-Specific Forwarding:

gcloud dns policies create my-routing-policy \
    --description="Forward only corp.example.com" \
    --networks=my-vpc-network \
    --enable-logging \
    --alternative-name-servers=10.1.0.1 \
    --private-alternative-name-servers=10.2.0.1 \
    --dns-name=corp.example.com.

Note: The --dns-name flag restricts forwarding to that specific domain. If omitted, the policy forwards all unresolved queries.

#### Create an Inbound Server Policy:

gcloud dns inbound-server-policies create my-inbound-policy \
    --description="Inbound endpoint for on-prem" \
    --network=my-vpc-network

Then create an endpoint:

gcloud dns inbound-server-policies endpoints create my-endpoint \
    --policy=my-inbound-policy \
    --subnet=my-subnet

If the on-premises server is unreachable, Cloud DNS returns a SERVFAIL error after the timeout (default 5 seconds).

A large enterprise runs Active Directory on-premises with DNS zone corp.example.com. They have migrated some workloads to Google Cloud VPCs. They need Google Cloud VMs to resolve on-premises hostnames (e.g., fileserver.corp.example.com) and on-premises clients to resolve Google Cloud VM hostnames (e.g., app.internal.example.com).

Solution: Create a private zone internal.example.com attached to the VPC. Add A records for all Google Cloud VMs. Create an outbound DNS server policy that forwards corp.example.com to the on-premises AD DNS servers (IPs 10.1.0.1, 10.1.0.2). Create an inbound server policy with an endpoint IP from a subnet. Configure on-premises DNS to forward internal.example.com to that endpoint IP. Ensure VPN or Interconnect connectivity.

Common Pitfall: Forgetting to attach the private zone to all VPCs that need it. If the zone is only attached to the production VPC, the development VPC cannot resolve internal.example.com even if they are peered.

Scale Considerations: With thousands of records, Cloud DNS handles it seamlessly. However, forwarding policies have a limit of 4 target name servers. For large on-premises environments, use a load balancer or DNS forwarder as the target.

A SaaS company has separate VPCs for different environments (prod, staging, dev) and wants each environment to resolve internal service names like api.prod.internal only within that environment. They also want to share a common zone global.example.com across all VPCs.

Solution: Create a private zone prod.internal attached to the prod VPC, staging.internal attached to staging VPC, etc. Create a private zone global.example.com attached to all three VPCs. This allows each environment to have its own internal names while sharing common names.

Common Pitfall: Overlapping DNS names. If prod.internal and global.example.com both have a record for api, the more specific zone wins (longest suffix match). Ensure no unintended overlaps.

Performance: Cloud DNS provides low-latency resolution (typically <10ms) for private zones. No additional cost for queries within the same region.

A company uses a third-party SaaS platform that requires DNS resolution of a custom domain saas.mycompany.com to a set of external IPs. They want all VMs in their VPC to use a specific external DNS server (e.g., 8.8.8.8) for that domain, but use Google's public DNS for everything else.

Solution: Create an outbound DNS server policy with --dns-name=saas.mycompany.com. and --alternative-name-servers=8.8.8.8. Attach to the VPC. This ensures only queries for that domain are forwarded; all other queries go to Google's public DNS.

Common Pitfall: If the policy does not specify a --dns-name, it forwards ALL unresolved queries, which may break resolution for other domains. Always use domain-specific policies unless you intend to forward everything.