Article 19 – Google Cloud DNS

DNS does not get the spotlight. Kubernetes gets the spotlight. GPUs get the spotlight. But DNS is the silent navigator that makes sure your traffic actually finds its way home. Without it, nothing works. Every single service call, every API request, every time a browser loads a page — DNS is involved.

Let me walk you through how Cloud DNS works in Google Cloud, because there are some very specific concepts here that matter for architecture decisions.

Resolvers vs. Authoritative Servers

To understand DNS, you need to understand the two roles in the conversation:

1. The Resolver (Recursive Resolver)

When your browser asks “Where is google.com?”, it talks to a recursive resolver first. This is the librarian. It does not necessarily own the answer, but it knows where to look.

In GCP, your VPC has a built-in resolver at the metadata server address 169.254.169.254. It handles the DNS lookups for your VMs automatically.

2. The Authoritative Server

This is the “Source of Truth.” It is the final word for a specific domain. Cloud DNS is primarily an authoritative service. You tell it, “For my domain, here are the IP addresses,” and it tells the rest of the world exactly where to go.

Cloud DNS Zone Types

Cloud DNS organizes records into Zones. The type of zone you choose depends on who needs to see the data:

• Public Zones — Visible to the entire internet. If you bought my-startup.com, you host its DNS records here.

• Private Zones — Visible only inside your VPC. Completely invisible to the public internet. Perfect for internal microservices. Your backend can resolve database.internal.prod without exposing that name externally.

• Forwarding Zones — The bridge for hybrid cloud setups. If your GCP VM needs to resolve a hostname that lives on your on-premises network, a forwarding zone tells Cloud DNS: “Send this query to my on-prem DNS server through Cloud VPN.”

• Peering Zones — Let one VPC see another VPC’s DNS namespace. It is a one-way mirror — a Consumer VPC can resolve names from a Producer VPC’s private zone.

The Policy Layer — This Is Where the Real Power Lives

Cloud DNS has three types of policies. This is what separates basic DNS hosting from a programmable traffic controller.

1. DNS Server Policies

Server policies define how the VPC itself handles DNS resolution. Think of these as the plumbing.

• Inbound Forwarding — Allows your on-premises servers to query Cloud DNS. You get an entry point IP in your VPC that your on-prem DNS can point to, so it can resolve names inside Google Cloud.

• Outbound Forwarding — Tells your GCP VMs to skip the default resolver and send all queries to an alternative name server — like an on-premises BIND server.

2. Response Policies

These act as a filter or override for the resolver. Before the resolver goes out to look for an answer, it checks the response policy first. If a rule matches, you can return an error, a passthrough, or a custom IP address.

Practical use case: You can use a response policy to redirect all queries for *.googleapis.com to the Restricted Google API VIP. This is how you enforce VPC Service Controls without manually managing a massive list of DNS records.

3. DNS Routing Policies

These control what record gets returned based on context:

• Weighted Round Robin (WRR) — Split traffic by percentage. Send 90% to your Blue deployment and 10% to your Green deployment for canary testing.

• Geolocation Routing — Send users in London to europe-west2 backends and users in New York to us-east1. Reduces latency by serving from the closest region.

• Failover Routing — The backup plan. If a health check fails on your primary server, Cloud DNS automatically points users to your backup IP.

Essential DNS Record Types

Here are the record types you will work with most:

Working with Cloud DNS — The Commands

Let me show you some practical gcloud commands:

# Create a public DNS zone
gcloud dns managed-zones create my-public-zone \
    --dns-name="example.com." \
    --description="Public zone for example.com" \
    --visibility=public

Output:

Created [https://dns.googleapis.com/dns/v1/projects/my-project/managedZones/my-public-zone].

# Create a private DNS zone (only visible inside your VPC)
gcloud dns managed-zones create my-private-zone \
    --dns-name="internal.prod." \
    --description="Private zone for internal services" \
    --visibility=private \
    --networks=my-custom-vpc

# Add an A record to your zone
gcloud dns record-sets create web.example.com. \
    --zone=my-public-zone \
    --type=A \
    --ttl=300 \
    --rrdatas="34.120.1.50"

# List all records in a zone
gcloud dns record-sets list --zone=my-public-zone

Output:

NAME                TYPE   TTL    DATA
example.com.        SOA    21600  ns-cloud-c1.googledomains.com. ...
example.com.        NS     21600  ns-cloud-c1.googledomains.com. ...
web.example.com.    A      300    34.120.1.50

Putting It All Together

Here is how I think about Cloud DNS in a real architecture:

• Use a Private Zone for internal service discovery so your backend microservices can find each other by name instead of hardcoded IPs
• Use Geolocation Routing to direct users to the nearest regional deployment for lower latency
• Use Response Policies to enforce security controls at the DNS layer — block known malicious domains, redirect API traffic through VPC Service Controls
• Use Forwarding Zones to bridge your hybrid cloud setup so on-prem and cloud resources can resolve each other’s names

DNS is not just a phonebook. In Google Cloud, it is a programmable traffic controller.