In the world of cloud networking—especially when you’re deep in the weeds of VPCs, multi-NIC VMs, and migration strategies—Cloud DNS is often the “unsung hero.” While Kubernetes clusters and high-end GPUs get the spotlight, DNS is the silent navigator making sure your traffic actually finds its way home.
The Two Halves of the Brain: Resolvers vs. Authoritative Servers
To understand DNS, you have to understand the “conversation” between two different roles:
1. The Resolver (The “Responder”)
When your browser asks, “Where is https://www.google.com/search?q=google.com?”, it first talks to a Recursive Resolver (often referred to as a “Responder” because it responds to the client’s query). This is the librarian. It doesn’t necessarily own the answer, but it knows where to find it.
- In GCP: Your VPC has a built-in resolver at the metadata server address (
169.254.169.254). It handles the legwork of finding answers for your VMs.
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 Cloud DNS, “For my domain, here are the IP addresses,” and it tells the rest of the world (or your internal network) exactly where to go.
The Neighborhoods: Cloud DNS Zone Types
Cloud DNS organizes records into Zones. Depending on who needs to see the data, you’ll choose a different neighborhood:
- Public Zones: Visible to the entire internet. If you bought
my-startup.com, you’d host it here. - Private Zones: Visible only inside your VPC. They are invisible to the public—perfect for internal microservices.
- Forwarding Zones: The bridge for hybrid clouds. If your GCP VM needs to find a server on-premises, a forwarding zone tells Cloud DNS “Send this question to my on-prem DNS server via Cloud VPN.”
- Peering Zones: These let one VPC “peer” into another’s DNS namespace. It’s like a one-way mirror where a Consumer VPC can see the DNS records of a Producer VPC.
The Policy Layer: Control and Customization
This is where the real power lies. Cloud DNS uses different types of policies to control how traffic flows and how queries are handled.
1. DNS Server Policies
Server policies define how the VPC itself handles DNS. They are the “plumbing” of your network’s name resolution.
- Inbound Forwarding: This allows your on-premises servers to query Cloud DNS. You get an entry point IP in your VPC, and your on-prem DNS can use it to resolve names inside Google Cloud.
- Outbound Forwarding: This tells your GCP VMs to ignore the default resolver and send all queries to an alternative name server (like an on-premise bind server).
2. Response Policies (The “Responder” Logic)
Often called “Responder policies” in other networking contexts, GCP calls these Response Policies. They act as a filter or “override” for the resolver.
- How they work: Before the resolver goes out to look for an answer, it checks the Response Policy. If a rule matches (e.g.,
*.malicious-site.com), you can tell it to return an error, a “passthru,” or a custom IP address. - Use Case: VPC Service Controls. You can use a response policy to redirect all queries for
*.googleapis.comto the Restricted Google API virtual IP (VIP) without managing a massive list of records.
3. DNS Routing Policies
Routing policies determine what record is returned based on the user’s context.
- Weighted Round Robin (WRR): Split traffic by percentage (e.g., 90% to Blue, 10% to Green for a Canary test).
- Geolocation Routing: Send London users to
europe-west2and New York users tous-east1to reduce latency. - Failover Routing: The “Plan B.” If a health check fails on your primary server, Cloud DNS automatically points users to your backup IP.
The Building Blocks: Essential DNS Records
Inside those zones, you have Resource Records. Here are the ones you’ll use most often:
| Record Type | What it does | Example |
|---|---|---|
| A | Maps a name to an IPv4 address. | web.com -> 1.2.3.4 |
| AAAA | Maps a name to an IPv6 address. | web.com -> 2001:db8... |
| CNAME | An alias (points one name to another). | www -> web.com |
| PTR | Reverse DNS (maps IP to name). | 1.2.3.4 -> web.com |
| MX | Mail Exchanger (where to send email). | mail.google.com |
| TXT | Arbitrary text (used for security/verification). | v=spf1 include:_spf.google.com |
| SOA | Metadata about the zone (admin email, refresh). | ns-cloud-c1.googledomains.com |
| NS | Lists the authoritative name servers. | ns-cloud-a1.googledomains.com |
Putting it Together: A Pro-Engineer View
Imagine you are managing the network for your upcoming family trip to Europe.
- You use a Private Zone so your internal family “itinerary app” works only on your private devices.
- You use Geolocation Routing so if you’re in Italy, your map data loads from the Milan region, but if you’re in London, it hits the London region.
- You use a Response Policy to block any known “travel scam” domains at the DNS level for anyone on your network.
That is the power of Cloud DNS—it’s not just a phonebook,it’s a programmable traffic controller.
